1902844 - windows API: extension pages are not allowed to close their own windows

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, defect, P1)

Description

[Teal Dulcet [:tdulcet] (TB Council)]

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.

Comment 1

[John Bieling]

This is a longstanding known bug

Has it been reported here? What are you trying to implicate by this wording?

Comment 2

[Teal Dulcet [:tdulcet] (TB Council)]

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.

Comment 3

[John Bieling]

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.

Comment 4

[Teal Dulcet [:tdulcet] (TB Council)]

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.

Comment 5

[John Bieling]

Attachment: Bug 1902844 - Make create() of the windows API default `allowScriptsToClose` to `true` for extension pages. r=#thunderbird-reviewers

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.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ab6019af91ec
Make create() of the windows API default allowScriptsToClose to true for extension pages. r=mkmelin

Comment 7

[John Bieling]

Comment on attachment 9426842 [details]
Bug 1902844 - Make create() of the windows API default allowScriptsToClose to true for extension pages. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: Since we first added support for allowScriptsToClose, it was disabled by default. Firefox however enabled it for extension pages. Not adjusting Thunderbird will keep certain add-ons which work in both (TB and FF) incompatible with Thunderbird.
Testing completed (on c-c, etc.): On Daily since 133
Risk to taking this patch (and alternatives if risky): Low, only affecting WebExtension code

Comment 8

[Corey Bryant]

Comment on attachment 9426842 [details]
Bug 1902844 - Make create() of the windows API default allowScriptsToClose to true for extension pages. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr128

Comment 9

[Corey Bryant]

Thunderbird 128.5.0esr:
https://hg.mozilla.org/releases/comm-esr128/rev/35020e1b01eb