1794329 - Multi Account Container confirmation page lost all styles

Status: RESOLVED MOVED

(WebExtensions :: Developer Outreach, defect)

Description

[bbhtt]

Attachment: before.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

1. Install Multi Account Container extension
2. Set a page to "always open" in a container
3. Open it again so that the confirmation page is displayed

Actual results:

All style is lost

Expected results:

Properly styled and themed

Comment 1

[bbhtt]

Attachment: after.png

Comment 2

[bbhtt]

Attachment: about:support.json

Comment 3

[bbhtt]

I tried with two different regression ranges: 2022-10-01 to 2022-10-09 and then with 2022-10-07 to 2022-10-08, both points to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=30bdee9799a07b8770719aa868416174ff0c54f5&tochange=1258b03e6b88179ed35d6ac53f1171fb11abbbba, but I don't think that's correct.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

:bbhtt.zn0i8, could you try to find a regression range using for example mozregression?

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 6

[Alice0775 White]

I got same regression window as comment#3.

:eemeli, your bunch of patches seems to cause webextension styling breakage. Could you please look into this?
Tentatively, set Bug 1734217 to the regression flag.

Comment 7

[Eemeli Aro [:eemeli]]

Yeah, this was a regression caused by bug 1734217 as it moved the aboutNetError.css file from browser/ to toolkit/.

The fix for this needs to be done in the extension: https://github.com/mozilla/multi-account-containers/pull/2424

Comment 8

[Donal Meehan [:dmeehan]]

Double checking we will ship an update to the extension with this fix before we release 107?
I see the fix just landed, but was wondering about timing

Comment 9

[Eemeli Aro [:eemeli]]

I don't know; this was my first contribution to the extension. Danny, would you know if it'd be possible to publish a release with this fix?

Comment 10

[Danny Colin [:sdk]]

I talked with Max (Privacy & Security team) and he's going to try to push a release because I can't. However, we can't jump the AMO queue so it may take up to 2 weeks to be reviewed since we were already about to push a new release with a bunch of changes.

Comment 11

[:Gijs (he/him)]

We could add a one-line override manifest instruction to the chrome manifest registration that provides the new file at the old location and that'd avoid extensions having to update. Question is whether we want to do that or "just" get extensions to update given that depending on internal stylesheets is kind of yucky anyway - ideally I'd like to make chrome: URLs much less accessible than they currently are, and then all this stuff is going to break anyway.

Comment 12

[Danny Colin [:sdk]]

100% agree with Gijs that we shouldn't depend on an internal stylesheets. Adding both URLs is IMO only a quick workaround to fix the issue for our Nightly users and to make sure it doesn't break for all our users if 107 is released before we have the time to implement a permanent fix.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1734217

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.