Page MenuHomePhabricator

JavaScript from mw.loader.store should be listed in browser's developer tools
Closed, DeclinedPublic

Description

I'm pretty sure this was possible before, but right now, I'm not able to do the following:

  1. Enable a broken gadget, or a gadget you want to debug
  2. Access a page where the gadget is executed (e.g. a page where you noticed an error/warning in the console)
  3. On Firefox/Iceweasel, type !SomethingFromThatGadget in the search box in the "Search scripts" field in the "Debugger" tab, to search for all scripts containing that string (e.g. to get some context for the code which is mentioned in the error/warning message)

Expected result
One of the search results contains the gadget script I was looking for (maybe concatenated with the code of other gadgets the user has enabled)
Actual result
No result from the gadget I want. Tested with Iceweasel 38.1.0 (and the analogous procedure on Google Chrome 44).

I believe this might be due to some recent change in MediaWiki, because I used to do this a lot some time ago. In case I'm just missing something, please close this as invalid (and kindly point me to a way to search over all JS code which is loaded in a page, for debugging scripts with Firefox).

Event Timeline

He7d3r raised the priority of this task from to Needs Triage.
He7d3r updated the task description. (Show Details)
He7d3r added subscribers: He7d3r, Krinkle, ori, matmarex.

Here is a screencast of my attempt to find the (default) gadget which loads the Teahouse script (on Chrome):
https://en.wikipedia.org/wiki/MediaWiki:Gadget-teahouse.js

Works for me.

The gadget is marked as default, but it was not check on Special:Preferences for me. Are you sure, that it is loaded? Type "mw.loader.getState( 'ext.gadget.teahouse' );" into the console, if you get ready it is loaded, if you get registered, it is not active for you.

Yes, since I was logged out, the module was loaded:

mw.loader.getState( 'ext.gadget.teahouse' );
"ready"

That gadget is just an example anyway, because it happens for others as well.

I also restored my preferences to default explicitly for testing this (but noticed the problem earlier, when I had many more gadgets/scripts running).

Hm.. It seems only happens after the page is loaded at least two times... o.O

This is probably caused by the gadget's script being cached in localStorage, and executed from there (basically using eval(), which tends to hide it in debuggers). Try doing mw.loader.store.clear() in the console and reloading the page, or using debug mode (?debug=1 in the URL).

Thanks! The search works after mw.loader.store.clear() + reload, but that will not be so useful to debug intermittent bugs. They might not happen in the next page load.
Also, debug mode is not reliable, because some errors are not reproducible in debug mode =/
T64605: ResourceLoader: Debug mode should not execute scripts in the global scope

I'm not sure what are clear criteria to judge whether this task is "resolved" at some point, especially given the provided input
@He7d3r: Could you clarify?

If there is an easy way to find, just after a JS error occurs in production mode (i.e. no debug mode, and without reloading the page), which risks not causing the error again), which part of which JS code contains a given string.

PS: I should add that I'm subscribed to the error events (by means of mw.trackSubscribe( 'global.error', function ( topic, err ) {...}). This way, I can notice when these errors happen, even if my console is not open.

matmarex renamed this task from Debugging gadgets is harder than ever: unable to find JS files containing a given string to Debugging gadgets is harder than ever: unable to find JS files containing a given string (because they execute from mw.loader.store).Aug 20 2015, 4:05 PM
matmarex set Security to None.
Krinkle renamed this task from Debugging gadgets is harder than ever: unable to find JS files containing a given string (because they execute from mw.loader.store) to JavaScript from mw.loader.store should be listed in browser's developer tools.Aug 28 2015, 10:46 AM
Krinkle triaged this task as Medium priority.
Krinkle moved this task from Inbox to Accepted Enhancement on the MediaWiki-ResourceLoader board.
Krinkle changed the task status from Open to Stalled.Dec 17 2015, 12:24 AM
Krinkle removed Krinkle as the assignee of this task.
Krinkle lowered the priority of this task from Medium to Low.Nov 18 2016, 7:16 PM

Declining per T90524. May be solved by T47514 instead.