1375451 - UnexpectedAlertPresentException when attempting to use Browser Toolbox

Status: RESOLVED INVALID

(Remote Protocol :: Marionette, enhancement, P3)

Description

[Dave Hunt [:davehunt] [he/him] ⌚BST]

It can be useful to interrupt a running instance of Firefox w/ Marionette by opening the Browser Toolbox to inspect elements in chrome. I noticed whilst demonstrating this last week that Marionette is throwing UnexpectedAlertPresentException even after the prompt to enable remote debugging is dismissed.

Steps to replicate (using Python with selenium 3.4.3 installed):

1. Run the following in a Python interactive shell:

from selenium.webdriver import Firefox
from selenium.webdriver.firefox.options import Options
options = Options()
options.set_preference('devtools.chrome.enabled', True)
options.set_preference('devtools.debugger.remote-enabled', True)
options.binary = '/Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin'
firefox = Firefox(firefox_options=options)
firefox.get('http://example.com')

2. Open Browser Toolbox from Firefox, and accept prompt when displayed.

3. Running any command such as firefox.refresh() will raise an UnexpectedAlertPresentException.

I'm able to switch to the alert using firefox.switch_to_alert(), however the returned Alert object raises NoAlertPresentException when calling any of its methods or properties.

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

It seems to work fine if I accept the remote connection prompt using firefox.switch_to_alert().accept() rather than doing it by clicking the button. Perhaps dismissing/accepting the alert manually is not clearing the alert detected by Marionette?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Nothing in the spec talks about a real click, so I would assume you would have to use the provided commands:

https://w3c.github.io/webdriver/webdriver-spec.html#dfn-dismiss

Andreas, or David?

Comment 3

[Andreas Tolfsen ❲:ato❳]

(In reply to Dave Hunt (:davehunt) from comment #0)

> It can be useful to interrupt a running instance of Firefox w/
> Marionette by opening the Browser Toolbox to inspect elements in
> chrome. I noticed whilst demonstrating this last week that Marionette
> is throwing UnexpectedAlertPresentException even after the prompt to
> enable remote debugging is dismissed.

This is because the dialogue is a global dialogue that is detected by
Marionette.  My suspicion is that this only happens when you interrupt
an IPC message to the content frame script.

> from selenium.webdriver import Firefox
> from selenium.webdriver.firefox.options import Options
> options = Options()
> options.set_preference('devtools.chrome.enabled', True)
> options.set_preference('devtools.debugger.remote-enabled', True)

You may want to try setting marionette.debugging.clicktostart, which is
what --js-debugger uses.

Comment 4

[Dave Hunt [:davehunt] [he/him] ⌚BST]

> You may want to try setting marionette.debugging.clicktostart, which is what --js-debugger uses.

This just seems to cause a modal dialog in Firefox, which I assume you're suggesting I open the Browser Toolbox before accepting, but I'm unable to do so.

Comment 5

[Andreas Tolfsen ❲:ato❳]

(In reply to Dave Hunt (:davehunt) from comment #1)

> It seems to work fine if I accept the remote connection prompt using
> firefox.switch_to_alert().accept() rather than doing it by clicking
> the button. Perhaps dismissing/accepting the alert manually is not
> clearing the alert detected by Marionette?

Our user prompt implementation isn’t great, so this is likely a bug to
do with tracking them.  My guess is that it thinks the prompt is still
there after you click to dismiss it.

Comment 6

[Andreas Tolfsen ❲:ato❳]

We need to implement a new user prompt handler for this to be fixed.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

What we actually need here is bug 1477977.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dave is that still a problem now with bug 1477977 fixed? When I tried myself I didn't see the modal dialog as mentioned in the original comment. So maybe something has been changed? Mind checking again? Thanks!

Comment 9

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Running this with latest Firefox release (67.0.2) and latest Selenium (3.141.0) I still see a prompt to accept when opening the Firefox Browser Toolbox. Instead of UnexpectedAlertPresentException I now get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/dhunt/.pyenv/versions/tmp-3.7.0-dhunt-woEEuC/lib/python3.7/site-packages/selenium/webdriver/remote/webdriver.py", line 831, in refresh
    self.execute(Command.REFRESH)
  File "/Users/dhunt/.pyenv/versions/tmp-3.7.0-dhunt-woEEuC/lib/python3.7/site-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute
    self.error_handler.check_response(response)
  File "/Users/dhunt/.pyenv/versions/tmp-3.7.0-dhunt-woEEuC/lib/python3.7/site-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response
    raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: TypeError: this.tabModal is null

This is what I see in the Browser Toolbox console:

Marionette threw an error: TypeError: this.tabModal is null
get ui@chrome://marionette/content/modal.js:159:5
GeckoDriver.prototype._handleUserPrompts@chrome://marionette/content/driver.js:3256:23
GeckoDriver.prototype.refresh@chrome://marionette/content/driver.js:1273:14
despatch@chrome://marionette/content/server.js:289:40
execute@chrome://marionette/content/server.js:262:16
onPacket/<@chrome://marionette/content/server.js:235:20
onPacket@chrome://marionette/content/server.js:236:9
_onJSONObjectReady/<@chrome://marionette/content/transport.js:492:20

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dave the fix is only in the latest Nightly (20190614100022). Please check with it again. I would appreciate. Thanks!

Comment 11

[Dave Hunt [:davehunt] [he/him] ⌚BST]

I can confirm that I do not see a prompt in Nightly.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ok, so I'm not alone. Given that my modal dialog patch will not be backported to 68, we won't be able to check if it fixes the problem.

I think we have to close this bug as invalid now because it can no longer be reprodued.