642851 - When windows taskbar is set to auto-hide and is docked to the top of the monitor on which Firefox is maximized, Fx fails to draw bottom row of pixels

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P1)

Description

[gekacheka]

Firefox fails to redraw the bottommost row of pixels on the screen 
when the 
- Windows taskbar is not at the bottom,
- Taskbar auto-hide is enabled, and
- Firefox window is maximized.

(The task bar can be dragged to any of the four edges of the screen.
Auto-hide reduces the taskbar to a line 2 pixels high or wide at that edge, and shows the full taskbar when the mouse hovers over it.  Apparently Firefox assumes the taskbar is always at the bottom when auto-hide is enabled.)

Steps to reproduce:
0. (Arrange so bottom row of pixels on screen is not just one color, say by 
    having a blue background and contrasting white non-firefox window covering
    different parts of bottom row of pixels.)
1. Drag windows task bar to edge of screen other than the bottom edge.
   (for example, the left edge).
2. Right click on task bar, click "Properties", enable "Auto-hide the taskbar".
   ("taskbar always on top" is also enabled)
3. Open a Firefox window and maximize it.  (Click the one-window button next to
   the close box in the titlebar.)

Actual Result:
The bottom row of pixels on the screen is not redrawn.  
The (blue) background and (white) window are visible in this row of pixels.

Expected Result:
A maximized window should fill the screen so the background and other windows are not visible.  (Except for the auto-hidden taskbar strip on the right edge of screen.)

Other programs handle this correctly.

(Speculation: Maybe FireFox assumes that an auto-hidden taskbar is always at the bottom edge of screen.  Instead, it should determine where the taskbar is located.)

Comment 1

[gekacheka]

[revised: add menubar off, regression, remove speculation]

Firefox fails to redraw the bottommost row of pixels on the screen 
when the 
- Windows taskbar is not at the bottom,
- Taskbar auto-hide is enabled, and
- Firefox menubar is off.
- Firefox window is maximized.

(The task bar can be dragged to any of the four edges of the screen.
Auto-hide reduces the taskbar to a line 2 pixels high or wide at that edge, and
shows the full taskbar when the mouse hovers over it.)

Problem is reproducible always, even in safe-mode.

Steps to reproduce:
0. (Arrange so bottom row of pixels on screen is not just one color, say by 
    having a blue background and contrasting white non-firefox window covering
    different parts of bottom row of pixels.)
1. Drag windows task bar to edge of screen other than the bottom edge.
   (for example, the left edge).
2. Right click on task bar, click "Properties", enable "Auto-hide the taskbar".
   ("taskbar always on top" is also enabled)
3. Open a Firefox window, not maximized.
4. Turn off menubar: View / Toolbars / Menubar (no checkmark)
5. Maximize Firefox (click the one-window button next to
   the close box in the titlebar).

Actual Result:
The bottom row of pixels on the screen is not drawn.  
The (blue) background and (white) window are visible in this row of pixels.

(Enabling the menu temporarily with the alt key does NOT cause Firefox
to draw these pixels.  Only when the menu is displayed persistently by
turning on the checkbox at View / Tooblars / Menubar makes FireFox
draw this bottom row of pixels.)


Expected Result:
A maximized window should fill the screen so the background and other windows
are not visible.  (Except for the auto-hidden taskbar strip on the edge
of screen.)


Regression window: 2010-08-09-04 to 2010-08-10-04 nightly

This problem 
does not appear in Firefox 4 beta 4 
and does appear Firefox 4 beta 5 

More specifically, this problem
does not appear in 
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/08/2010-08-09-04-mozilla-central/firefox-4.0b4pre.en-US.win32.zip
and does appear in
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/08/2010-08-10-04-mozilla-central/firefox-4.0b4pre.en-US.win32.zip

Comment 3

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

This is tied to the `WM_NCCALCSIZE` refactoring being done in bug 758280.

Comment 4

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Somehow I accidentally set myself as the QA contact instead of the assignee.  Fixing.

Comment 5

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

When the patch in bug 758280 lands, this issue should only be present if the auto-hide taskbar is on the same monitor as the Firefox window and is docked to the top of the screen.

