User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Steps to reproduce: In the Watir tests, we have a set of nested frames (starting here: https://github.com/watir/watirspec/blob/master/html/nested_frames.html) A couple levels down there is this link. <a id="four" href="definition_lists.html" target="_top">this link should consume the page</a> Before the click there is no title in the top level browsing context. After the click there is, but it is not getting returned. I don't know if this might be an issue of not forcing a return to the top level browsing context after a navigation? https://gist.github.com/titusfortner/914b4fa4187c67733184 Actual results: no title returned Expected results: title should be returned
I am able to reproduce this, and the issue appears to be that the current browsing context reference (curContainer.frame) in testing/marionette/listener.js is not reset when a click causes navigation. I see this stacktrace in the console: > Full message: TypeError: can't access dead object > Full stack: getPageSource@chrome://marionette/content/listener.js:1152:3 > dispatch/</req<@chrome://marionette/content/listener.js:188:22 > TaskImpl_run@resource://gre/modules/Task.jsm:319:42 > TaskImpl@resource://gre/modules/Task.jsm:277:3 > asyncFunction@resource://gre/modules/Task.jsm:252:14 > Task_spawn@resource://gre/modules/Task.jsm:166:12 > dispatch/<@chrome://marionette/content/listener.js:186:15
And this is similar to what we discussed earlier for backward and forward navigation. Whenever frames are changing, or getting removed, the current context is invalid. It's close to impossible for the navigation to detect this. What we actually miss is the patch for bug 1349861, which would make it clear that the DOMwindow for the frame is not longer present after the navigation.
I think Selenium may have some special behaviour that resets the current browsing context when interacting with a link, or that the current browsing context is being reset automatically. According to the WebDriver standard, the ‘wait for navigation to complete’ algorithm should look at the _current browsing context_, which is only updated when the Switch To Frame command is called. This is clearly problematic if you click <a target=_top>, since the readiness target to be tested for should be the top-level browsing context.
(In reply to Henrik Skupin (:whimboo) from comment #2) > And this is similar to what we discussed earlier for backward and forward > navigation. Whenever frames are changing, or getting removed, the current > context is invalid. It's close to impossible for the navigation to detect > this. Well I think interaction-induced navigation is somewhat of a special case because the wait-for-page-to-load algorithm needs in any case to know which browser context to look at the document readiness of. I filed https://github.com/w3c/webdriver/issues/871 on WebDriver, which probably means we need to inspect the _target attribute of the link we’re clicking to know what to do. If the target is _top, we should look at the top frame’s/top-level browsing context’s document.readyState; in the case of _blank we should look at the new tab, and so on.
I wrote some more elaborate tests for Get Title which I have submitted independently of this in https://bugzilla.mozilla.org/show_bug.cgi?id=1351738.