Last modified: 2013-06-13 23:17:15 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 T50091, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48091 - UploadWizard broken in Opera 12.15
UploadWizard broken in Opera 12.15
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
unspecified
All All
: High critical with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-05 01:53 UTC by Erik Moeller
Modified: 2013-06-13 23:17 UTC (History)
8 users (show)

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


Attachments
HTML DOM of Special:UploadWizard in debug mode (74.21 KB, image/png)
2013-05-17 16:38 UTC, Rainer Rillke @commons.wikimedia
Details
HTML DOM of Special:UploadWizard in debug mode with JS disabled (7.40 KB, image/png)
2013-05-17 16:42 UTC, Rainer Rillke @commons.wikimedia
Details

Description Erik Moeller 2013-05-05 01:53:34 UTC
UploadWizard currently errors out on the first screen. Error console with debug mode enabled shows the error "Undefined variable: UploadWizardConfig" is triggered in line 24 of mw.LanguageUpWiz.js. This is with Opera 12.15 on Ubuntu.
Comment 1 indeedous 2013-05-06 11:43:32 UTC
The same problem with XP and Win7 with Opera 12.15 (Build 1748). UploadWizard doesn't work at all for about 1 week.
Comment 2 Gerrit Notification Bot 2013-05-06 19:56:02 UTC
Related URL: https://gerrit.wikimedia.org/r/62480 (Gerrit Change Iaf23ae56d610471a8ac2b49b303a96adb957cd48)
Comment 3 Nischay Nahata 2013-05-06 21:06:31 UTC
The change is based just on the error shown above and has to be verified with the browser. I don't have a Opera installation yet.
Comment 4 Nischay Nahata 2013-05-16 12:43:46 UTC
I updated my copy of UW and the error didn't show, then updated core to master and its there. The patch doesn't solve the problem for me.
Comment 5 Rainer Rillke @commons.wikimedia 2013-05-17 16:38:29 UTC
Created attachment 12331 [details]
HTML DOM of Special:UploadWizard in debug mode

If you set the config *after* calling mw.loader.load for ext.uploadWizard, this might happen:
* Browser sees "mw.loader.load"
* RL creates script tags and inserts them directly after the script node containing the call (creating new script nodes which are above the config)
* Browser loads all these scripts (requested by RL) synchronously and "sees" the UpWiz config after all scripts have been loaded. Most browsers do this async for scripts inside <body> now, but Opera might behave differently.

As soon as mw.config is available, the UpWiz config can be set.

UpWiz config is shipped directly within the HTML (no separate script). Since mw.config is available as soon as the head-scripts are loaded (which always happens synchronously [except when using a special attribute]) and UpWiz config contains only constants, you can put it directly at the beginning of the body or better, as the last node into the head.

