Last modified: 2006-03-26 08:35:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5236 - Load ../wikibits.js before ../Monobook.js
Load ../wikibits.js before ../Monobook.js
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://als.wikipedia.org/w/index.php?...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-13 00:48 UTC by Melancholie
Modified: 2006-03-26 08:35 UTC (History)
1 user (show)

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


Attachments

Description Melancholie 2006-03-13 00:48:05 UTC
Maybe there is a reason why wikibits.js is loaded after the Monobook.js is being
generated (see HTML source), but if not it would be good if the "global"
wikibits.js could be loaded before Monobook.js and User/monobook.js!

This would reduce redundancy, as this rendering order would offer us to use some
variables that are used in wikibits.js, and we especially could use the function
"hookEvent"; see the given URL.
Comment 1 Brion Vibber 2006-03-16 23:48:29 UTC
Ok, wikibits.js now loaded first.

Warning: previously cached pages have it the other way around, so be careful about 
MediaWiki:Monobook.js. In your user JS you can be more wacky.
Comment 2 Christian Thiele 2006-03-23 13:21:09 UTC
This is not good. The generated javascript file (/w/index.php?title=-&action=raw&gen=js) has to be 
before wikibits.js: It generates the variables skin and stylepath, which are used in wikibits.js to 
load browser specific css patches for Opera and KHTML - these are now not loaded.
Comment 3 Christian Thiele 2006-03-23 13:27:58 UTC
By the way: Opera 9 supports the new CSS 3 selector ^=. So there should be a new Opera9Fixes.css, because 
overwriting the normal stylesheet for external links results in having external.png behind every link 
(also https, mailto etc.). In previous Opera versions this is fine, but for Opera 9 this is not good.
Comment 4 Brion Vibber 2006-03-23 19:52:55 UTC
That would be a separate issue (eg, some variables being set in the wrong place).
Comment 5 Melancholie 2006-03-24 01:13:25 UTC
Christian Thiele is right.
At the top of http://en.wikipedia.org/w/index.php?title=-&action=raw&gen=js
there is var skin = 'monobook'; and var stylepath = '/skins-1.5';

Those variables are used in wikibits.js under "document.write special stylesheet
links"! Is there a better way of defining those two variables? Maybe directly in
the html source? Or could you separate the generated .js from Monobook.js in
some way?
Comment 6 Brion Vibber 2006-03-24 01:52:10 UTC
Those definitely belong in the page source; putting them in a separate .js is unreliable, 
and may be the cause of the bogus requests we see in logs, if one fails and the other 
doesn't .
Comment 7 bdk 2006-03-24 09:25:33 UTC
... just leaving a note here on a now separated bug:
Bug 5342 "Missing link icons in Opera"
Comment 8 Melancholie 2006-03-26 08:35:43 UTC
Bug 5355: "Put the JavaScript variables "skin" and "stylepath" 
into the html page source"

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


Navigation
Links