Bugzilla

> - stop using openContentPrompt

After taking a better look into it I now see that "stop using openContentPrompt" is referring to `PromptParent.openContentPrompt`, and in particular it refers to the fact that the patch we landed is special casing the prompts originated from the inline options pages to always be handled by Prompts.openContentPrompt independently from the value of the prefs enableing/disabling them (see [here in searchfox](https://searchfox.org/mozilla-central/rev/9e5b13e92b50c61e60a42bdc2cb2e5966ae28795/browser/actors/PromptParent.sys.mjs#144-146)).

Going through `PromptParent.openContentPrompt` then requires the stack XUL element wrapping the inline browser element used in about:addons to host the options_ui extensions pages.

One way to stop using `PromptParent.openContentPrompt` is to go for the other option that we didn't pick when we were fixing the regression, see  patch attached as comment 4 in this ticket.

I digged a bit back into why that ["second option" patch created by "past-me"](https://phabricator.services.mozilla.com/D110531) had to use the tab's tab prompts instead one tied to the embedded browser and the reason is that (unlike e.g. sidebars extension pages or browserAction/pageAction popup pages) the browser element in this case belongs to a chrome document (the about:addons chrome document) that isn't the same as the one that the chrome window, and TabDialogBox hits an exception when trying to append into the XUL stack element that belongs to the about:addons chrome document, and so the "options 2" patch was going through the easier path (turn the modal into a tab modal).

I'm adding these additional details here as a bugzilla comment in the meantime, but I think that it would be worth touching base and discuss between us about this a bit more so that we can determine what would be the best path forward based on our combined perspectives.

> - stop using openContentPrompt

After taking a better look into it I now see that "stop using openContentPrompt" is referring to `PromptParent.openContentPrompt`, and in particular it refers to the fact that the patch we landed is special casing the prompts originated from the inline options pages to always be handled by Prompts.openContentPrompt independently from the value of the prefs enabling/disabling them (see [here in searchfox](https://searchfox.org/mozilla-central/rev/9e5b13e92b50c61e60a42bdc2cb2e5966ae28795/browser/actors/PromptParent.sys.mjs#144-146)).

Going through `PromptParent.openContentPrompt` then requires the stack XUL element wrapping the inline browser element used in about:addons to host the options_ui extensions pages.

One way to stop using `PromptParent.openContentPrompt` is to go for the other option that we didn't pick when we were fixing the regression, see  patch attached as comment 4 in this ticket.

I digged a bit back into why that ["second option" patch created by "past-me"](https://phabricator.services.mozilla.com/D110531) had to use the tab's tab prompts instead one tied to the embedded browser and the reason is that (unlike e.g. sidebars extension pages or browserAction/pageAction popup pages) the browser element in this case belongs to a chrome document (the about:addons chrome document) that isn't the same as the one that the chrome window, and TabDialogBox hits an exception when trying to append into the XUL stack element that belongs to the about:addons chrome document, and so the "options 2" patch was going through the easier path (turn the modal into a tab modal).

I'm adding these additional details here as a bugzilla comment in the meantime, but I think that it would be worth touching base and discuss between us about this a bit more so that we can determine what would be the best path forward based on our combined perspectives.