1255946 - Getting top-level browsing context’s title from nested browsing context if frame is changed with target=_top does not work

Status: RESOLVED DUPLICATE of bug 1493108

(Remote Protocol :: Marionette, defect, P2)

Description

[Titus Fortner]

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

Comment 1

[Andreas Tolfsen ❲:ato❳]

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

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 3

[Andreas Tolfsen ❲:ato❳]

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.

Comment 4

[Andreas Tolfsen ❲:ato❳]

(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.

Comment 5

[Andreas Tolfsen ❲:ato❳]

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.

Comment 6

[Titus Fortner]

If it matters, the current error I'm getting for this is: Selenium::WebDriver::Error::UnknownError: TypeError: can't access dead object

Comment 7

[Andreas Tolfsen ❲:ato❳]

Thanks for the update: it does matter.  I am inclined to say this
depends on https://bugzilla.mozilla.org/show_bug.cgi?id=1311041
because it will change virtually every aspect about how we deal with
windows and browsing contexts in Marionette.

However, the work I’m doing on that bug explicitly does not make
any conformance improvements.  On the contrary, it in fact works
around known problems just so it can pass the tests.  I will follow
up after that has landed to resolve WebDriver conformance issues
with window management.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Andreas Tolfsen ⦗:ato⦘ from comment #4)

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.

That issue has been closed a while ago with the following update of the spec:
https://github.com/w3c/webdriver/pull/932/files

It means that accessing the title of the top-level browsing context requires a context change by the user. Automatically switching the browsing context will not be done.

Titus, not sure if you still have this testcase around. If yes, does switching to the top frame first fix your problem?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

With bug 1493108 fixed at some point a proper error message will be thrown.