Instead of wiping the old toolbar out on the server side we now just wrap the old toolbar in a div that has an inline style that prevents it from being displayed. This is only done when the toolbar is enabled. When the toolbar code runs on the client, if the toolbar ends up being incompatible, the old toolbar's wrapping div is shown. This avoids the side-effect of the old toolbar showing up momentarily while the new toolbar loads. It's a dirty hack, but we explored this extensively and it's the least evil way we could come up with that worked consistently.
Change-Id: I6fefadea4dbd01b96a0b95c50bc9ef526144dc3c
This is still broken in production right now: the preference message is
missing and disabling the preference doesn't disable the toolbar.
Reverting this because it just doesn't work right now.
This reverts the following commits:
4234c5ddc7 "Fix syntax error in I1adc6b99fa3e1980d4ce3c565b5f193bcbceb526"
00eee72543 "modified as per bug 35879"
00eee72543 "(bug 30796) Dropping preferences for toolbar"
Change-Id: I882a6e0c0cc70f9afecb49746f3db01eab8808dc
Re-added the preference for toolbar I had removed by mistake in change 4339
made global=false and user=true for toolbar,as it was before my changes
for dialogs global=true and user=false is retained as now the user cannot
control dialogs in preferences and it is always on
Patchset 3 (Roan): enable WikiEditor preference by default
Change-Id: I1adc6b99fa3e1980d4ce3c565b5f193bcbceb526
* I left MwEmbed alone since it was scary.
* I left the half-completed commented-out ResourceLoader code in Maps as it was
* PrefSwitch was apparently broken, with a typo in remoteBasePath.
* ClickTracking and ProofreadPage now demostrate two different styles of multi-module registration. Choose which one you prefer.
* SemanticMediaWiki/SMW.hooks.php became empty and was deleted.
* Tested using a special script that includes extension setup files and checks $wgResourceModules for correctness.
What actually happens here
* Add $localBasePath, $remoteBasePath params to the FileModule constructor, defaulting to $IP and $wgScriptPath respectively
* Add getLocalPath() and getRemotePath(), which use this information to build a proper FS or URL path for a file
* Make readScriptFiles() non-static so it can use these functions
* Run every single file path we use through either getLocalPath() or getRemotePath() as appropriate
** Except file dependencies, these are already prefixed. Our inability to give them special treatment caused bugs earlier
* Kill prefixFilePathList() and resolveFilePath(), no longer needed
* Abstracted the requirements concept being used to hack in the iframe as a context extension requirement
* Removed some hardcoding for iframe stuff
* Moved about 60k of JavaScript code out of the main wikiEditor script, and into an iframe only context extension.
