If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Windows opened due to an action outside of marionette are not reflected in marionette's set of window handles

RESOLVED DUPLICATE of bug 941749

Status

Testing
Marionette
RESOLVED DUPLICATE of bug 941749
3 years ago
3 years ago

People

(Reporter: chmanchester, Assigned: chmanchester)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
This is probably usually something of an edge case, but when we do something that results in a window opening, we sometimes don't end up with a reference to that window, so we can't switch to it and activate marionette for further testing. Mozmill tests do this sort of thing from time to time.
(Assignee)

Comment 1

3 years ago
Created attachment 8520846 [details] [diff] [review]
Test case demonstrating the issue

Test case demonstrating the issue. My reading of the webdriver spec is that we should know about the newly opened tab. Is that right? If not, we might need some other notion of "activating" marionette in certain windows to convert mozmill tests.
Attachment #8520846 - Flags: feedback?(dburns)
(Assignee)

Updated

3 years ago
Assignee: nobody → cmanchester
Status: NEW → ASSIGNED
If a window has been opened in a browser that has a marionette server session active then we need to know about it. If say we have a new window created via something that doesnt speak to marionette server then if we don't know about it then it's ok to not know about it.
(Assignee)

Comment 3

3 years ago
(In reply to David Burns :automatedtester from comment #2)
> If a window has been opened in a browser that has a marionette server
> session active then we need to know about it. If say we have a new window
> created via something that doesnt speak to marionette server then if we
> don't know about it then it's ok to not know about it.

In this case I think we need to know about the newly opened window, but I would appreciate feedback on the test case because it could be a grey area.
I wonder if this is a dupe of bug 941749
(Assignee)

Comment 5

3 years ago
(In reply to David Burns :automatedtester from comment #4)
> I wonder if this is a dupe of bug 941749

I'd say it is!
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 941749
I'm confused! So what is the relationship between window_handles and available tabs inside a browser window? The testcase as attached here opens a new tab but not a new window.
Flags: needinfo?(dburns)
A tab is a window too. It's a child window and not the HNWD. Please read http://w3c.github.io/webdriver/webdriver-spec.html#widl-WebDriver-getWindowHandles-sequence-DOMString.
Flags: needinfo?(dburns)
So how are you able to get the real number of top-level windows then? I was not able to find something in that referenced document. This is somewhat important for Mozmill related tests. Tabs are not windows in chrome scope.
Flags: needinfo?(dburns)
you'll always be able to be able to execute javascript to find out that we can wrap on the client side. FOr the most part people will want to switch top browsing contexts which means tabs and we should cater for that
Flags: needinfo?(dburns)
Comment on attachment 8520846 [details] [diff] [review]
Test case demonstrating the issue

Review of attachment 8520846 [details] [diff] [review]:
-----------------------------------------------------------------

clearing flag since we have a dupe and I commented
Attachment #8520846 - Flags: feedback?(dburns)
You need to log in before you can comment on or make changes to this bug.