JavaScript error: resource://gre/modules/Prompter.jsm, line 1081: AbortError: Actor 'Prompt' destroyed before query 'Prompt:Open' was resolved
Categories
(Toolkit :: Content Prompts, defect, P3)
Tracking
()
People
(Reporter: whimboo, Unassigned)
References
Details
I noticed that while investigating a test failure on bug 1654701. Maybe caused by the changes on bug 1631362 or bug 1615588.
Note that the tests are opening and closing tab modals in a quick succession. So this seems to be more a timing issue, as the error message also describes.
Problematic line in Prompter.js:
Paul, could you please have a look? Thanks.
Comment 1•5 years ago
|
||
The messaging was introduced in bug 1650837 and bug 1649477, and before that would have just shown NS_ERROR_NOT_AVAILABLE
.
The line number is supremely unhelpful as it just points to where we're looking for a nested event loop. What we need is the stack for the pending query...
Nika, is there an obvious way of getting this? And if this situation is expected for a given query (e.g. child process asks parent to display a prompt, then the tab closes before the prompt does, so the actor never gets a response through the query call), what's the "right" solution for this?
Also, Henrik, how do we run the test from bug 1654701, in order to reproduce? Is it possible the tab is closed while the dialog is open?
Updated•5 years ago
|
Comment 2•5 years ago
|
||
As I mentioned in matrix, I don't think that the failure is related to the prompter exception, which I think is actually harmless and just being reported as it is unhandled.
From a quick glance, it seems like the window in question is being navigated to be cross-origin while the prompt is open, so when the timeout returns after the navigation is complete, the attempt to access a property off of the window
object fails, as it is no longer in the current process.
Comment 3•5 years ago
|
||
Just to copy stuff from matrix, the exception is probably coming from https://searchfox.org/mozilla-central/rev/227f22acef5c4865503bde9f835452bf38332c8e/toolkit/components/prompts/src/Prompter.jsm#1178 and we need to handle both an exception there and the explicit exception for aborted prompts if we don't want this to show anything in the browser console. If we do that, we'll need to work out what to return to the callers of the prompt APIs now that the window got destroyed. Unsure if this is specced in some way, as these APIs are effectively web-exposed via alert()
, confirm()
and prompt()
.
Either way I agree with Nika that this is almost certainly harmless, so setting priority accordingly.
Comment 4•5 years ago
|
||
The prompt callers expect the "prompt aborted by user" exception. This has been around for a while and is mentioned in an MDN article here: https://developer.mozilla.org/en-US/docs/Mozilla/Using_tab-modal_prompts. Throwing all the way to the consumer is important so they can fallback to a default.
However, this shouldn't be relevant for the web exposed prompt methods since the consumers are unloaded when this exception is thrown.
The actor exception is something we could catch, but ideally the prompt consumers should handle it as well.
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #1)
Also, Henrik, how do we run the test from bug 1654701, in order to reproduce? Is it possible the tab is closed while the dialog is open?
Those tests can be run via mach wpt %path%
and you would need a geckodriver executable.
I'm not sure if the tab is closed because we don't have the TabOpen
and TabClose
listeners attached all the time. But bug 1657095 comment 2 is another case here. The document was unloaded
failure indicates that at least the web content has been unloaded, and the tab not necessarily been closed, right?
Updated•2 years ago
|
Comment hidden (Intermittent Failures Robot) |
Description
•