"TypeError: browser.browsingContext is null" for WebDriver:GetWindowHandles when unloaded tabs are present
Categories
(Remote Protocol :: Marionette, defect, P3)
Tracking
(firefox-esr78 unaffected, firefox84 wontfix, firefox85 wontfix, firefox86 wontfix, firefox87 wontfix, firefox88 wontfix, firefox89 wontfix, firefox90 fixed)
People
(Reporter: MTRNord1, Assigned: whimboo)
References
(Regression, )
Details
(Keywords: regression, Whiteboard: [fission-])
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
System Setup (Maybe important?):
- Recent Manjaro
- Wayland (swaywm)
- Firefox 83
- geckodriver 0.28.0 (c00d2b6acd3f 2020-11-03 16:29 +0200)
- about 10 windows with around 140 tabs open
- Open firefox using "firefox --marionette" and make sure to set "MOZ_ENABLE_WAYLAND=1"
- Use "geckodriver --connect-existing --marionette-port 2828" to start the geckodriver.
- (From this on I used a rust binding (https://github.com/stevepryde/thirtyfour See also issue: https://github.com/stevepryde/thirtyfour/issues/34 ).
I assume steps from now on due to usage of that binding:
- Create a session
- Ask for window handles.
Actual results:
This is the error log using --log trace from geckodriver:
https://paste.ubuntu.com/p/thxdKRPDdB/
It returns Error 500 with "TypeError: browser.browsingContext is null" as a message.
Also when closing the tab selected when starting geckodriver it fails to find any window until it gets restarted. It seems to only see one tab.
Expected results:
It should have listed all tabs across all windows and workspaces.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Henrik, is this bug related to Fission (since this bug is related to browser.browsingContext
)? Does it need to block shipping Fission MVP?
Assignee | ||
Comment 2•4 years ago
|
||
Marcel, do you see the same with Firefox 84 beta, or Firefox Nightly? I would appreciate if you could take a look at those. So far we aren't aware of that problem.
Also do you have other windows open that are not browser windows, like downloads, library?
Reporter | ||
Comment 3•4 years ago
|
||
Hi I will check the beta and nightly. Might take a day or so as it is like 22:00 on my side of the world :)
No other firefox or thunderbird windows are open.
Assignee | ||
Comment 4•4 years ago
|
||
Please note that Firefox 84 will be released tomorrow. As such make sure that you are checking 84 and 85. Thanks.
Reporter | ||
Comment 5•4 years ago
|
||
I can confirm it works with Firefox 84 with a single window open (and a single tab). I will try tomorrow with the same windows/tabs again. Just did not yet move my firefox 83 profile over which has all the history to open them up easily.
Reporter | ||
Comment 6•4 years ago
|
||
It also fails on firefox 84 as soon as I have multiple tabs and windows open (started the profile I used on the firefox 83 version).
Going to try firefox 85 as well
Reporter | ||
Comment 7•4 years ago
|
||
With firefox 85 the error message slightly improved but the error itself still happens
β ~ geckodriver --log trace --connect-existing --marionette-port 2828
1607985943442 geckodriver INFO Listening on 127.0.0.1:4444
1607985948880 webdriver::server DEBUG -> POST /session {"capabilities":{"firstMatch":[{}],"alwaysMatch":{"browserName":"firefox"}},"desiredCapabilities":{"browserName":"firefox"}}
1607985948881 geckodriver::marionette DEBUG Waiting 60s to connect to browser on 127.0.0.1:2828
1607985948898 geckodriver::marionette DEBUG Connection to Marionette established on 127.0.0.1:2828.
1607985948913 webdriver::server DEBUG <- 200 OK {"value":{"sessionId":"0def1768-4f41-4c12-8e25-49c517b8ffb8","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"85.0a1","moz:accessibilityChecks":false,"moz:buildID":"20201214091023","moz:geckodriverVersion":"0.28.0","moz:headless":false,"moz:processID":94213,"moz:profile":"/home/marcel/.mozilla/firefox/j29h01b5.default-release","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"5.9.11-3-MANJARO","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1607985948915 webdriver::server DEBUG -> POST /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/timeouts {"script":60000,"pageLoad":60000,"implicit":30000}
1607985948919 webdriver::server DEBUG <- 200 OK {"value":null}
1607985948920 webdriver::server DEBUG -> GET /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/title
1607985948920 webdriver::server DEBUG <- 200 OK {"value":"Commits Β· Nucleon-eV/mitfahrbank-flutter"}
1607985948921 webdriver::server DEBUG -> GET /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/window
1607985948922 webdriver::server DEBUG <- 200 OK {"value":"94"}
1607985948923 webdriver::server DEBUG -> GET /session/0def1768-4f41-4c12-8e25-49c517b8ffb8/window/handles
1607985948924 webdriver::server DEBUG <- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: can't access property \"id\", browser.browsingContext is null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1450:15\nget@chrome://marionette/content/driver.js:249:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1495:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}
Assignee | ||
Comment 8•4 years ago
|
||
Could you please check if it is a special window or tab, which triggers that? I cannot explain why that happens, and I cannot reproduce it locally on MacOS. If you can't check that I could provide a special build of Firefox that adds more logging to the get window handles method.
Reporter | ||
Comment 10•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [βοΈUTC+2] (away 12/07 - 12/11) from comment #8)
Could you please check if it is a special window or tab, which triggers that? I cannot explain why that happens, and I cannot reproduce it locally on MacOS. If you can't check that I could provide a special build of Firefox that adds more logging to the get window handles method.
A Special build would be nice as it are quite many tabs to check :/
(In reply to Henrik Skupin (:whimboo) [βοΈUTC+2] (away 12/07 - 12/11) from comment #9)
Oh, and that started with Firefox 83, and wasn't visible with 82?
I did never have 82 on this system. So I dont know. to test I will check how to downgrade firefox on arch.
Assignee | ||
Comment 11•4 years ago
|
||
You can use https://github.com/mozilla/mozdownload to get older builds of Firefox from our servers. So no need for you to build yourself.
You can get mozdownload from https://pypi.org/project/mozdownload/.
Reporter | ||
Comment 12•4 years ago
|
||
One thing I am wondering about which started with firefox nightly is that the robot in the addressbar seems to only show in one of the windows (each on different workspaces in swaywm). Not sure if thats a seperate issue or contributed here or just a visual thing.
Assignee | ||
Comment 13•4 years ago
|
||
No, the robot should be present for all windows. And that is what I also cannot reproduce. Can you please provide some steps in how you get there? As best with a fresh profile. Did you download a nightly via mozdownload? Or where did you get it?
Reporter | ||
Comment 14•4 years ago
|
||
So the env itself is the same as before (wayland, swaywm, manjaro). The firefox nightly version is installed using https://aur.archlinux.org/packages/firefox-nightly/ . Each window is on another workspace and firefox-nightly is started using an exec inside of the sway config. Sway was started directly from the shell (no gdm or similiar).
Each window was opened with the firefox "autorestart" feature where it reopens the last open windows.
The exact command used is firefox-nightly -P default-release --marionette
. The profile given was my firefox 83 profile.
Please ask if any further information is needed. I will later today test firefox 82 and test with a fresh profile
Assignee | ||
Comment 15•4 years ago
|
||
Some other things to check:
- Does the same happen when you don't use the arch linux builds but always ours as downloadable via mozdownload?
- What happens when all browser windows are on the same workspace?
Reporter | ||
Comment 16•4 years ago
|
||
Still didn't get around to test ff82 due to homework I do today but as it just crashed (error reported using the error report tool) I was able to check behavior if they are all on the same workspace:
The behavior seems to be the same. Automation only shows on the first windows address bar instead of all of them.
Not surprising but I tested anyway -> geckodriver still does the same error.
Assignee | ||
Comment 17•4 years ago
|
||
For crashes you can go to about:crashes
and report them. Feel free to drop the URL here.
Otherwise thanks for the update and good to know that the workspaces aren't the problem. Let us know when you wre able to test older versions, so we might know if it is a regression.
Reporter | ||
Comment 18•4 years ago
|
||
The crash is https://crash-stats.mozilla.org/report/index/c647c1ba-5a92-4a91-807c-4ee180201217 . But I think it is unrelated to this.
Comment 19•4 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #1)
Henrik, is this bug related to Fission (since this bug is related to
browser.browsingContext
)? Does it need to block shipping Fission MVP?
(In reply to Marcel Radzio from comment #6)
It also fails on firefox 84 as soon as I have multiple tabs and windows open (started the profile I used on the firefox 83 version).
(In reply to Marcel Radzio from comment #7)
With firefox 85 the error message slightly improved but the error itself still happens
Since this bug is reproducible in Firefox 84 and 85, it's not a Fission bug (unless it's a regression from a Fission code change that is affecting non-Fission behavior).
Assignee | ||
Comment 20•4 years ago
|
||
Marcel, when you have some updates regarding your testing please let us know. Thanks.
Assignee | ||
Comment 21•4 years ago
|
||
No further response from reporter, and I cannot reproduce. I'm happy to reopen when the requested information has been provided.
Reporter | ||
Comment 22•4 years ago
|
||
Hi I am sorry for no response in a long time. I just didnt find any time to respond.
Also I in between had to reinstall my system and now am on Arch instead of Manjaro. On this new system it works flawless with firefox-nightly so I cannot reproduce my original bug sadly :/
Reporter | ||
Comment 23•4 years ago
|
||
Actually nvm I can still reproduce it. I can get the current url but not window handles:
Error: Standard(WebDriverError { error: UnknownError, message: "TypeError: can\'t access property \"id\", browser.browsingContext is null", stack: "", delete_session: false }}
Is returned when using firefox nightly, current geckodriver from master branch and https://github.com/jonhoo/fantoccini as rust client.
Geckodriver log is:
β ~ geckodriver --port 4444 --connect-existing --marionette-port 2828 --log debug
1612360768093 geckodriver INFO Listening on 127.0.0.1:4444
1612360769661 webdriver::server DEBUG -> POST /session {"capabilities": {"alwaysMatch":{"goog:chromeOptions":{"w3c":true},"pageLoadStrategy":"normal"},"firstMatch":[{}]}}
1612360769662 geckodriver::marionette DEBUG Waiting 60s to connect to browser on 127.0.0.1:2828
1612360769662 geckodriver::marionette DEBUG Connection to Marionette established on 127.0.0.1:2828.
1612360769669 webdriver::server DEBUG <- 200 OK {"value":{"sessionId":"71f82dc4-0124-4e8f-9125-f26f706c5ecb","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"87.0a1","goog:chromeOptions":{"w3c":true},"moz:accessibilityChecks":false,"moz:buildID":"20210130194115","moz:geckodriverVersion":"0.29.0","moz:headless":false,"moz:processID":123959,"moz:profile":"/home/marcel/.mozilla/firefox/j29h01b5.default-release","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"5.10.11-arch1-1","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1612360769670 webdriver::server DEBUG -> GET /session/71f82dc4-0124-4e8f-9125-f26f706c5ecb/url
1612360769677 webdriver::server DEBUG <- 200 OK {"value":"https://docs.rs/fantoccini/0.17.1/fantoccini/struct.Client.html#method.close"}
1612360769678 webdriver::server DEBUG -> GET /session/71f82dc4-0124-4e8f-9125-f26f706c5ecb/window/handles
1612360769679 webdriver::server DEBUG <- 500 Internal Server Error {"value":{"error":"un
known error","message":"TypeError: can't access property \"id\", browser.browsingContext is null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1465:15\nget@chrome://marionette/content/driver.js:255:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1510:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}
I will get back to testing now that I can reproduce it. I am using a minimal code for this: https://gist.github.com/MTRNord/443e2f3acce029fabd35b40da5d8b19d
The second call for windows is the one not working. the url always works. I will try to test the other requested things with that code
Reporter | ||
Comment 24•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [βοΈUTC+1] from comment #15)
Some other things to check:
- What happens when all browser windows are on the same workspace?
This seems to not make any difference in behavior. The bug stays exactly the same.
Reporter | ||
Comment 25•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [βοΈUTC+1] from comment #15)
Some other things to check:
- Does the same happen when you don't use the arch linux builds but always ours as downloadable via mozdownload?
Latest Beta from mozdownload: (86.0b5) and latest (85.0)
Error:
Error: Standard(WebDriverError { error: UnknownError, message: "TypeError: browser.browsingContext is null", stack: "", delete_session: false })
Logs from Geckodriver:
β ~ geckodriver --port 4444 --connect-existing --marionette-port 2828 --log debug 1612361897323 geckodriver INFO Listening on 127.0.0.1:4444
1612361899373 webdriver::server DEBUG-
> POST /session {"capabilities": {"alwaysMatch":{"goog:chromeOptions":{"w3c":true},"pageLoadStrategy":"normal"},"firstMatch":[{}]}}
1612361899373 geckodriver::marionette DEBUGWaiting 60s to connect to browser on 127.0.0.1:2828
1612361899389 geckodriver::marionette DEBUGConnection to Marionette established on 127.0.0.1:2828.
1612361899406 webdriver::server DEBUG<- 200 OK {"value":{"sessionId":"344f2b21-8ada-4d48-9525-5de18e42cb1e","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"86.0","goog:chromeOptions":{"w3c":true},"moz:accessibilityChecks":false,"moz:buildID":"20210202185823","moz:geckodriverVersion":"0.29.0","moz:headless":false,"moz:processID":129181,"moz:profile":"/home/marcel/.mozilla/firefox/j29h01b5.default-release","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"5.10.11-arch1-1","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1612361899407 webdriver::server DEBUG-> GET /session/344f2b21-8ada-4d48-9525-5de18e42cb1e/url
1612361899411 webdriver::server DEBUG<- 200 OK {"value":"https://de.wikipedia.org/wiki/Liste_mathematischer_Symbole"}
1612361899413 webdriver::server DEBUG-> GET /session/344f2b21-8ada-4d48-9525-5de18e42cb1e/window/handles
1612361899413 webdriver::server DEBUG<- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: browser.browsingContext is null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1465:15\nget@chrome://marionette/content/driver.js:255:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1510:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}
Firefox ESR (78.7.0esr)
Works without any problems and returns expected results.
Note: Everything was tested with the same code and same profile
Reporter | ||
Comment 26•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [βοΈUTC+1] from comment #9)
Oh, and that started with Firefox 83, and wasn't visible with 82?
I tried mozdownload 82.0b9 version too and it has the same error as I get with 86 and 85 I will go and try to step back until it works to pin point where it started
Reporter | ||
Comment 27•4 years ago
|
||
Ok I went back every version between 82 and 79.0b1 now. It seems that I get the error on all of them. It goes away on the esr version.
Assignee | ||
Comment 28•4 years ago
|
||
Thanks a lot for the details, and especially the regression check. Given that 78ESR is fine I had a look which changes went into the 79 release, and the only fix is from bug 1519335.
The change that caused it for you is:
https://hg.mozilla.org/integration/autoland/rev/db55b898e188#l2.103
So I assume that when this method gets called the content browser hasn't been created yet, and as such there is no browsing context available.
When you ignore the error and repeat the command does it eventually return the list of window handles, or is the failure permanent?
Reporter | ||
Comment 29•4 years ago
|
||
I will try that :) Going to let it run in a loop for some time and report back :)
Reporter | ||
Comment 30•4 years ago
|
||
I just noticed that sometimes the errors changes from:
windows: Err(
Standard(
WebDriverError {
error: UnknownError,
message: "TypeError: can\'t access property \"id\", browser.browsingContext is null",
stack: "",
delete_session: false,
},
),
)
to
windows: Err(
Standard(
WebDriverError {
error: UnknownError,
message: "TypeError: can\'t access property \"id\" of null",
stack: "",
delete_session: false,
},
),
)
It seems to happen a lot less than the first error.
Also not sure how often I should try but even after 1600 tries I had not once success. (Each time calling that endpoint in a loop)
Reporter | ||
Comment 32•4 years ago
|
||
Log at geckodriver from that other error is:
1612387138155 webdriver::server DEBUG -> GET /session/136b0885-5c5f-4b99-90fc-026200acb26b/window/handles
1612387138155 webdriver::server DEBUG <- 500 Internal Server Error {"value":{"error":"unknown error","message":"TypeError: can't access property \"id\" of null","stacktrace":"GeckoDriver.prototype.getIdForBrowser@chrome://marionette/content/driver.js:1465:15\nget@chrome://marionette/content/driver.js:255:28\nGeckoDriver.prototype.getWindowHandles@chrome://marionette/content/driver.js:1510:3\ndespatch@chrome://marionette/content/server.js:297:40\nexecute@chrome://marionette/content/server.js:267:16\nonPacket/<@chrome://marionette/content/server.js:240:20\nonPacket@chrome://marionette/content/server.js:241:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:504:20\n"}}
Assignee | ||
Comment 33•4 years ago
|
||
Wow, ok. So this is really, really puzzling. We have never seen such a problem in our own CI or locally when running any test.
So I was actually wrong above. getIdForBrowser()
clearly gets the content browser, and returns early if it's null
. In case it exists we then check if a content browser is already registered via its permanentKey
. But that's also not the case here given that we always fail to add the content browser to the cache:
Could you please do me a favor and test the following: When the call to get handles fails please suspend the test and manually open the browser toolbox (see web developer menu). It will allow you to interact with the chrome code of Firefox. There please open the web console and execute the following code: gBrowser.selectedBrowser.browsingContext
. Does that return a valid browsing context?
Reporter | ||
Comment 34•4 years ago
|
||
Web console is the one that is in every tab correct?
In that case I do get:
Uncaught ReferenceError: gBrowser is not defined
<anonymous> debugger eval code:1
Though I am not 100% sure if I am in the correct js console :)
Assignee | ||
Comment 36•4 years ago
|
||
No, I don't mean the web console. It looks like you will have to enable devtools.chrome.enabled
first in about:config
before you will see this menu item.
Whatever is broken here I'm sure that bug 1680479 should get rid of this problem.
Reporter | ||
Comment 38•4 years ago
|
||
Whoops I missunderstood the editor apparently. Lets try this again:
Result:
CanonicalBrowsingContext { currentWindowGlobal: WindowGlobalParent, topChromeWindow: ChromeWindow chrome://browser/content/browser.xhtml, currentRemoteType: "webIsolated=https://mozilla.org", embedderWindowGlobal: WindowGlobalParent, secureBrowserUI: XPCWrappedNative_NoHelper, webProgress: XPCWrappedNative_NoHelper, sessionHistory: XPCWrappedNative_NoHelper, mediaController: MediaController, name: "", parent: null }
Or as the enlarged version: https://matrix.nordgedanken.dev/_matrix/media/r0/download/nordgedanken.dev/c5f0e98dbe998b2555b85d201af7d6e1700e5a29 (screenshot)
Assignee | ||
Comment 39•4 years ago
|
||
It looks like that I can reproduce the failure on my own now when executing the following code in the browser console:
var hs = [];
for (let win of Services.wm.getEnumerator(null)) {
let tabBrowser = win.gBrowser;
// Only return handles for browser windows
if (tabBrowser && tabBrowser.tabs) {
for (let tab of tabBrowser.tabs) {
console.log(tab);
let winId = tab.linkedBrowser.browsingContext.id;
if (winId !== null) {
hs.push(winId);
}
}
}
}
console.log(hs);
It's basically the code that Marionette uses to get all the window handles. I will have a look.
Assignee | ||
Comment 40•4 years ago
|
||
So the problem is indeed related to some tabs that aren't loaded yet, and as such don't have an active browser. This can happen when you have a number of tabs open, and restart Firefox. After the restart only the current tab and all pinned tabs are loaded. Running the code above will cause failures for each of the not yet loaded tabs.
Marcel, when Firefox gets opened by your test how many tabs are open? Usually it should be a single one, but maybe you make use of a custom profile that has some not yet loaded background tabs?
Reporter | ||
Comment 41•4 years ago
|
||
Yeah I run my usual profile for this. So I have easily over 60 open tabs in this.
I attach geckodriver to my regular already open driver instead of opening a new browser as the goal was to automate parts of my usual browser usage and bind it to some hardware buttons :)
I am however wondering why it worked in the esr version or did that behavior change later on?
Reporter | ||
Comment 42•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [βοΈUTC+1] from comment #40)
So the problem is indeed related to some tabs that aren't loaded yet, and as such don't have an active browser. This can happen when you have a number of tabs open, and restart Firefox. After the restart only the current tab and all pinned tabs are loaded. Running the code above will cause failures for each of the not yet loaded tabs.
Indeed after I went ahead and loaded every tab it works.
Assignee | ||
Comment 43•4 years ago
|
||
Yes, see my comment 28. Moving away from outerWindowID
, which seems to be always present even with a tab unloaded, it doesn't work with the browsingContext
that only exists for a valid browser.
Note that we strongly advice not to use your normal Firefox profile for automation tasks, and especially not even connecting to a running instance. There are various side-effects (like navigator.webdriver
always be true
), and Firefox accepting commands from external tools via the open socket by Marionette.
So we indeed can get this fixed by bug 1680479 and would have to account for unloaded tabs.
Thanks for all your help.
Reporter | ||
Comment 44•4 years ago
|
||
Thanks for the help debugging it! And I am aware of the side effects :)
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 45•3 years ago
|
||
With bug 1680479 fixed this is issue is also fixed now. To ensure we do not regress it in the future I'm going to add some unit tests.
Assignee | ||
Comment 46•3 years ago
|
||
Updated•3 years ago
|
Comment 47•3 years ago
|
||
Pushed by hskupin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8f0acc0b26ce [marionette] Added Marionette unit tests for unloaded tab behavior. r=marionette-reviewers,jdescottes
Comment 48•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•2 years ago
|
Description
•