[Customize] The theme changes if the cursor falls on another theme than the one selected
Categories
(Firefox :: Toolbars and Customization, defect, P3)
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)
596.56 KB,
image/gif
|
Details |
[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.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 1•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
(If somebody else is able to reproduce this very reliably, I'd love a confirmation on bug 1463708 being the regressor though)
Reporter | ||
Comment 3•5 years ago
|
||
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.
Comment 4•5 years ago
|
||
(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.
Reporter | ||
Comment 5•5 years ago
|
||
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.
Reporter | ||
Comment 6•5 years ago
|
||
Just to be clear. I can't reproduce the issue on the build from 2018-06-19 either.
Comment 7•5 years ago
|
||
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.
Comment 8•5 years ago
|
||
Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.
Updated•5 years ago
|
Updated•2 years ago
|
Description
•