Last modified: 2012-06-21 02:00:36 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 T27610, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25610 - Setting a cookie to go into a RL debug mode
Setting a cookie to go into a RL debug mode
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Trevor Parscal
:
Depends on:
Blocks: 35061
  Show dependency treegraph
 
Reported: 2010-10-21 23:42 UTC by Nux
Modified: 2012-06-21 02:00 UTC (History)
3 users (show)

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


Attachments

Description Nux 2010-10-21 23:42:21 UTC
The idea is to make this work:
javascript:alert(document.cookie="resource_loader_debug=1;path=/")

Meaning a developer could add this URI as a bookmark which would in effect turn on the debug mode.

I was going to attach a patch, but I see my original idea is not working and I have a question - can I replace all this getFuzzyBool thingies in OutputPage.php to a static method call of e.g. ResourceLoaderContext? Something like:
ResourceLoaderContext::isInDebugMode($wgRequest)
Comment 1 Brion Vibber 2010-10-21 23:54:25 UTC
If making a bookmarklet to turn the cookie on, be sure to have one to turn it off too! ;) Actually this'd be handy in a little 'developer goodies' gadget.
Comment 2 Roan Kattouw 2010-11-01 20:38:24 UTC
Implemented in r75825. Cookie name is resourceLoaderDebug. Setting it to "" or "0" disables debug mode, any other value enables debug mode.
Comment 3 Nux 2010-11-05 07:41:16 UTC
Are you sure this is enough? The behaviour seems to differ a bit as you also read "debug" state on line 2410 and 2579 and you don't read from the cookie there. The cookie state is also disregarded in the __construct of ResourceLoaderContext. Maybe not a big difference now, but it seems to be a point where things can go bad in the future (where debug might mean something more). What I'm saying is debugging with a cookie and with a param is different even now and might be worse in future. This doesn't feel like an expected or intended behaviour.
Comment 4 Roan Kattouw 2010-11-05 20:36:38 UTC
(In reply to comment #3)
> Are you sure this is enough? The behaviour seems to differ a bit as you also
> read "debug" state on line 2410 and 2579 and you don't read from the cookie
> there.
Good point, I missed those. Fixed in r76138.

 The cookie state is also disregarded in the __construct of
> ResourceLoaderContext. Maybe not a big difference now, but it seems to be a
> point where things can go bad in the future (where debug might mean something
> more). What I'm saying is debugging with a cookie and with a param is different
> even now and might be worse in future. This doesn't feel like an expected or
> intended behaviour.
This is actually not a problem. All the debug cookie and the debug param when applied to *index.php* do is make OutputPage.php generate links to load.php with debug=true instead of debug=false. load.php itself never needs to read the cookie for this reason (and if it did, that would violate cacheability).
Comment 5 Nux 2010-11-06 21:21:29 UTC
OK, thanks :-).

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


Navigation
Links