windows API: extension pages are not allowed to close their own windows
Categories
(Thunderbird :: Add-Ons: Extensions API, defect, P1)
Tracking
(thunderbird_esr128 affected)
Tracking | Status | |
---|---|---|
thunderbird_esr128 | --- | affected |
People
(Reporter: tdulcet, Assigned: TbSync)
Details
Attachments
(1 file)
When using the windows.create()
function to open an extension page in a new window, the page is not allowed to close itself without setting the allowScriptsToClose
option, which according to MDN should not be needed for extension pages:
if the URL(s) given in
url
point to extension pages (that is, they are pages included with this extension and loaded with the "moz-extension:" protocol) then scripts are by default allowed to close those tabs.
For example, this code does not currently work, but should.
background.js
:
browser.windows.create({
url: browser.runtime.getURL("popup.html"),
type: "popup"
});
popup.js
:
setTimeout(() => {
close();
}, 10000);
This is a longstanding known bug, which affects my FileLink provider for Send add-on. The workaround for extension developers is obviously trivial (include the allowScriptsToClose
option), but it is still confusing that it does not match the documented behavior. This may also cause issues when porting Firefox add-ons to Thunderbird, as well as Chrome, which does not support this allowScriptsToClose
option.
I just tested in the latest TB 129 Daily, but I have previously tested in TB 91 ESR, 102 ESR, and 115 ESR. Also see Bug 1675940.
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 1•5 months ago
|
||
This is a longstanding known bug
Has it been reported here? What are you trying to implicate by this wording?
Reporter | ||
Comment 2•5 months ago
|
||
What are you trying to implicate by this wording?
Just that it is not a recent regression and has likely existed at least since bug 1675940 was fixed, in case that is helpful for debugging it.
Assignee | ||
Comment 3•5 months ago
|
||
The bug is not known to me, and it is definitely not a longstanding known bug. You are probably correct that the current (wrong) behaviour exists for long (and that behaviour is actually expected by our test).
For me, your statement implies that you reported this and the report has purposefully been ignored. However, this is the first time I learn of this wrong implementation. Please use less aggressive wording in the future.
Reporter | ||
Comment 4•5 months ago
|
||
Sorry, I did not mean to imply that you knew about the bug, just that I (and maybe other add-on developers) knew about it. I have had a comment about this in my source code for several years, but it is of course a mirror issue with an easy workaround, so I have not prioritized reporting it. Anyway, I will of course try to word that better next time.
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 5•1 month ago
|
||
The default has been false
for all URL types since we first added
support for allowScriptsToClose
. As reported, extension pages no
longer have to explicitly request it anymore.
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/ab6019af91ec
Make create() of the windows API default allowScriptsToClose
to true
for extension pages. r=mkmelin
Description
•