Open Bug 1224803 Opened 4 years ago Updated 4 months ago

Firefox window is not full height after using Windows 10 Aero snap

Categories

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

45 Branch
x86_64
Windows 10
defect

Tracking

()

People

(Reporter: t_edwards, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: polish, Whiteboard: tpi:+)

Attachments

(3 files)

Attached image aero_snap.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151113030248

Steps to reproduce:

1. Install Firefox on Windows 10 version 1511 ("November Update" / "Threshold 2"). My monitor setup may also be relevant: I run at 2560x1080 resolution with the taskbar on the left. See attached screenshot.
2. Snap Firefox to the left or right side of the screen.
3. Observe how there is a small gap at the bottom of the screen.
4. Snap an Explorer window to the other side of the screen.
5. Try to use Windows 10's new snapped window resize bar. It won't appear.
6. Manually drag the bottom of the Firefox window down until it hits the bottom of the screen.
7. Re-snap the Explorer window to its side of the screen (or manually adjust it to be flush with Firefox).
8. Try to use the snap resize bar again. It will work correctly; both windows will resize in synch with each other.
9. Notice that sometimes once you release the mouse after the resize operation Firefox is again not full-height and the snap resize bar cannot be used. At other times it remains full-height.



Expected results:

Firefox's window height should equal to screen height after being aero snapped.
Hi Tom,

I have tested the problem and I can't reproduce it. I have tested on Win 10, with FF 45.0a1(2015-11-16), with new profile, resolution was 1920x1080 and the taskbar on the left. Everything is has a normal display. Please download the Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.
You can try to create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Please test if the issue can be reproduced in the safe mode of Firefox: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Please see if this problem is reproduce on other browsers, like: chrome, internet explorer.
Flags: needinfo?(t_edwards)
Component: Untriaged → Page Info Window
I tried everything you suggested and the bug still occurred, though I couldn't reproduce it at 1920x1080. Neither Internet Explorer nor Edge suffer from the problem.

I've actually found that switching to 1920x1080 fixes the problem even after I've switch back to 2560x1080. It remains fixed until restart my user session (i.e. log out/in).

Firefox/Nightly doesn't have to be running when you change resolution to benefit which makes me inclined to blame the OS, but then again this issue doesn't occur with any other programs...
Flags: needinfo?(t_edwards)
Hi Tom, 

Thank you for your time regarding this problem. Maybe is a OS problem like you suggested, I will investigate this problem in the future, but for now I will change the status to resolved works for me, knowing the fact that you can't reproduce this at 1920x1080.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
Ovidiu, that's not what "works for me" means! Could you redirect this bug to someone who is equipped to reproduce the issue please?
Status: RESOLVED → UNCONFIRMED
Component: Page Info Window → General
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Resolution: WORKSFORME → ---
Hi Tom, 

I will be able to test the issue on a display with this resolution: 2560x1080, in a few days, when I will be equipped with the proper display.
I can reproduce the problem with win10 1280*1024 monitor as well

Str
1. Open browser
2. Key press Windows key+Left arrow key
3. Close browser and restart

Actual results
The problem appears

Expected results:
Browser should be restore with previous size
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: windows-10
Component: General → Widget: Win32
Product: Firefox → Core
I am having the same bug on 1920x1080. Reproduced on a Win 10 PC with 1366 x 768 resolution as well. I actually created another bug report after failing to find this one. Please see the same results here, with some screenshots. https://bugzilla.mozilla.org/show_bug.cgi?id=1231584

This is not a problem with Chrome or any other application on my PC. This happened as soon as I installed Windows 10; wasn't a problem on Windows 8.1 and earlier. Tested by creating new Firefox profiles as well.
Duplicate of this bug: 1231584
Might be relevant to jaws' interest.
Since filing this bug I've noticed that this problem applies to some other programs:

Windows Media Player
Notepad++
Thunderbird
A simple WPF application made in Visual Studio
Blender

Unaffected programs include:

Windows Explorer
Universal Apps
A simple Windows Forms application made in Visual Studio
Visual Studio
Steam
CMake-GUI (which uses Qt)
CMD / PowerShell

There's clearly _something_ that Firefox needs to do to move from one group to the other.
This appears to have been fixed in Firefox 47. It's still happening in Thunderbird 45 though.
I am still getting this issue in 47.1.  Running 2560 x 1440 resolution.
I am seeing the issue on 47.0.1 too in 2560 x 1600 resolution. But there might be solution. The issue started appearing after the Windows 10 installation and also affected my own utility written in AutoHotKey to position any application window. It started to incorrectly position the Firefox window too.

Turns out the window frames are the problem as they are invisible, but bigger then the visible window. It is necessary to it the new window position by this offset (you might end up with negative numbers). Maybe the same change could be implemented in Firefox. Though I am not sure how one can save position and use the same numbers to restore it and fail - perhaps a wrong set of methods was used, which previously gave same results, but now are differentiated by the offset.

The final code for this is as follows. Written in AutoHotKey language, but seems to be pretty readable (the ; signs are for comments). Now when called like this - MoveWindow (0, 0, 1000, 1000) - it positions the Firefox window perfectly.


MoveWindow(posleft, postop, posright, posbottom)
{
    hwnd:=WinExist("A")                         ;get window handle
    _RECT:="Int left, Int top, Int right, Int bottom"
    rect:=new _Struct(_RECT)                      ;create structure
    frame:= new _Struct(_RECT)

    DllCall("GetWindowRect","Uint",hwnd,"Uint",rect[]) ;get window position

   DllCall("dwmapi\DwmGetWindowAttribute"
      , "Uint", hwnd 
      , "Int", 9 ; DWMWA_EXTENDED_FRAME_BOUNDS,
      , "Uint", frame[]
      , "Uint", 16) ; sizeof(RECT)

   border := new _Struct(_RECT)
   border.left := frame.left  - rect.left
   border.top := frame.top  - rect.top
   border.right := rect.right  - frame.right
   border.bottom := rect.bottom - frame.bottom

   rect.left := posleft
   rect.top := postop
   rect.right := posright
   rect.bottom := posbottom

   rect.left -= border.left
   rect.top -= border.top
   rect.right += border.right
   rect.bottom += border.bottom

 
   DllCall("SetWindowPos"
      , "UInt", hwnd ;handle
      , "UInt", 0 ;HWND_TOP
      , "Int", rect.left ;x
      , "Int", rect.top ;y
      , "Int", rect.right - rect.left ;width
      , "Int", rect.bottom - rect.top ;height
      , "UInt", 0x4000) ;SWP_ASYNCWINDOWPOS

}
Keywords: polish
Priority: -- → P4
Whiteboard: tpi:+
Hi, Having the same issue with Firefox 50.0 in 1920x1080.

Stumbled upon this bug as I've noticed the same behavior on my Firefox installation. I can reproduce this issue reliably in Firefox 68, 69 and 70 (nightly). This is on Windows 10 LTSC running with an Intel HD 520 graphics card on a Surface Book.

Firefox window after opening a new instance after having it snapped when closing the browser.

This screenshot shows Firefox properly snapped to the right of the screen.

You need to log in before you can comment on or make changes to this bug.