The "Drop media file to donate here" button (second screen of the UploadWizard) will sometimes fail to bring up the file dialog (in Chrome; possibly other browsers)
Repro:
Eventually, when you click, it won't come up.
Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63053
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T33217 MediaWiki bugs to be fixed for 1.19wmf1 deployment (tracking) | |||
| Resolved | • brion | T36601 "Drop media file to donate here" sometimes silently fails |
r112166 seems to reduce it but not eliminate it entirely -- adds a second ping to moveFileInputToCover() 50ms after the first one.
It seems that the error in positioning happens mostly when the styles haven't been applied yet when we start creating the UI; a visibile flash of text from the learn/upload/release/etc step list shows, then things move into their final positions... but the file input has been positioned relative to something else and no longer fits over the button.
Thanks for looking at this one Brion. I tried this 20 times, and it failed once, which isn't great, but I'm pretty sure is much better than before.
Per in-person chat w/ Robla & Roan there's a few more things I can check out (modules vs CSS load order, DOM manipulation order, or changing how the positioning gets done)...
I'm keeping the bug open pending further investigation.
r112229 loads the styles early; there is stuff in the original HTML though it's hidden until add'l styles are applied to it.
Everything *should* be fine since it's all hidden until we adjust it, and the styles and JS seem to be in the same package, so not sure why this even happens...
Haven't been able to repro the click bug on Commons since r112229 went live, but I still sometimes see the flash of unstyled text briefly so it could still happen. Sigh.
Additionally, if you change the window size it's possible for the file input and button to get out of sync in their positioning, making part of the button unclickable -- this is due to the way the positioning is being done as a one-off adjustment.
r112248 uses an interval timer instead of the earlier one-off timeout to update every half second as necessary. This should help with initial layout cases, but also helps with the layout changing due to the window being resized later.
Confirmed fixed, unable to repro the issue at this time (at worst it takes a tiny bit longer to respond to the click).