Comment 6

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Unassigning myself.  Fixing the remaining issue requires us to be able to offset our client area from the top of our window, but when we try to do that the caption buttons become unresponsive.  I attempted to get around this by overriding our window position in `WM_WINDOWPOSCHANGING` and making the top of our window not hang over the top of the screen, but the top window border looked wrong.  We'll have to investigate why our caption buttons become unresponsive when we offset our client area from the top of our window.  Fixing that would allow us to remove a couple hacks [1][2] and to fix this issue.

[1] https://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp?rev=5c8fcc4cc760#2064
[2] https://mxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp?rev=b5c4b792f3f2#1763

Comment 7

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Updating title to reflect current behavior.

Currently this issue should only appear when
  1) Firefox is maximized
  2) The taskbar is set to auto-hide
  3) The taskbar is docked at the top of the monitor where the Firefox window is maximized

Comment 8

[isle]

this happened after install ati catalyst drivers..

Comment 10

[val.zapod.vz]

I do not understand this issue. In fullscreen you somehow forced not showing the taskbar at all! After Alt-Tab, etc. And in maximised (not fullscreen) when you change the place of hidden taskbar the 1 px (not 2, STRANGE) px are not redrawn... So "Currently this issue should only appear when" is just wrong.

Comment 11

[xiii_13]

