Last modified: 2014-08-21 21:12:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67566, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65566 - Pre and post-edit anonymous editor acquisition tours are displaying multiple times
Pre and post-edit anonymous editor acquisition tours are displaying multiple ...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
GettingStarted (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Rob Moen
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-20 23:38 UTC by Steven Walling
Modified: 2014-08-21 21:12 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Steven Walling 2014-05-20 23:38:08 UTC
We're getting multiple reports that the pre and post-edit anonymous editor acquisition tours are displaying repeatedly per user. I have tested and confirmed this is the case, at least on English Wikipedia.
Comment 1 Matthew Flaschen 2014-05-20 23:49:40 UTC
I think this is due to ResoureLoader's (the client-side in particular) use of localStorage for resource caching (JS/CSS, etc.).  This adds up pretty quick, and browsers have a limit (you may see an error in your console, "Persistent storage maximum size reached".

This has been discussed before at bug 65364.

So we can work around this by using a cookie and/or solve/improve this in the long-term, by having ResourceLoader use less localStorage.
Comment 2 Ori Livneh 2014-05-21 02:33:36 UTC
Using a cookie temporarily makes sense -- fixing the localStorage issue properly will take some work to get right.
Comment 3 Ori Livneh 2014-05-21 03:37:54 UTC
Something like this would work too, by making activation conditional on the key not being present *and* on it being set successfully:

	function shouldShow() {
		try {
			if ( localStorage.getItem( ctaFlagKey ) === null ) {
				localStorage.setItem( ctaFlagKey, 'true' );
				return localStorage.getItem( ctaFlagKey ) !== null;
			}
		} catch (e) {}
		return false;
	}

This approach wouldn't work with $.jStorage, because it caches any stored value in an in-memory object, so the call $.jStorage.get will always succeed even when the value fails to persist.
Comment 4 Matthew Flaschen 2014-05-21 03:52:29 UTC
Won't that cause it not to show the first time, if their storage happens to be full?
Comment 5 Ori Livneh 2014-05-21 04:51:05 UTC
(In reply to Matthew Flaschen from comment #4)
> Won't that cause it not to show the first time, if their storage happens to
> be full?

Yes, that's the intent. It's the lesser evil: you only activate if you can be sure you can do it without repeatedly pestering the user.
Comment 6 Matthew Flaschen 2014-05-21 05:10:56 UTC
(In reply to Ori Livneh from comment #5)
> Yes, that's the intent. It's the lesser evil: you only activate if you can
> be sure you can do it without repeatedly pestering the user.

Yes, but it also risks invalidating/weakening the experiment by providing too few people with the treatment.  So the cookie is probably the way to go for now.

Since the Gerrit bot is slacking, Rob started this at https://gerrit.wikimedia.org/r/#/c/134540/2 .
Comment 7 Gerrit Notification Bot 2014-05-22 05:05:30 UTC
Change 134540 had a related patch set uploaded by MZMcBride:
Use mw.cookie for CTA flag due to localStorage capacity issues

https://gerrit.wikimedia.org/r/134540
Comment 8 Gerrit Notification Bot 2014-06-06 03:37:44 UTC
Change 134540 merged by jenkins-bot:
Use mw.cookie for CTA flag due to localStorage capacity issues

https://gerrit.wikimedia.org/r/134540

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links