ChromeDriver does not switch back to top frame after navigation events

[GoogleCodeExporter]

If you browse to a page, switch to an iframe, and then navigate to the same URL 
(using either the navigate, refresh, or back/forward commands), and then try to 
find an element in the top frame, a "no such element" error will be returned. 
This is due to ChromeDriver not switching back to the top frame after 
navigation.

Steps to repro:

driver.get('http://ci.seleniumhq.org:2310/common/alerts.html')
driver.switch_to.frame('iframeWithAlert')
driver.get('http://ci.seleniumhq.org:2310/common/alerts.html')
driver.find_element_by_id('alert').click()

This should result in a "no such exception" error, because the element with 
id="alert" is on the top frame, but ChromeDriver is looking at the 
"iframeWithAlert" frame.

Alernative ways to repro:

1. replace the second call to get() with:
  - driver.refresh()

2. replace the second call to get() with:
  - driver.get('http://google.com')
  - driver.back()

This causes avalanching test failures when two separate tests run 
one-after-the-other, and the first test switches frames.

Original issue reported on code.google.com by samu...@chromium.org on 22 May 2015 at 10:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Previously we had relied on ExecuteWindowCommand() to implicitly switch back to 
the top frame whenever the execution context changed, but it seems the 
execution context no longer changes when returning to a page with the same URL 
as before:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/test/chromedri
ver/window_commands.cc&q=window_commands.cc&sq=package:chromium&type=cs&l=218

The solution here is to explicitly switch to the top-level frame whenever we 
navigate anywhere. This matches the behavior of the current FirefoxDriver.

Original comment by samu...@chromium.org on 22 May 2015 at 10:18

[GoogleCodeExporter]

Issue 1124 has been merged into this issue.

Original comment by samu...@chromium.org on 11 Jun 2015 at 7:17

[GoogleCodeExporter]

To be clear in this issue (as I mention in Issue 1124), as far as I know, this 
started reproducing with Chrome 44 desktop (not yet sure about android/iOS).

Original comment by vlotoshn...@gmail.com on 11 Jun 2015 at 10:48

[GoogleCodeExporter]

Also for reference here: https://codereview.chromium.org/1157763003 is a fix.

Original comment by vlotoshn...@gmail.com on 11 Jun 2015 at 10:51

[GoogleCodeExporter]

Sam, I am preparing a pull request for the w3c standard.
I am going to propose that all of get(), refresh(), back(), forward() MUST end 
up in the http://www.w3.org/TR/html5/browsers.html#top-level-browsing-context
Let me know if you think otherwise.

Original comment by vlotoshn...@gmail.com on 11 Jun 2015 at 11:00

[GoogleCodeExporter]

Sounds good to me.

Original comment by samu...@chromium.org on 11 Jun 2015 at 11:06

[GoogleCodeExporter]

https://github.com/w3c/webdriver/pull/100

Original comment by vlotoshn...@gmail.com on 12 Jun 2015 at 1:31

[GoogleCodeExporter]

Original comment by samu...@chromium.org on 18 Jun 2015 at 7:25

• Changed state: Fixed
• Added labels: ChromeDriver-2.16