Visit https://en.m.wikipedia.org/wiki/Book?mobileaction=stable#/media/File%3ABook_Collage.png and look for the close icon. You can't find it. It's in the DOM though. Happens both in stable and beta.
Description
Details
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
mediawiki/extensions/MobileFrontend | master | +2 -2 | Use the correct image variant in overlay and drawer |
Related Objects
Event Timeline
<button title="" class="mw-ui-icon mw-ui-icon-close-gray mw-ui-icon-element cancel">Close</button>
Stylesheet lacks any definition of foreground and background colors.
@Danny_B this bug is about the MobileFront MediaViewer, not the MultimediaViewer extension. Is it OK if I remove the tag MediaViewer?
Sure. If the MediaViewer is not handling any single piece of the code which is relevant to this task. It is always better to tag tasks with assumed tags to improve their discoverability, which in case they are not relevant can be removed anytime, but finding a task which is not tagged with proper tag is harder. Hence why I added certain tags.
Change 303377 had a related patch set uploaded (by Bmansurov):
Use the correct image variant in overlay and drawer
Change 303377 merged by jenkins-bot:
Use the correct image variant in overlay and drawer
Fixed! To test please visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Bukhara#/media/File%3AKalon-Ensemble_Buchara.jpg and look for the close icon.
Signing off.
Checked on desktop FF, Opera, Chrome, Safari. Checked on phone iOS 9 Safari, tablet simulator iOS 9 Safari, Android 5 Chrome, Android 5 Opera Mini (no compression), UC Browser (no compression), Windows Mobile 7.5 IEMobile on both orientations and LTR+RTL.
<noscript>/compression browsers were out of scope here.
Windows Mobile 7.5 IE continues to face problems of garbled rendering on RTL (not tofu, the blocks are scrambled), so that wasn't testable, but despite some pain with cert warnings the LTR MediaViewer showed the X button correctly.
Samsung Wave II (SamsungMobile) wasn't pulling up the MediaViewer properly on the beta cluster, but it worked fine on production. I have a hunch this won't be a problem on the stable channel, so can accept this risk for now.