Change Details

GettingStarted has a method logUnlessTimeout that cancels a log attempt after a certain amount of time. Otherwise, it's the same as logEvent. This is used by code like: logging.logUnlessTimeout( { action: 'navbar-return-click', funnel: fullTask, pageId: cfg.wgArticleId, revId : cfg.wgCurRevisionId }, 500 ).always( function () { location.href = $this.attr( 'href' ); } ); evt.preventDefault(); This is the only use of logUnlessTimeout, and other people have expressed interest in the same thing. We should implement a helper method, like: function logThenNavigate( $link, eventInstance, timeout ) with timeout being optional and defaulting to 500. It would basically work the same way but handle both the href and timeout. Unlike bug 42815, the navigation is delayed until 'always' or the timeout fires, but the network request still works the same way. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=42815

GettingStarted has a method logUnlessTimeout that cancels a log attempt after a certain amount of time. Otherwise, it's the same as logEvent. This is used by code like: ``` logging.logUnlessTimeout( { action: 'navbar-return-click', funnel: fullTask, pageId: cfg.wgArticleId, revId : cfg.wgCurRevisionId }, 500 ).always( function () { location.href = $this.attr( 'href' ); } ); evt.preventDefault(); ``` This is the only use of `logUnlessTimeout`, and other people have expressed interest in the same thing. We should implement a helper method, like: ``` function logThenNavigate( $link, eventInstance, timeout ) ``` with timeout being optional and defaulting to 500. It would basically work the same way but handle both the href and timeout. Unlike bug T44815, the navigation is delayed until 'always' or the timeout fires, but the network request still works the same way. -------------------------- **See Also**: T44815

GettingStarted has a method logUnlessTimeout that cancels a log attempt after a certain amount of time. Otherwise, it's the same as logEvent. This is used by code like: ``` logging.logUnlessTimeout( { action: 'navbar-return-click', funnel: fullTask, pageId: cfg.wgArticleId, revId : cfg.wgCurRevisionId }, 500 ).always( function () { location.href = $this.attr( 'href' ); } ); evt.preventDefault(); ``` This is the only use of `logUnlessTimeout`, and other people have expressed interest in the same thing. We should implement a helper method, like: ``` function logThenNavigate( $link, eventInstance, timeout ) ``` with timeout being optional and defaulting to 500. It would basically work the same way but handle both the href and timeout. Unlike bug 42815T44815, the navigation is delayed until 'always' or the timeout fires, but the network request still works the same way. -------------------------- **Version**: unspecified **Severity**: normal ****See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=42815: T44815