This has happened 5 times over the weekend, doesn't seem like a temporary issue. It only seems to affect Chrome. First thing I'll check is if it's another instance of rotten cached API result on beta.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Switch Media Viewer Chrome browser test to OS X | integration/config | master | +1 -0 |
Related Objects
Related Objects
Event Timeline
Comment Actions
I can reproduce the issue on saucelabs with Linux Chrome. The download menu never comes up. I can't reproduce the issue locally with OS X Chrome. I'll try to install Ubuntu in a vm to check if it's an issue specific to tests or if all linux users of Chrome 40 would be affected.
Comment Actions
So far it resembles an issue that I thought had been fixed by pointing to the newer version of Chrome. The tooltip for the download menu shows up, but the menu doesn't open at all in the testing environment. It seems random, as it might work totally fine in the subtest just before or after the current one.
I couldn't reproduce the issue manually in Ubuntu.
If these issues persist and I find no way of reproducing them in Linux manually, I might switch our Chrome tests to OS X to see if they are more stable.
Comment Actions
Alright, switching to OS X or Windows for the Chrome tests, I've tried as hard as I could to reproduce this manually in Linux Chrome, to no avail.
Comment Actions
Change 197293 had a related patch set uploaded (by Gilles):
Switch Media Viewer Chrome browser test to OS X
Comment Actions
This still seems to happen as a timeout on OS X Chrome: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-os_x_10.9-chrome-sauce/3/testReport/junit/%28root%29/Download%20menu/Attribution_area_can_be_closed/
Comment Actions
Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.