User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36 Steps to reproduce: Set up and webdriver test with Marionette driver to do the following tasks. 1) Open a browser window with a single tab. 2) Open a new tab in that same window. 3) Ensure the code running on both tabs is responding to `visibilitychange` events and logging when the happen to it can be inspected later. 4) Close the second tab. Actual results: 1) The `visiblitychange` event on the first tab fires (`document.visibilityState` changing from `hidden` to `visible`). 2) The `visiblitychange` event on the second tab fires (`document.visibilityState` changing from `visible` to `hidden`). Expected results: The reverse order should happen. The tab that's closing should report its visibility state changing prior to the tab that's about to become visible. I.e.: 1) The `visiblitychange` event on the second tab fires (`document.visibilityState` changing from `visible` to `hidden`). 2) The `visiblitychange` event on the first tab fires (`document.visibilityState` changing from `hidden` to `visible`). Note this only happens when using Marionette driver. It works as expect when running Firefox normally.

Note that Marionette’s idea of which is the current window handle does not correspond to which is the active tab. Marionette also makes use of the active tab when changing WebDriver window, so you might expect to see Marionette interfering with your normal Firefox use.

> Note that Marionette’s idea of which is the current window handle does not correspond to which is the active tab. Right. In my case I'm opening a new tab by clicking on a link with `target="_blank"`; I'm not using any webdriver commands to it (other than the click, obviously). Also, once the new tab is open I run logic to ensure the current window handle is the same as the active tab, so that when I close it I know I'm closing the correct tab. I don't think my issue has to do with confusing the active tab and the window handle. > Marionette also makes use of the active tab when changing WebDriver window, so you might expect to see Marionette interfering with your normal Firefox use. In my case I don't have another instance of Firefox active while running my tests, so I don't think that's part of the issue.

(In reply to philip from comment #2) > Right. In my case I'm opening a new tab by clicking on a link with > `target="_blank"`; I'm not using any webdriver commands to it (other than > the click, obviously). Also, once the new tab is open I run logic to ensure > the current window handle is the same as the active tab, so that when I > close it I know I'm closing the correct tab. WebDriver should not choose this tab as the current window handle until you switch to it. The current window handle should remain the window handle of the document where you clicked the link. To activate the opened tab you need to switch to it by its window handle.

> WebDriver should not choose this tab as the current window handle until you > switch to it. The current window handle should remain the window handle of > the document where you clicked the link. > To activate the opened tab you need to switch to it by its window handle. I am switching to the newly opened tab in code, but I don't think that's relevant to this bug. Regardless of whether/when webdriver switches to the newly opened tab, the `visibilitychange` events should correspond to actual visibility state of the UI. Note, Chrome behaves as expected in my tests, as did Firefox driver in FF46.

Philip, my patch on bug 1311350 landed on mozilla-central. Can you please have a look again at this issue and check with the next Nightly build again? It should be released later today. I would like to know if it is fixed now. Thanks.

I tried it again just now and got the same results. That being said, I suspect I might not be running the latest changes. I updated FF developer edition to the 2017-01-12 version, but I'm not sure if that updates the version of Marionette driver. When I run my tests with the following config, it still loads FF50. {browserName: 'firefox', version: 'dev'} Any suggestions for how to test out your changes locally?

No, I was not talking about the dev edition, but Nightly. If you want to use the former you will have to wait until tomorrow. My patch got uplifted to aurora 6h ago, so it will make tomorrows dev edition nightly build.

I guess I'm not sure how to tell my webdriver tests which version of Marionette/FF to use. Specifying 'dev' didn't do anything differently from not specifying a version (btw, on my system I have FF50 and FFDE installed). Any suggestions or links to documentation re: how to do this?

Please have a look at the geckodriver docs in how to specify the binary through the capabilities: https://github.com/mozilla/geckodriver#firefox-capabilities

Thanks, I tried using this setup: 'browserName': 'firefox', 'moz:firefoxOptions': { binary: '/Applications/FirefoxDeveloperEdition.app/Contents/MacOS/firefox-bin', }, But when I do I get this error: ERROR: Firefox option was set, but is not a FirefoxOption: {binary=/Applications/FirefoxDeveloperEdition.app/Contents/MacOS/firefox-bin} Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 09:48:19 -0700' System info: host: 'philipwalton-macbookpro.roam.corp.google.com', ip: '172.31.98.18', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.11.6', java.version: '1.8.0_66' Driver info: driver.version: FirefoxDriver I get the same error if I reference `firefox` rather than `firefox-bin`.

Please have a look at the code as contained in my blog post. I hope it will help you to setup your test properly: https://www.hskupin.info/2017/01/23/using-selenium-and-webdriver-to-interact-with-insecure-ssl-pages-in-firefox/ It would also be good to see how your test looks like, so that I could try to run it myself. Thanks.

Philip, can we please get a feedback from you? Meanwhile a couple of releases of Firefox are out, so you can try to reproduce it with Firefox 57? If it's not working please create a little test snippet which shows the problem. Thanks.

Closing for inactivity.

(In reply to Andreas Tolfsen ‹:ato› from comment #13) > Closing for inactivity. It doesn't mean that the bug is invalid, but has incomplete information.