Page MenuHomePhabricator

Upstream: Issue with Chrome driver with resizing window
Closed, DeclinedPublic

Description

this seems likely to be an issue with SauceLabs and/or ChromeDriver, the @browser.window.resize_to command seems to have just stopped working for Chrome on SauceLabs, even though it works locally.

Confirmed as upstream bug: https://code.google.com/p/chromedriver/issues/detail?id=1036

Event Timeline

Jdlrobson created this task.Feb 2 2015, 3:09 PM
Jdlrobson raised the priority of this task from to Needs Triage.
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Jdlrobson.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 2 2015, 3:09 PM
zeljkofilipin triaged this task as Normal priority.Mar 25 2015, 1:47 PM
zeljkofilipin set Security to None.

@Jdlrobson: I do not know. You are the one that reported the bug, I did not have the time to investigate.

Jdlrobson closed this task as Resolved.Apr 16 2015, 3:47 PM
Jdlrobson claimed this task.

@chrismcmahon was working on this - he said that this was the reason MobileFrontend's browser tests for overlays were failing. I can't see any clues this is still happening so I assume this was an upstream bug and got fixed in new Chrome driver release

greg moved this task from Inbox to Done on the Browser-Tests-Infrastructure board.Apr 16 2015, 4:14 PM

Change 217588 had a related patch set uploaded (by Jdlrobson):
Enable test on Chrome

https://gerrit.wikimedia.org/r/217588

Change 217588 merged by jenkins-bot:
QA: Enable test on Chrome

https://gerrit.wikimedia.org/r/217588


Looks like width gets set but not height....

This appears to be a known issue with chromedriver and Chrome versions >= 40.[1] I was able to reproduce the bad behavior in SauceLabs with version 40,[2] and verify that the resize works as expected in version 39.[3]

One possible workaround would be to use browser_factory.override (MW-Selenium >= 1.3) to temporarily force the Chrome version to 39 for specific scenarios.[4] You'd probably want to implement it as a tag + hook to ensure that the configuration takes effect before the browser is opened—with MW-Selenium 1.x there's a factory system that delays the start of the browser session until it's first accessed with Environment#browser so this kind of runtime configuration is a lot easier than it used to be.[5]

Something like:

Before("@chrome-39") do
  browser_factory(:chrome).override(version: '39')
end

[1] https://code.google.com/p/chromedriver/issues/detail?id=1036
[2] SauceLabs, Chrome 40, https://saucelabs.com/tests/b63ee7a53d9b496f97e5199f1ad2c983
[3] SauceLabs, Chrome 39, https://saucelabs.com/tests/edfe4df30a6e45db98888d4775f8df94
[4] https://doc.wikimedia.org/rubygems/mediawiki-selenium/MediawikiSelenium/BrowserFactory/Base.html#override-instance_method
[5] https://doc.wikimedia.org/rubygems/mediawiki-selenium/MediawikiSelenium/Environment.html#browser-instance_method

We will discuss this task at the next browser tests triage meeting: https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Meetings/Notes

@Jdlrobson does that workaround make sense? Let me know if you want to pair on it.

I'd rather wait for the fix in Chrome, but it would be good to link to the upstream bug in the subject of this task so we know when we can remove the @skip tag. Since it works in Firefox I think we have sufficient coverage.

In future when we upgrade versions of the drivers could we be more careful to communicate this and check they do not impact builds, as I remember when this bug initially came up we were very confused.

Jdlrobson updated the task description. (Show Details)Jun 16 2015, 4:36 PM

In future when we upgrade versions of the drivers could we be more careful to communicate this and check they do not impact builds, as I remember when this bug initially came up we were very confused.

It wasn't an upgrade to any of the underlying libraries that we use that caused the issue but some interaction between chromedriver and the latest version of Chrome.

dduvall changed the task status from Open to Stalled.Jun 23 2015, 3:35 PM
hashar added a subscriber: hashar.
Jdlrobson renamed this task from Issue with Chrome driver with resizing window to Upstream: Issue with Chrome driver with resizing window.Jul 20 2015, 11:20 PM
hashar removed a subscriber: hashar.Jul 21 2015, 8:48 AM

I also seem to see the same issue with firefox on saucelabs. Causes like 1 or 2 failures per run for wikidata.

Jdlrobson moved this task from Backlog to Tracking on the MobileFrontend board.Mar 16 2016, 10:54 PM
Jdlrobson closed this task as Resolved.May 25 2016, 9:37 PM

I can only assume one year later that given this hasn't come up again this is no longer a problem.

JanZerebecki changed the task status from Resolved to Declined.May 26 2016, 9:15 AM

AFAIK it happens all the time on saucelabs, but as a non-free service I can't fix saucelabs.