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

NEW
Unassigned

Status

defect
P2
normal
3 years ago
3 months ago

People

(Reporter: titus.fortner, Unassigned, NeedInfo)

Tracking

(Blocks 1 bug, {pi-marionette-server})

45 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

3 years 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
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
Reporter

Comment 6

2 years ago
If it matters, the current error I'm getting for this is: Selenium::WebDriver::Error::UnknownError: TypeError: can't access dead object
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.
Priority: -- → P2

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

Flags: needinfo?(titus.fortner)
You need to log in before you can comment on or make changes to this bug.