[Windows] Crash reporter icon from the window title bar is blurry when the scaling factor is set to 125%
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox125 | --- | unaffected |
| firefox126 | --- | wontfix |
| firefox127 | --- | verified |
People
(Reporter: bhidecuti, Assigned: afranchuk)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
Found in
- Latest Nightly 127.0a1 (2024-04-16)
Affected versions
- 127.0a1
- 126.0b1
Tested platforms
- Affected platforms: Windows 11
- Unaffected platforms: macOS 12.6.6, Ubuntu 22.04
Preconditions
- Have the OS scaling factor set to 125%
Steps to reproduce
- Go to about:crashparent page;
- Observe the crash reporter icon from the window title bar;
Expected result
- The crash reporter icon from the window title bar is not blurry
Actual result
- The crash reporter icon from the window title bar is blurry
Regression range
- Regressed by: Bug 1888880
Additional notes
- See the attached ss
- Not reproducing for the icon from the taskbar
- Not reproducing if the scaling factor is set to 100%
Comment 1•1 year ago
|
||
:afranchuk, since you are the author of the regressor, bug 1888880, could you take a look?
For more information, please visit BugBot documentation.
Comment 2•1 year ago
|
||
I suspect we need multiple sizes of this particular icon.
| Assignee | ||
Comment 3•1 year ago
•
|
||
The problem here is that I'm using PNG (that's the easiest format to load directly from image data at runtime using the windows API), which does not support multiple sizes. Believe it or not using an ICO is more labor-intensive; you have to manually parse through and select the size you want (so it won't actually help in this case). It would be easier to use an ICO if I add windows resources, which can be done in a hacky manner with the linker or a less hacky manner with something like the winres crate. Only when using a bundled resource will the system select the best size for you (I believe).
| Assignee | ||
Comment 4•1 year ago
|
||
I've spent an inordinate amount of time on this. I noticed that the old application never uses the 16x16 or 48x48 icon, regardless of scaling settings (technically the 48x48 should be used). I had written a WM_GETICON which would choose the right one to use per the DPI, however each of those icons is actually a different design, so it makes more sense to just use one.
I've found that, for reasons I haven't figured out, windows is scaling the PNG icon differently than the ICO icon. For example, I took a screenshot of the icon of the old crashreporter, and resized the 32x32 image in GIMP to be 20x20 (which is the icon size at 125% scaling) using cubic interpolation and found them to be identical! I.e., if windows were resizing the PNG image in the same way as the ICO image (resizing a bitmap), it would look the same. I expect that rather than scaling the raw bitmap from the PNG itself like it probably does with the ICO image, windows has some external PNG renderer (likely one they use to render all PNGs in the OS) which is doing something weird when scaling, such as doing a multi-step scaling (scaling up, then down, which is common).
| Assignee | ||
Comment 5•1 year ago
|
||
I just went through quite a lot of pain to get the ICO data loaded rather than using PNG data, and... it's still blurry.
| Assignee | ||
Comment 6•1 year ago
•
|
||
Aha! This is subtle and I'm not entirely sure, but I think LoadIcon (used by the old crash reporter but not the new) actually resizes the image too. I will experiment with this.
| Assignee | ||
Comment 7•1 year ago
|
||
Okay, super "interesting" (but not really). If you have an icon set with the window class, it scales poorly. If you use WM_SETICON, it scales nicely. Ugh.
| Assignee | ||
Comment 8•1 year ago
|
||
For some reason, they only scale nicely when set with WM_SETICON as
opposed to being set in the window class.
Updated•1 year ago
|
Comment 9•1 year ago
|
||
Thanks for having gone through this madness to figure out what the problem was.
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
| bugherder | ||
Comment 12•1 year ago
|
||
The patch landed in nightly and beta is affected.
:afranchuk, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox126towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 13•1 year ago
|
||
Doesn't affect usability; no need for uplift.
Updated•1 year ago
|
Reproduced the issue on Firefox 127.0a1 (2024-04-16) on Windows 11 by following the STR from Comment 0.
This issue is fixed on Firefox 127.0b4 on the same system.
Description
•