1830705 - Extension APIs can't handle custom windows created by add-ons via experiment APIs

Status: RESOLVED FIXED

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

Description

[Mark Banner (:standard8)]

The Conversations' add-on currently creates custom windows for displaying messages when the user has the preference set to open new messages in a window.

When the window attempts to obtain the window Id using the WebExtension code.

Unfortunately that is now failing as the code now throws if the type is not known.

Probably the easiest thing is to handle the unknown window types and return unknown, or something like that.

A more complex (and likely longer) solution would be to make it possible to open content tabs as a separate window, without the 3-pane tab attached (similar to the standalone message window).

Comment 1

[Thomas D. (:thomas8)]

This regression is probably caused by sn-3p.

Comment 2

[John Bieling (:TbSync)]

It is important to know what kind of window the API is dealing with, in order for the tabs API to properly know how to work with the window. If I understand your code correctly, you forcefully introduce your custom window to the windowTracker by calling convert(), which the WebExt API itself is not doing, because it does not know it (https://searchfox.org/comm-central/rev/66ab958f260f7b9de66d960839fd479db75fe562/mozilla/toolkit/components/extensions/parent/ext-tabs-base.js#1707-1709).

After manually introducing the window to the windowTracker, your window was listed by the windows and tabs API and was considered to be a normal window, IIRC.

I think it will not cause issues to return "unsupported" or similar in the type getter, but documenting something that can actually never happen without using an Experiment seems strange to me. My preferred solution to this would be to not pipe custom windows through the WebExt API.

Could you give a short explanation, why you need to pipe your custom window through the WebExt API, instead of handling your own window completely on your own?

Comment 3

[Mark Banner (:standard8)]

The window is Conversations' equivalent of the stand-alone message window. The window is really just a simple browser element that allows loading and displaying the same chrome:// page that Conversations' uses in the message pane.

The page is accessing various APIs that need to know the window/tab id, e.g. to know which folder to stream messages into.

Whilst I could try and pretend that the window is a stand-alone message window (by setting the window type), I'm not sure that would be a sensible thing to do, since there seems to be a lot of assumptions about what is in those types of windows, how they are structured and what global variables are available.

As mentioned in comment 0, if there was a way to create tabs as stand-alone, without the three pane tabs, that might be an option, but I'm guessing that's not likely to happen until after 115.

Comment 4

[John Bieling (:TbSync)]

Whilst I could try and pretend that the window is a stand-alone message window (by setting the window type), I'm not sure that would be a sensible thing to do, since there seems to be a lot of assumptions about what is in those types of windows, how they are structured and what global variables are available.

Agreed, as it will open the window up to the messageDisplay API for all other active add-ons, which will probably cause issues. I rather have it being ignored completely by our APIs.

The window is really just a simple browser element that allows loading and displaying the same chrome:// page that Conversations' uses in the message pane.

Which browser of the mail3pane tab do you load your chrome:// page into? Does that page needs to know the WebExt id of the window/tab it is loaded into? To know what folder is selected? Why does the stand-alone version of your message viewer needs to know its WebExtension Id?

The page is accessing various APIs that need to know the window/tab id, e.g. to know which folder to stream messages into.

Could you give a few examples of what APIs it uses?

Since your custom window is now no longer treated as a normal window, this may no longer work, even if I return a "unknown" type. I will create a test build for you to try out.

Comment 5

[John Bieling (:TbSync)]

If this try looks good, could you check if that solves it for you?
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=a2833a87678c74d57acfca1c92d3f9d34c406b71

Comment 6

[Mark Banner (:standard8)]

(In reply to John Bieling (:TbSync) from comment #5)

If this try looks good, could you check if that solves it for you?
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=a2833a87678c74d57acfca1c92d3f9d34c406b71

That seems to work, it at least gets it opening & loading. Thank you.

Comment 7

[John Bieling (:TbSync)]

Attachment: Bug 1830705 - Allow unknown window types, used in Experiments. r=#thunderbird-reviewers

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/2aff456e667e
Allow unknown window types, used in Experiments. r=mkmelin

Comment 9

[John Bieling (:TbSync)]

Comment on attachment 9338617 [details]
Bug 1830705 - Allow unknown window types, used in Experiments. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
This is work which was not completed in time for 115. The author of the conversation add-on is migrating his add-on to WebExtension but still has some legacy parts. This patch helps him to better interact between these two realms. It should not affect pure WebExtension users.

Testing completed (on c-c, etc.):
Just landed on Daily.

Risk to taking this patch (and alternatives if risky):
There should be none.

Comment 10

[Wayne Mery (:wsmwk)]

Comment on attachment 9338617 [details]
Bug 1830705 - Allow unknown window types, used in Experiments. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Comment 11

[Daniel Darnell [:dandarnell]]

Thunderbird 115.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/dc2e076351ba