Closed
Bug 1200453
Opened 9 years ago
Closed 6 years ago
|marionette.switch_to_window| fails on e10s if you load an actual page
Categories
(Remote Protocol :: Marionette, defect)
Remote Protocol
Marionette
Tracking
(e10s+)
RESOLVED
DUPLICATE
of bug 1311041
Tracking | Status | |
---|---|---|
e10s | + | --- |
People
(Reporter: erahm, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
1.77 KB,
patch
|
Details | Diff | Splinter Review | |
2.36 KB,
text/plain
|
Details |
I discovered this in the e10s version of AWSY. What I'm seeing is:
#1 open a new tab
#2 select the tab
#3 navigate to a web page
#4 select the original tab
#5 select the new tab
This causes an exception:
> NoSuchWindowException: Unable to locate window: 26
Note: This is currently blocking the e10s version of AreWeSlimYet.
Reporter | ||
Comment 1•9 years ago
|
||
This updates the test_window_handles test case to actually load a page and cycle through them. To reproduce, apply the patch and run:
> marionette --e10s --binary path/to/firefox testing/marionette/client/marionette/tests/unit/test_window_handles.py
Reporter | ||
Comment 2•9 years ago
|
||
I should note: this used to work, so it feels like a "regression" on the Firefox side (not marionette-client/driver). The best I can guess for the range is roughly June 2015 - Aug 2015.
Comment 3•9 years ago
|
||
I'm pretty sure this is bug 1140237 -- we're using the underlying window id for marionette's window handles, and those aren't preserved when a tab's content is moved between processes. 'about:newtab' is still in-process for now, so navigating to the data: uri in the test case changes process, and the old window handle for the new tab is invalidated. I'm not sure why this would be a recent regression. The workaround is to re-determine the set of open window handles from marionette.window_handles after the navigation that changes process.
Comment 4•9 years ago
|
||
This adds some logging to illustrate the issue and applies the workaround to make the test pass.
Updated•9 years ago
|
Blocks: e10s-tests
tracking-e10s:
--- → +
Comment 5•6 years ago
|
||
I believe htis has been resolved, but marking it as a duplicate of the window tracking refactoring just in case, which should definitely handle this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•