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

NEW
Unassigned

Status

Testing
Marionette
a year ago
23 days ago

People

(Reporter: Titus Fortner, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {ateam-marionette-server})

45 Branch
ateam-marionette-server
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
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
Blocks: 721859
Keywords: ateam-marionette-server
Summary: title from nested browsing context → title from nested browsing context if frame is changed with target=_top
Summary: title from nested browsing context if frame is changed with target=_top → Getting top-level browsing context’s title from nested browsing context if frame is changed with target=_top does not work
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Depends on: 1349861
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.
Depends on: 1351738
You need to log in before you can comment on or make changes to this bug.