(In reply to gekacheka from comment #0)

Firefox fails to redraw the bottommost row of pixels on the screen
when the

• Windows taskbar is not at the bottom,
• Taskbar auto-hide is enabled, and
• Firefox window is maximized.

(The task bar can be dragged to any of the four edges of the screen.
Auto-hide reduces the taskbar to a line 2 pixels high or wide at that edge,
and shows the full taskbar when the mouse hovers over it. Apparently
Firefox assumes the taskbar is always at the bottom when auto-hide is
enabled.)

Steps to reproduce:
0. (Arrange so bottom row of pixels on screen is not just one color, say by
having a blue background and contrasting white non-firefox window
covering
different parts of bottom row of pixels.)

1. Drag windows task bar to edge of screen other than the bottom edge.
   (for example, the left edge).
2. Right click on task bar, click "Properties", enable "Auto-hide the
   taskbar".
   ("taskbar always on top" is also enabled)
3. Open a Firefox window and maximize it. (Click the one-window button next
   to
   the close box in the titlebar.)

Actual Result:
The bottom row of pixels on the screen is not redrawn.
The (blue) background and (white) window are visible in this row of pixels.

Expected Result:
A maximized window should fill the screen so the background and other
windows are not visible. (Except for the auto-hidden taskbar strip on the
right edge of screen.)

Other programs handle this correctly.

(Speculation: Maybe FireFox assumes that an auto-hidden taskbar is always at
the bottom edge of screen. Instead, it should determine where the taskbar
is located.)

This bug is still present 10 years later. I currently run a three monitor setup with taskbar set on autohide in the left edge of the screen. A soon as I maximize any Firefox window it will go on top of the taskbar making it impossible to "summon" it by hovering the cursor on it.
The behavior is not present with Windows third party taskbars (i.e. DisplayFusion or Nexus Dock).

So, again, if:

• Windows taskbar is not at the bottom,
• Taskbar auto-hide is enabled, and
• Firefox window is maximized.

(The task bar can be dragged to any of the four edges of the screen.
Auto-hide reduces the taskbar to a line 2 pixels high or wide at that edge, and shows the full taskbar when the mouse hovers over it. Apparently Firefox assumes the taskbar is always at the bottom when auto-hide is enabled.)

Steps to reproduce:

1. Drag windows task bar to edge of screen other than the bottom edge.
   (for example, the left edge).
2. Right click on task bar, click "Properties", enable "Auto-hide the taskbar".
   ("taskbar always on top" is also enabled)
3. Open a Firefox window and maximize it. (Click the one-window button next to
   the close box in the titlebar.)

Actual Result:
You won't be able to make the taskbar unhide with your mouse.

Expected Result:
A maximized window should not cover hidden taskbars, no matter what edge of the screen they belong.

Other browsers/programs handle this correctly.

Speculation (as OP mentioned): Maybe FireFox assumes that an auto-hidden taskbar is always at the bottom edge of screen. Instead, it should determine where the taskbar is located.

Hoping it will be sorted out in development, meanwhile this is my workaround for people struggling with this issue: press Start and the taskbar will show together with the start menu (it will lose focus and disappear as soon as you go back to Firefox's maximized window). Alternatively (not viable for me) use third party taskbars,

What didn't work for me: AutoHotKey script to keep the taskbar always on top of other windows.

Comment 13

[Chris Peterson [:cpeterson]]

Windows taskbar is not at the bottom,

Note that this bug will only affects Windows versions <= 10 because Windows 11 no longer allows the taskbar to be moved to the top or side edges of the screen.

Comment 14

[val.zapod.vz]

It does, it is just harder to do in registry. Just like old context menu.

Comment 15

[xiii_13]

I believe this should be categorized in
Product: Core
Component: DOM: Window and Location
Version: Firefox 93
Platform: All Windows 10

Comment 16

[Chris Peterson [:cpeterson]]

(In reply to xiii_13 from comment #15)

Component: DOM: Window and Location

The "DOM: Window and Location" component is for issues related to the window or location JavaScript objects. The "Widget: Win32" component is for OS-specific UI issues.

Comment 17

[David Parks [:handyman]]

I can reproduce this on (only) one of my displays (in Win10).

STR for Windows 10:

• 0: Have Firefox window maximized on a page that is, e.g. essentially all white. Make sure the Windows taskbar is at bottom of screen and "Automatically hide the taskbar in desktop mode" is off (right-click taskbar, it's in Taskbar settings)
  1: Drag the taskbar to another edge of the screen to test.
  2: Turn on "Automatically hide..."
  3: Open a new Firefox window (Ctrl-n or "Open link in new window" in right-click context menu)
  4: Go to a page that contrasts the one in step 0 -- e.g. essentially all black.

Actual:

• Witness the line of white pixels where the mostly-hidden dock used to be is visible. If unconvinced, drag a smaller black window (like a terminal) over part of the line of pixels to see it clearly.
• After dragging the taskbar to the top of screen, I see comment 0 (a line of non-updated pixels). After dragging to the right, I see comment 11 (taskbar cannot be exposed -- need to minimize Firefox to get it back).
• Neither Minimize+Restore nor Restore_Down+Maximize cause it to start drawing the pixels. Strangely, moving the taskbar again to another side of the window also does not restore the pixels but moving the taskbar and Restore_Down+Maximize does fix the pixels.

Expected:

• Not those things.

Also see important comments 13 and 14 about this being impossible by default on Win11.

Comment 18

[zalerasco]

I can reproduce this on my laptop display in Windows 11.

Steps to reproduce in Windows 11:
1: Turn on "Automatically hide the taskbar" in Windows settings.
2: Maximize Firefox (if Firefox is already maximized, click the maximize button again to make it small, then maximize it.)
3: Switch to any dark-themed web page.

Actual result:
Observe the 1-2px white line stuck at the bottom of your screen.

Expected result:
No white line at the bottom of your screen.

Comment 19

[David Parks [:handyman]]

This region is made part of the non-client region here. This is necessary to be able to expose the hidden taskbar, although the 1px size is arbitrary and is smaller than other apps (on my display, they take 2px). This may be related to some "cannot expose hidden taskbar" bugs like bug 1428569.

Other apps, like Edge and Chrome, paint this region black and the result doesn't look like it is wrong. We do that in some cases, but not this one, here. Changing this clear to be non-conditional "fixes" the issue for me so it looks like the other applications. FWIW, it looks like this code could restrict to clearing the non-client region in any case (that might be a bit faster).

A better solution would be to detect the taskbar movement and resize/reflow when it happens.

Comment 20

[David Parks [:handyman]]

(In reply to zalerasco from comment #18)

I can reproduce this on my laptop display in Windows 11.

Thanks for the note. Can you provide a screenshot of what you are seeing? I think you are probably running into a different bug that looks similar -- e.g. bug 1739301, but I'm not sure.

(That could also be Win11 blowback from the non-client region hack I mentioned in comment 19 since other apps don't seem to account for the hidden taskbar visually in Win11 like they do in Win10.)

Comment 21

[zalerasco]

(In reply to David Parks [:handyman] from comment #20)

Thanks for the note. Can you provide a screenshot of what you are seeing? I think you are probably running into a different bug that looks similar -- e.g. bug 1739301, but I'm not sure.

It looks like bug 1739301 is indeed what I am seeing. Here's an image: https://i.imgur.com/Go5Kmo0.png. Should I move my report?

Comment 22

[David Parks [:handyman]]

Thanks, no need to do anything else. Once in Win11, I could easily see what you are referring to. This case actually makes me think I was wrong about the diagnosis; it suggests that clearing the non-client region may be the right fix after all. The other fix I proposed obviously wouldn't work -- there is no taskbar-moving to detect and we already resize when we start taskbar-hiding, but it doesn't remove the white line.

A second Win11 VM I have always shows the bottom row of pixels on the desktop as all white. And it spans two monitors. I don't know how buggy this corner of the universe in in general.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:handyman, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 24

[Gian-Carlo Pascutto [:gcp]]

Okay bot, I agree!

Comment 25

[David Parks [:handyman]]

I've commented in bug 1739301 on an idea that fixes the bug from comment 18. We're still looking at whether it helps this case.

Comment 27

[David Parks [:handyman]]

Attachment: Bug 642851: Allow identification of correct taskbar window for our screen on Windows r=cmartin!

Since Windows 8, ABM_GETAUTOHIDEBAREX has provided a way to identify if/where the system taskbar is hidden, even in multi-monitor setups. This adds a function to easily fetch that information.

Comment 28

[David Parks [:handyman]]

Attachment: Bug 642851: Clear autohidden taskbar region on Windows 10+ if drawing NC region r=cmartin!

The unpainted non-client region leaves a white bar at the bottom of the window when maximized on Win11 with auto-hidden taskbar. This region is where a user can mouse-over to expose the taskbar. Painting it black eliminates the row of white pixels and fixes problems with exposing the hidden taskbar. Windows 10 usually (correctly) paints a sliver of the taskbar in this region with or without this patch. However, it also has similar (but more complex) failing edge cases discussed in the bug.

Additionally, bug 758280 used 1px for the autohidden region size but the real size is 2px so we switch to that here.

Depends on D148833

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4db736ca2ba8
Allow identification of correct taskbar window for our screen on Windows r=cmartin
https://hg.mozilla.org/integration/autoland/rev/9b36e5d3771e
Clear autohidden taskbar region on Windows 10+ if drawing NC region r=cmartin

Comment 30

[Marian-Vasile Laza]

Backed out 2 changesets (Bug 642851) for causing wpt failures on modal-dialog-blocks-mouse-events.html.
Backout link
Push with failures <--> wpt11
Failure Log

Comment 31

[David Parks [:handyman]]

I'm just getting started looking into this but it does fail on my machine without the patches and it looks to have been intermittent for months (bug 1749149). The issue is that the test generates clicks on non-integral pixel locations because it divides by 2 to get them. The harness only allows integers. I need to determine if the test needs correcting (probably) or the harness. And why this unrelated patch triggered the behavior.

Comment 32

[siorenai]

This very old bug still exists today on a Windows 11 machine, running Firefox MSIX (the Microsoft Store app).

In my case the taskbar is docked at the bottom of the monitor and the white line is drawn at the bottom of the screen as well.

While Firefox's counterparts, such as Edge, which are also Microsoft Store apps, do not exhibit this behavior, a maximized Firefox window will draw a white line at the bottom of the screen, when the taskbar is set to auto-hide.

This does not happen if Firefox is in full-screen mode (F11).

I should note that I also use the MS app TranslucentTB, which at least provides the option for an opaque (black) taskbar, with which the white line does not appear.

Windows info:
Edition Windows 11 Pro
Version 21H2
Installed on ‎13/‎8/‎2022
OS build 22000.918
Experience Windows Feature Experience Pack 1000.22000.918.0

Pleeeeease fix this bug, because a lot of people use OLED screens and Firefox for many hours a day, and burn in is a REAL possibility with bugs suck as these!!!

Comment 33

[siorenai]

The bug in action on a maximized Firefox window.

Comment 34

[robsoncardin]

Yeah, it still happens (windows 10). It's not an exclusivity to firefox. Windows Explorer also does the same. It does not happen on windowed.

It's because the taskbar when auto-hidden is supposed to leave itself 1-2 pixels on screen, to be summoned by the mouse hovering. But if you do hide it ("Bins" for example has an option, or make it translucent with Glass2k or TranslucentTB), or remove it, completely with another app, Firefox and Windows Explorer will draw this annoying horrible white line on maximized screen. Edge does not do that... other programs does not do that. Some will leave a 1-2 pixels gap like Steam.
I wish it was at least a black line instead. This is terrifying for the oled crazy burn-in worried people like me.

Comment 35

[zalerasco]

(In reply to robsoncardin from comment #34)

Yeah, it still happens (windows 10). It's not an exclusivity to firefox. Windows Explorer also does the same. It does not happen on windowed.

It's because the taskbar when auto-hidden is supposed to leave itself 1-2 pixels on screen, to be summoned by the mouse hovering. But if you do hide it ("Bins" for example has an option, or make it translucent with Glass2k or TranslucentTB), or remove it, completely with another app, Firefox and Windows Explorer will draw this annoying horrible white line on maximized screen. Edge does not do that... other programs does not do that. Some will leave a 1-2 pixels gap like Steam.
I wish it was at least a black line instead. This is terrifying for the oled crazy burn-in worried people like me.

Not exclusive to Firefox that there are 1-2 pixels at the bottom of the screen, but drawing a white line instead of a black one or no render at all is Firefox's problem.

Comment 36

[acrivec+github]

It's so annoying that I can't get to my autohidden taskbar on top when firefox is maximized... Forced to use win key or to minimize firefox.

Comment 37

[acrivec+github]

Actually, seems to be Microsoft issue.

Comment 38

[Emilio Cobos Álvarez (:emilio)]

Seems like the test issue that caused this to get backed out was fixed in https://github.com/web-platform-tests/wpt/pull/35972, maybe this can reland?

I also wonder if instead of messing with the non-client area we should deal with taskbar autohide in NCHITTEST, but that was just an idle thought while I was looking at related issues.

Comment 39

[David Parks [:handyman]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #38)

Seems like the test issue that caused this to get backed out was fixed in https://github.com/web-platform-tests/wpt/pull/35972, maybe this can reland?

Seems it did, thanks.

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bb07fcac8fea
Allow identification of correct taskbar window for our screen on Windows r=cmartin
https://hg.mozilla.org/integration/autoland/rev/0ab04972b892
Clear autohidden taskbar region on Windows 10+ if drawing NC region r=cmartin

Comment 41

[Natalia Csoregi [:nataliaCs]]

Backed out for causing bustage on nsWindowGfx.cpp.

• backout: https://hg.mozilla.org/integration/autoland/rev/377d2b5eb530bcc0401efc706139bc65b0ce20b6
• push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=0ab04972b892257849cd2a873df96fd1ceada483&selectedTaskRun=OMKt37ntRiu8Xqy0uD5r1g.0
• failure log: https://treeherder.mozilla.org/logviewer?job_id=413515376&repo=autoland&lineNumber=77707

[task 2023-04-24T03:56:09.469Z] 03:56:09    ERROR -  /builds/worker/checkouts/gecko/widget/windows/nsWindowGfx.cpp(199,12): error: use of undeclared identifier 'ABE_TOP'; did you mean 'VA_TOP'?
[task 2023-04-24T03:56:09.469Z] 03:56:09     INFO -        case ABE_TOP:
[task 2023-04-24T03:56:09.469Z] 03:56:09     INFO -             ^~~~~~~
[task 2023-04-24T03:56:09.469Z] 03:56:09     INFO -             VA_TOP
[task 2023-04-24T03:56:09.469Z] 03:56:09     INFO -  /builds/worker/fetches/vs/Windows Kits/10/Include/10.0.17134.0/um/vssym32.h(93,2): note: 'VA_TOP' declared here
[task 2023-04-24T03:56:09.469Z] 03:56:09     INFO -          VA_TOP = 0,
[task 2023-04-24T03:56:09.470Z] 03:56:09     INFO -          ^
[task 2023-04-24T03:56:09.470Z] 03:56:09    ERROR -  /builds/worker/checkouts/gecko/widget/windows/nsWindowGfx.cpp(202,12): error: use of undeclared identifier 'ABE_LEFT'
[task 2023-04-24T03:56:09.470Z] 03:56:09     INFO -        case ABE_LEFT:
[task 2023-04-24T03:56:09.470Z] 03:56:09     INFO -             ^
[task 2023-04-24T03:56:09.470Z] 03:56:09    ERROR -  /builds/worker/checkouts/gecko/widget/windows/nsWindowGfx.cpp(205,12): error: use of undeclared identifier 'ABE_BOTTOM'; did you mean 'VA_BOTTOM'?
[task 2023-04-24T03:56:09.470Z] 03:56:09     INFO -        case ABE_BOTTOM:
[task 2023-04-24T03:56:09.471Z] 03:56:09     INFO -             ^~~~~~~~~~
[task 2023-04-24T03:56:09.471Z] 03:56:09     INFO -             VA_BOTTOM
[task 2023-04-24T03:56:09.471Z] 03:56:09     INFO -  /builds/worker/fetches/vs/Windows Kits/10/Include/10.0.17134.0/um/vssym32.h(95,2): note: 'VA_BOTTOM' declared here
[task 2023-04-24T03:56:09.471Z] 03:56:09     INFO -          VA_BOTTOM = 2,
[task 2023-04-24T03:56:09.471Z] 03:56:09     INFO -          ^
[task 2023-04-24T03:56:09.471Z] 03:56:09    ERROR -  /builds/worker/checkouts/gecko/widget/windows/nsWindowGfx.cpp(208,12): error: use of undeclared identifier 'ABE_RIGHT'
[task 2023-04-24T03:56:09.472Z] 03:56:09     INFO -        case ABE_RIGHT:
[task 2023-04-24T03:56:09.472Z] 03:56:09     INFO -             ^
[task 2023-04-24T03:56:09.472Z] 03:56:09     INFO -  4 errors generated.
[task 2023-04-24T03:56:09.472Z] 03:56:09    ERROR -  gmake[4]: *** [/builds/worker/checkouts/gecko/config/rules.mk:668: nsWindowGfx.obj] Error 1

Comment 42

[David Parks [:handyman]]

https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=OZnDUownQrSc-iWPSJd1aA.0&revision=32bb71a43fa2c54cc91a230f232d1ed84bf681b4

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/34c6c8476495
Allow identification of correct taskbar window for our screen on Windows r=cmartin
https://hg.mozilla.org/integration/autoland/rev/9e69ba4a6817
Clear autohidden taskbar region on Windows 10+ if drawing NC region r=cmartin

Comment 44

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/34c6c8476495
https://hg.mozilla.org/mozilla-central/rev/9e69ba4a6817

Comment 46

[Ray Kraesig [:rkraesig]]

@handyman: given the severity and the low intrusiveness of the fix, do you think this is worth uplifting to Beta?

Comment 47

[David Parks [:handyman]]

It's just over a week to the code freeze so I'm hesitant but clearing "unused" parts of the surface before rendering is indeed low risk, so let's roll the dice.

Comment 48

[David Parks [:handyman]]

Comment on attachment 9280536 [details]
Bug 642851: Clear autohidden taskbar region on Windows 10+ if drawing NC region r=cmartin!

Beta/Release Uplift Approval Request

• User impact if declined: Stray lines of pixels that are the wrong color on the boundary of the maximized window (on Windows 11).
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It clears the non-client region of the window because Windows is supposed to clip that area automatically but seems not to unless the area has been cleared. In other words, we are clearing pixels that were not supposed to be shown.
• String changes made/needed: N/A
• Is Android affected?: No

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9280535 [details]
Bug 642851: Allow identification of correct taskbar window for our screen on Windows r=cmartin!

This is a pretty old issue and we're down to our last Beta of the cycle. I think it'd be better to let this ride the 114 train instead. Let me know if you strongly disagree!

Comment 50

[David Parks [:handyman]]

Technically, the issue has migrated to be somewhat new (it's Windows 11) but it is mild enough that letting it ride the trains is totally fine.