Closed Bug 489258 Opened 11 years ago Closed 11 years ago
[MSFT-12113] Firefox window doesn't maintain docked position when minimized and restored
Description of the Problem: Firefox window doesn't maintain docked position when minimized and restored. Detailed Steps to Reproduce the Problem: 1. Install Windows 7 2. Install Firefox from www.firefox.com 3. Launch Firefox 4. Dock it to the right of the screen using mouse 5. Minimize Firefox (using the minimize button or Winkey + M) 6. Restore Firefox by clicking on the icon in the Superbar 7. Actual Result - Firefox is restored to its location before it was docked to the right of the screen Note: This behavior is not consistent with other Internet Browsers: Internet Explorer. Tester/Developer Notes: Firefox was installed on a machine and launched. The size of the window of Firefox was adjusted using the WinKey +M, and then re-sized using the icon on the Superbar, however Firefox did not resume it original position on the screen. Al's Note: I don't see the Superbar (just gadgets) in the public build of Windows 7 so I was unable to verify this bug. Marking this for 1.9.1 by default but we should find out what version of Firefox was used and if we can get access to a more current Windows 7 build.
On trunk this isn't reproducible. Both side docking and maximization on top restore correctly. For 3.5 though, max works, but side dock does something really strange, it restores to the docked position, then repositions to the old window position before the doc. Tracking down the different landings is going to be a pain, so I'll just debug and see if I can come up with a 1.9.1 one off for a future 3.5.x update release.
The bug was present on both trees but was masked by changes in our focus related code. This is the same bug fix as 191 with the addition of a new poschanged event handler. building some 191 try builds before reviews to do some final release build testing.
Doh, debug code leftovers - + static bool sbFlip = false; That will be removed from the final 191 patch. :)
minor nit - updated the bug number in the comments. Tested on 1.9.1 with a release build, looks good. https://firstname.lastname@example.org/
ditto. https://email@example.com/ With trunk, the problem was mitigated by other landings, but the same underlying problem is there so it's worthy of fixing.
I'm not sure if this is a helpful comment, but this also happens in the 64-bit version of Windows 7.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
This push seems to have accidentally reverted the change made in bug 504499. Oops! (We'll fix it again, just a heads up to be careful.)
Comment on attachment 389204 [details] [diff] [review] sizemode fix for 191 v.1 Approved for 184.108.40.206, a=dveditz for release-drivers
Attachment #389204 - Flags: approval220.127.116.11? → approval18.104.22.168+
(In reply to comment #13) > (From update of attachment 389204 [details] [diff] [review]) > Approved for 22.214.171.124, a=dveditz for release-drivers http://hg.mozilla.org/releases/mozilla-1.9.1/rev/25498faa9c88
How exactly do we turn on the super bar for docking?
(In reply to comment #15) > How exactly do we turn on the super bar for docking? Not sure I understand the question. You can pin apps to the taskbar (which display as icons as in the old quick launch) by right clicking the icon of a running instance. Docking on the desktop should "just work" by dragging the window toward an edge. Also, some features of the new taskbar are not enabled if you do not have the aero interface enabled, which is often the case if you run it in an image.
You need to log in before you can comment on or make changes to this bug.