Open Bug 1515624 Opened 5 years ago Updated 2 years ago

[Customize] The theme changes if the cursor falls on another theme than the one selected

Categories

(Firefox :: Toolbars and Customization, defect, P3)

defect

Tracking

()

Tracking Status
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- fix-optional
firefox67 --- fix-optional
firefox68 --- fix-optional

People

(Reporter: obotisan, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

Attached image theme changes .gif
[Affected versions]:
- latest Nightly 66.0a1 
- Beta 65.0b5
- Release 64.0.3 

[Affected platforms]:
- Windows 10 x64
- Windows 7 x32
- Mac OS X 10.11
- Ubuntu 18.04 x64

[Prerequisites]:
- Install at least 3 themes from about:addons.

[Steps to reproduce]:
1. CLick hamburger menu -> Customize
2. Click on the "Theme" button at the bottom of the page.
3. Click on "Dark" theme and really fast slide the cursor down the doorhanger.

[Expected result]:
- The theme of the browser is "Dark" theme.

[Actual result]:
- The browser theme changes with whatever theme the cursor was on when the doorhanger closed.

[Regression range]:
- This is a regression, I can't reproduce the issue on Nightly from 2018-01-02. I will try to find a regression range as soon as possible. 

[Additional notes]:
- Please look at the attached gif.
- This change remains even after you click the "Done" button. 
- If you open again the "Theme" doorhanger, you can see that the "Dark" theme is the one selected.
- The issue can be reproduce with a clean profile, too.
Component: Themes → Toolbars and Customization
Product: Toolkit → Firefox
This seems pretty race-y, and I had middling success reproducing it reliably on my MBP. I _think_ I was able to bisect this down to bug 1463708 though.
Blocks: 1463708
Priority: -- → P3
(If somebody else is able to reproduce this very reliably, I'd love a confirmation on bug 1463708 being the regressor though)

I tried to find a regression range. By using mozregression this is what I found:

  • last good build: 2018-06-21
  • first bad build: 2018-06-19
    and concluded that bug 1466139 - set animation panel ID depending on devtools.new-animationinspector.enabled. might have caused the issue.

(In reply to Oana Botisan from comment #3)

I tried to find a regression range. By using mozregression this is what I found:

  • last good build: 2018-06-21
  • first bad build: 2018-06-19

This is a two-day window, but also your last good build is newer than the first bad build?

and concluded that bug 1466139 - set animation panel ID depending on devtools.new-animationinspector.enabled. might have caused the issue.

This is a test-only change so it can't have caused this issue.

I am sorry, I switched the two dates.
Also, mozregression didn't find a build from 2018-06-20 and I couldn't find one in https://archive.mozilla.org/pub/firefox/nightly/2018/06/ either.
I tried to find the regression 3 times, this is the result I got, so I am not sure what caused the issue, I just know that I can't reproduce it on builds before 2018-06-19.

Just to be clear. I can't reproduce the issue on the build from 2018-06-19 either.

Happy to take a patch in nightly 67, or potentially, in beta 66 for this.
Marking as fix-optional to remove it from weekly regression triage, since there is a priority assigned.

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: