Closed Bug 1902844 Opened 5 months ago Closed 1 month ago

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

Categories

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

Tracking

(thunderbird_esr128 affected)

RESOLVED FIXED
133 Branch
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.

Status: NEW → UNCONFIRMED
Ever confirmed: false

This is a longstanding known bug

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

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.

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.

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: nobody → john
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

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.

Status: NEW → ASSIGNED
Target Milestone: --- → 133 Branch

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

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: