1661295 - AlpenGlow theme goes wrong when external monitor is connected or disconnect (or goes to sleep?)

Status: RESOLVED WORKSFORME

(WebExtensions :: Themes, defect)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Screen Shot 2020-08-26 at 11.09.40 AM.png

Plugged in my external monitor, and the AlpenGlow theme (installed from AMO) ended up looking like the attached screenshot.

Quit and restarted firefox, and the theme went back to correct. Then I put my display to sleep, went away, and came back, and the theme did the same thing.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

(Guessed at component based on other AlpenGlow bugs)

Comment 2

[Robert Martin [:romartin], Ecosystem QA]

Hey Matthew,

We’ve been trying to reproduce the issue by doing the following:

• Alpenglow Theme installed from AMO (addons.mozilla.org).
  Unplug the main monitor, plug it back in and observe.
  Unplug the secondary monitor, plug it back in and observe.
  Put the PC to “Sleep” by using the Windows provided “Sleep” feature.
  Wait for the PC to naturally go in “Sleep” mode.
  Prepare the browser with the theme on a single monitor setup and add a secondary one afterward.
• Alpenglow Theme selected in the “about:welcome” page.
  Unplug the main monitor, plug it back in and observe.
  Unplug the secondary monitor, plug it back in and observe.
  Put the PC to “Sleep” by using the Windows provided “Sleep” feature.
  Wait for the PC to naturally go in “Sleep” mode.
  Prepare the browser with the theme on a single monitor setup and add a secondary one afterward.
• Alpenglow Theme enabled in the “about:addons” page from the “Themes” section.
  Unplug the main monitor, plug it back in and observe.
  Unplug the secondary monitor, plug it back in and observe.
  Put the PC to “Sleep” by using the Windows provided “Sleep” feature (Windows only).
  Wait for the PC to naturally go in “Sleep” mode.
  Prepare the browser with the theme on a single monitor setup and add a secondary one afterward.

All the verifications were done using Firefox Nightly 82.0a1 (Build ID: 20200831215215) and Firefox Beta 81.0b4 (Build ID: 20200829200810) with the following devices:

• Desktop PC , Windows 10 x64, i5 7600k, 16 GB RAM, GTX 1080ti with one 27” monitor connected through DisplayPort and the second one through HDMI.
• Desktop PC, Windows 10 x64, AMD 8320, 16 GB RAM, AMD RS780 with dual 21.5” monitors, one of which is connected through HDMI and the other one through VGA.
• Desktop PC, Ubuntu Linux 18.04, i5 7600k, 16 GB RAM, GTX 1080ti with one 27” monitor connected through DisplayPort and the second one through HDMI.
• MacBook Pro Retina 13”, macOS 10.14.6, i5 2.7 GHz, 8 GB RAM, Intel Iris Graphics 6100 with an external 24” monitor connected through HDMI.
• Desktop PC, Windows 7 x32, AMD 8320, 2 GB RAM, AMD RS780 with dual 21.5” monitors, one of which is connected through HDMI and the other one through VGA.

The results are the same across all our checks. We did not manage to reproduce the issue.
Is there something that we’re missing in our tests? Is it possible for you to provide us with the OS and maybe the specs of the device that you are using when you encounter this issue?

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

I am also no longer reproducing; I did change themes for a while though.

I can imagine it was a nightly issue. I'll keep the theme enabled (the one builtin rather than the AMO one) for a while to see if it reproduces.

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

Oh, and note: I am on MacOS 10.15.6, external monitor is a Dell 27", connected via USB-C -> DisplayPort cable.

Radeon Pro 560X 4 GB
Intel UHD Graphics 630 1536 MB

Comment 5

[Andrei Oprea [:andreio]]

Since we're not able to reproduce this I'm closing it for now. Feel free to re-open if it happens again. Thanks.

Comment 6

[Matthew Gaudet (he/him) [:mgaudet]]

So, this happened again, this time when plugging in an external monitor.

A potentially relevant note: I have different screen scaling applied to my built in display depending on if I am disconnected or connected: When I have my external monitor plugged in, I have it set to one tick larger than the default ("Looks like 1440x900" and when I have it unplugged, the scaling is "Looks like 1900x1200". )

As I am typing this bug report, my theme is incorrect while the screen is plugged in; however I was unplugging and plugging it back in. At least once, when unplugging, the theme fixed itself. Interestingly, dragging the window when the theme was broken -back- to the laptop screen, the theme repaired itself.

