Closed Bug 1255946 Opened 9 years ago Closed 5 years ago

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

Categories

(Remote Protocol :: Marionette, defect, P2)

Product:
Remote Protocol
Component:
Marionette
Version:
45 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1493108

People

(Reporter: titus.fortner, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: pi-marionette-server)

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
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.
Depends on: marionette-window-tracking
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)

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

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(titus.fortner)
Resolution: --- → DUPLICATE
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.