[Win 11] Firefox PBM icon is briefly displayed in taskbar when opening
Categories
(Firefox :: Installer, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | affected |
People
(Reporter: cgeorgiu, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
image/gif
|
Details |
Found in
- Beta 105.0b2
Affected versions
- Beta 105.0b2
Tested platforms
- Affected platforms:
Win 11 x64 - Unaffected platforms:
Win 10 x64
Steps to reproduce
- Download, unzip this build and open it.
- Navigate to
about:config
and add the following prefs as true:
browser.privacySegmentation.enabled
browser.privacySegmentation.windowSeparation.enabled - this pref needs to be manually created - Update the build to the latest beta version available.
- Close the build.
- Open again the Firefox build, and observe the Win taskbar.
Expected result
- Firefox icon is the regulator one, not the PBM icon, as briefly is displayed in the taskbar.
Actual result
- Firefox PBM icon is briefly displayed in the taskbar, then it changes to the regular one.
Regression range
- Not a regression.
Additional notes
- Please observe the attached screencast.
- I was unable to reproduce the problem if updating from 104.0b1 to the latest version. So, maybe, this issue is triggered by the fact that we manually create the pref
browser.privacySegmentation.windowSeparation.enabled
in 99.0b1, before updating the build.
Comment 1•2 years ago
|
||
I'm going to take at least a quick look at this regardless, but is this reproducible by starting with a newer version? Eg: does it happen if you go from 105.0b1 -> 105.0b2?
Comment 2•2 years ago
|
||
I'm still curious what you find, but I think this is not related to the privacy segmentation prefs (although it's more serious when windowSeparation
is true
). I was able to reproduce what is effectively the same issue by following the same STR without setting the prefs. Instead of going from a Private Browsing icon to a regular icon, it replaced one regular icon with another.
Most likely, the AUMID of the window is getting changed at some point shortly after it has been painted. I don't have time to dive deeper at the moment, but I think that attaching a debugger and setting some breakpoints in the AUMID functions in https://searchfox.org/mozilla-central/source/widget/windows/WinTaskbar.cpp would make it pretty clear what's happening.
The fact that zip builds aren't typically launched with a shortcut with an AUMID associated with it may be playing a factor here.
Reporter | ||
Comment 3•2 years ago
|
||
(In reply to bhearsum@mozilla.com (:bhearsum) from comment #1)
I'm going to take at least a quick look at this regardless, but is this reproducible by starting with a newer version? Eg: does it happen if you go from 105.0b1 -> 105.0b2?
No, it doesn't happen in that case. I updated today a Beta build, from 105.0b1 to 105.0b3, without encountering the issue.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
It sounds like this is no longer reproducible (I'm guessing it had something to do with older code that has since been fixed). Please re-open if it's still an issue.
Description
•