Then, disconnecting the monitor, the theme stayed good; but plugging the monitor back in, and it broke again.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

This may only surface when that monitor gets plugged in, but this is almost certainly a problem with the theme system or, perhaps even more likely, the platform layer. I'm going to move this to the theme system for further triage.

Comment 8

[Tomislav Jovanovic :zombie]

Hey Dão, This is unlikely a bug in extension framework, did you meant to move it to the Themeing component?

Comment 9

[Dão Gottwald [:dao]]

It's kind of a gray area, but I'd consider LightweightThemeConsumer.jsm part of WebExtensions::Themes rather than Toolkit::Themes.

I suspect the resolutionchange handling is broken: https://searchfox.org/mozilla-central/rev/c2e3ac11be4837718c2604e58085fbc8252b69dd/toolkit/modules/LightweightThemeConsumer.jsm#258
I think handling this event goes back to when we had LightweightThemeImageOptimizer.jsm which would crop the header image. That module doesn't exist anymore. It looks like we shouldn't handle this event anymore?

Comment 10

[Tomislav Jovanovic :zombie]

(In reply to Dão Gottwald [::dao] from comment #9)

I suspect the resolutionchange handling is broken: https://searchfox.org/mozilla-central/rev/c2e3ac11be4837718c2604e58085fbc8252b69dd/toolkit/modules/LightweightThemeConsumer.jsm#258
I think handling this event goes back to when we had LightweightThemeImageOptimizer.jsm which would crop the header image. That module doesn't exist anymore. It looks like we shouldn't handle this event anymore?

Thanks for pointing at the likely issue!

It's kind of a gray area, but I'd consider LightweightThemeConsumer.jsm part of WebExtensions::Themes rather than Toolkit::Themes.

None of the current extension module peers has ever worked on or reviewed changes to that file, it's mostly fronted folks (and from the past KMag, but he touched like half the tree, so that doesn't count :).

It seems that file is closer to handling the implementation of LW themes, and not to the API exposing themes to to extensions, or how themes are installed and handled by the Addon Manager. The location of the file in the tree also points to this separation.

What do you think Dão? We would like to clarify ownership here -- historically it seems this was mostly under the frontend/UI team, and we don't believe it belongs in our group. We understand all themes are technically "extensions" today :), but none of us have any real opinions to contribute to the implementation.

Comment 11

[Dão Gottwald [:dao]]

(In reply to Tomislav Jovanovic :zombie from comment #10)

It seems that file is closer to handling the implementation of LW themes, and not to the API exposing themes to to extensions, or how themes are installed and handled by the Addon Manager. The location of the file in the tree also points to this separation.

Lightweight themes are the precursor to webextension themes. They're pretty much the same thing at this point, i.e. lightweight themes don't exist anymore as a separate entity. The location and naming of this module are just legacy.

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

Setting qe-verify flag to verify if Bug 1676897 fixed it.

Comment 13

[Luca Greco [:rpl] [:luca] [:lgreco]]

Should have been fixed by Bug 1676897.
Victor, would you mind to double-check that this issue is queued for QA verification?

Comment 14

[Dão Gottwald [:dao]]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #13)

Should have been fixed by Bug 1676897.

It may or may not have. Comment 9 was a guess, and I have not determined that bug 1676897 actually fixed this.

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Dão Gottwald [::dao] from comment #14)

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #13)

Should have been fixed by Bug 1676897.

It may or may not have. Comment 9 was a guess, and I have not determined that bug 1676897 actually fixed this.

yeah, I closed it mainly to get it verified, and then reopen if it can still be reproduced (based on what we agree with the rest of the team during the last triaging, but on second thought... for this one I think that setting regressionwindow-wanted and asking for the fixing window may have been a better pick).

Comment 16

[Dão Gottwald [:dao]]

Matthew, can you still reproduce this in Nightly?

Comment 17

[Matthew Gaudet (he/him) [:mgaudet]]

I haven't seen it in a good while (3-4 weeks). I moved away from Alpen Glow about five days ago tho; I will go back to it and see if it returns at all.

Will report back if it happens

Comment 18

[Alex Cornestean]

Hello,

I’ve tried to see if the issue still occurs following the scenarios from Comment 2, on Windows 10 x64. Tested with the latest Nightly (85.0a1/20201209034903), Beta (84.0/20201207203640) and Release (83.0/20201112153044).

The issue did not surface during these tests.

I’ve also tried to reproduce the issue on an older version of Nightly (82.0a1 from about 4 months ago) but without success.