I will upload another image showing the HTML DOM of a browser having JS disabled. You will see that, indeed Opera wrote all script requests directly below the call to mw.loader which is highlighted here.
Comment 6 Rainer Rillke @commons.wikimedia 2013-05-17 16:42:47 UTC
Created attachment 12332 [details]
HTML DOM of Special:UploadWizard in debug mode with JS disabled
Comment 7 Rainer Rillke @commons.wikimedia 2013-05-17 17:41:46 UTC
Well, all this requires messing with OutputPage.php or https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/UploadWizard.git;a=blob;f=includes/specials/SpecialUploadWizard.php;hb=master#l212
with which I am not familiar and therefore exceeds my time limit.
Comment 8 Nischay Nahata 2013-05-19 04:45:38 UTC
(In reply to comment #5)

So you suggest that the config should be added into the head, I can try this but how is this done? currently its being added using
		$this->getOutput()->addScript(
Comment 9 Derk-Jan Hartman 2013-05-19 10:35:39 UTC
I think this is what you would want for that: http://www.mediawiki.org/wiki/Manual:Hooks/MakeGlobalVariablesScript
Comment 10 Nischay Nahata 2013-05-19 14:10:34 UTC
(In reply to comment #9)
> I think this is what you would want for that:
> http://www.mediawiki.org/wiki/Manual:Hooks/MakeGlobalVariablesScript

I tried to hack in https://gerrit.wikimedia.org/r/#/c/64520/ but didn't work in Opera yet.
Comment 11 Rainer Rillke @commons.wikimedia 2013-05-29 21:11:39 UTC
(In reply to comment #10)
> I tried to hack in https://gerrit.wikimedia.org/r/#/c/64520/ but didn't work in
> Opera yet.

Please be more specific: What did not work?

Here is what I did:
1) Installed a local proxy (Fiddler2)
1a) Configurated Opera to use the local proxy
1b) went to http://commons.wikimedia.org/wiki/Special:UploadWizard in Opera
2) Dumped the UploadWizard HTML page
3) Enabled auto-response for UploadWizard from the dump; other requests were passed through to the WMF servers
4) Verified that the Upload Wizard still "hangs" and threw the same error at the JS Error console
5) MODIFIED THE DUMP:
5a) Moved 
<script>if(window.mw){
mw.config.set({"UploadWizardConfig":{ [...]
    directly before the loading call
<script>if(window.mw){
mw.loader.load(["mediawiki.htmlform","ext.uploadWizard"
 AND IT WORKED!
5b) Moved the config into the head but below the other config so it looks like this:
<script>if(window.mw){
mw.config.set({"wgCanonicalNamespace":"Special" [...]
<script>if(window.mw){
mw.loader.implement("user.options" [...]
<script>if(window.mw){
mw.config.set({"UploadWizardConfig":
 AND IT WORKED!

Conclusion: There are many points where you can insert the config, you just have to care that:
a) mw.config is there
b) it must be *before* telling RL to load ext.UploadWizard

Is this that difficult? Isn't there anyone who developed this OutPage.php monster?
Comment 12 Nischay Nahata 2013-05-30 06:08:33 UTC
(In reply to comment #11)
> Please be more specific: What did not work?

My comment could be understood if you read the previous comments in that order.
Anyways, I tried to put the config variable above the load calls in a *hacky* way and couldn't make it work on Opera; that's what I meant.
Comment 13 Rainer Rillke @commons.wikimedia 2013-05-30 11:05:28 UTC
(In reply to comment #12)
> and couldn't make it work on Opera
Sorry for the misunderstanding. I would be still curious what the issue was exactly. Was the error message in Opera Dragonfly the same? Did you inspect the HTML DOM before and after it was altered by the JS engine?
Comment 14 Gerrit Notification Bot 2013-06-05 14:36:07 UTC
Related URL: https://gerrit.wikimedia.org/r/67090 (Gerrit Change I14b231bfb73e8382c59f34331b822837c651a34e)
Comment 15 Nischay Nahata 2013-06-05 14:37:40 UTC
(In reply to comment #14)
The following change demonstrates possible solution
Comment 16 Rainer Rillke @commons.wikimedia 2013-06-05 15:02:29 UTC
(In reply to comment #15)
Both provided "solutions" are a no-go. 

Timeouts and listening for DOMready are not suitable checks for determining whether a script was executed. jQuery event listeners may be but since the UpWiz config is written directly into the output page, it must be possible to place it before the loader-call.
Comment 17 Nischay Nahata 2013-06-05 15:06:06 UTC
(In reply to comment #16)
Actually they aren't solutions, but more of a analysis of the problem.
Surely the config should be before the load call but I was able to see different results on Chrome and Opera confusing me what the fix would be.

On Opera I was seeing window.load getting called while on Chrome both were getting called.
Comment 18 Gerrit Notification Bot 2013-06-13 18:31:21 UTC
Related URL: https://gerrit.wikimedia.org/r/68475 (Gerrit Change Ia09ace5dc985524634ee2c225207ee5050a046c2)
Comment 19 Mark Holmquist 2013-06-13 23:17:15 UTC
Fixed, deployed to commons, reopen if you see more problems.

Thanks all!

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


Navigation
Links