Last modified: 2013-06-24 11:01:56 UTC
Created attachment 11889 [details] Firebug stack trace of first call to prepareToSendOnTour() In Chromium and Firefox I find a single click on a task in GettingStarted results in prepareToSendOnTour() being called twice. I took screenshots of the Firebug stack each time. They seem identical except: * 1st call is from jquery.stall.js line 52 in the if ( typeof e.target.dispatchEvent != 'undefined' ) test and dispatch() shows an event with a timeStamp. * 2nd call is from jquery.stall.js line 68 in the if ( evt === undefined || evt.eventPhase <= 2 ) test and dispatch() shows timeStamp=0.
Created attachment 11890 [details] Firebug stack trace of second call to prepareToSendOnTour()
Could this have something to do with the fact that there are actually two tours launched from the page (the single step guider and the actual gettingstarted tour)?
And prepareToSendOnTour is actually not supposed to use stall at all (it's only being used in openTask). But stall is dispatching the whole click event over again, which means other listeners also get it again. Good detective work. Ori, correct me if I'm wrong, but IIRC, we're trying to phase out stall. I may just replace it in openTask with a preventDefault and doing what we want (e.g. URL navigation in an always).
(In reply to comment #3) > And prepareToSendOnTour is actually not supposed to use stall at all (it's > only > being used in openTask). But stall is dispatching the whole click event over > again, which means other listeners also get it again. > > Good detective work. > > Ori, correct me if I'm wrong, but IIRC, we're trying to phase out stall. I > may > just replace it in openTask with a preventDefault and doing what we want > (e.g. > URL navigation in an always). Dario may want to chime in here, so adding him. For reference: we are looking at gettingstarted click data still, but we're actually using gettingstarted page impressions to create cohorts for analysis, so doing whatever you want to do to ensure no more duplicate events or other weirdness is probably fine.
(In reply to comment #3) > Ori, correct me if I'm wrong, but IIRC, we're trying to phase out stall. I've gone as far as saying that it is known to be broken and should not be used, but S loves that thing. Yes, let's get rid of it. FWIW, as I've noted in bug 4285 (Comment #5, https://bugzilla.wikimedia.org/show_bug.cgi?id=42815#c5 ), $.ajax({ async: false }) should work, despite not having CORS enabled. But it would require quite a bit of testing.
prepareToSendOnTour does two things: 1. Sets the user pref so they don't get the tour every time they go to Special:GettingStarted 2. When that's done (or in the event it fails), actually send them on the tour. This means: 2a. Set the tour cookie. 2b. Actually change the URL. So this function actually has nothing to do with analytics.
(In reply to comment #6) > prepareToSendOnTour does two things: > > 1. Sets the user pref so they don't get the tour every time they go to > Special:GettingStarted > 2. When that's done (or in the event it fails), actually send them on the > tour. > This means: > 2a. Set the tour cookie. > 2b. Actually change the URL. > > So this function actually has nothing to do with analytics. OI heard stall and automatically thought we're talking about click tracking in EventLogging. Sorry to be slow. :)
'prepareToSendOnTour' has been factored out of GettingStarted in change Ia9931733a .
