| DanielFriesen | |
| Feb 11 2011, 8:44 AM |
| F7426: work.diff | |
| Nov 21 2014, 11:24 PM |
Something is wrong with the resource loader. Tabs are broken in Special:Preferences when resource loader is in debug mode, but not when debug mode is off.
I haven't examined it yet, but it's one of three things:
Version: 1.18.x
Severity: normal
URL: http://translatewiki.net/wiki/Special:Preferences?debug=0
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T28439 Deploy updated WMF branch to production (February 2011) | |||
| Resolved | None | T28676 Milestone: MediaWiki 1.17 release tarball (tracking) | |||
| Resolved | None | T28611 Bugs that should be fixed for 1.17 WMF deployment (tracking) | |||
| Resolved | Krinkle | T29321 Loading modules with a relative remote base path broken in debug mode |
reachouttothetruth wrote:
The search box, the editing toolbar, and probably other JavaScript stuff is also broken in debug mode. I tried hunting this down yesterday, but failed to discover the origin of the problem. I'll keep looking.
Not related to preference script. in trunk no javascript is loaded at all except for jquery and the module implementation calls.
The script that adds the individual <script> tags (mw.loader.load('/w/resources....') is not adding the tags.
Created attachment 8130
Provisional fix to mediawiki.load
This fixes it for me, but I'm not sure it's the correct fix.
In debug mode, the loader chunks get replaced with attempts to load the specific URLs; however only module "names" beginning with 'http:' or 'https:' actually get loaded this way. Since we were receiving local urls like this:
mediaWiki.loader.implement("mediawiki.legacy.mwsuggest", function( $, mw ) {mediaWiki.loader.load("/trunk/skins/common/mwsuggest.js");
they were getting added to a modules list and then just never work.
Checking also for module "names" that start with "/" and loading them as local URLs appears to work, but I'm not sure if it's wise. Should full URLs be used instead?
Attached:
Bug caused by regression in r81731; added a note on code review there to check whether reverting that or adding this is better fix.
Changing summary of the bug to reflect the issue.
Checking the live site I see that resources from mediawiki.legacy and extensions are loaded fine, even in debug mode. Because those have $wgStylePath and $wgExtensionAssetsPath in front of them which, in case of Wikimedia, starts with http:// (http://bits.wikimedia.org/ ...etc. )
Since resources could point to a full url prefixing wgServer in all cases is not good. So Brion's suggestion in Code Review comments: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81731#c14121 sounds like a good idea.
(changing assignee so I can easily find a bugs if I know that I fixed them with BugZilla's search engine)