What it looks like if you close MediaViewer. Yes, I uploaded a screenshot of a black tab.
Expected result: MediaViewer closes.
Obtained result: That tab is now a completely black screen, and it cannot be dismissed.
Version: unspecified
Severity: normal
Attached:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T72756 MediaViewer: Closing MediaViewer results in black, undismissable page | |||
| Declined | Krinkle | T72772 Errors in one module can affect other modules via $.ready |
Weird... https://wikimediafoundation.org/wiki/Staff_and_contractors?showall=1 works but the template does not.
Same issue as https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/825 : the domready handler in mmv.bootstrap.autostart.js is never called, even though the $(document).ready(handler) call itself is executed.
Well, not quite the same issue because that was Firefox-specific and this can be reproduced in Chrome. But the underlying issue is the same: something removes domready event handlers.
Given that the error is specific to this page, it might be related to the script embedded in the template to show/hide departmental lists (which works on the staff page but errors out on the template page). I really don't see how though. The error can be reproduced in debug mode, so it can't be errors in one script affecting other scripts due to ResourceLoader concatenating them.
It seems that fundamental jQuery behavior differs between the two pages. On [[wmf:Staff and contractors]]:
$(document).ready( function() { console.log('!'); });
// !
On [[wmf:Template:Staff and contractors]]:
$(document).ready( function() { console.log('!'); });
// no output
so some script might be messing with jQuery internals.
More specifically, $.ready.promise().done(cb) fires on the staff page but not the template page, even though $.ready.promise().state() returns
This is jQuery bug #10251 [1] (wontfixed). Basically, when a $(document).ready() handler has an error, all subsequent handlers fail to run. Given that gadgets are usually loaded before exceptions, this is bad and a generic solution is needed; but since that looks hard, and this issue affects MediaViewer in a rather severe way (a couple users complained about a BSOD - they were probably using broken user scripts which prevented the loading of the MediaViewer event handler which removes the black overlay), we should probably implement a local workaround.
gerritadmin wrote:
Change 160028 had a related patch set uploaded by Gergő Tisza:
Make sure event handlers are set up even if onready handler is lost
gerritadmin wrote:
Change 160028 merged by jenkins-bot:
Make sure event handlers are set up even if onready handler is lost
gerritadmin wrote:
Change 160413 had a related patch set uploaded by Gergő Tisza:
Make sure event handlers are set up even if onready handler is lost
gerritadmin wrote:
Change 160415 had a related patch set uploaded by Gergő Tisza:
Make sure event handlers are set up even if onready handler is lost
gerritadmin wrote:
Change 160413 merged by jenkins-bot:
Make sure event handlers are set up even if onready handler is lost
gerritadmin wrote:
Change 160415 merged by jenkins-bot:
Make sure event handlers are set up even if onready handler is lost
Works after pushing out the patch via SWAT.
The underlying issue (local site JS onready handlers throwing errors will prevent onready handlers of extensions from being called) is tracked as bug 70772.