Steps to reproduce: Open Display Properties->Effects. Change "show window contents while dragging" setting to unchecked. Grab lower-right corner of browser window on the border (not the grip) and drag. See window outline. Grab resize grip and drag. Browser window now resizes/redraws in realtime. Expected: Grabbing the resize grip and grabbing the border should yield the same result. Both should show an resizing outline if "show window contents while dragging" is unchecked, and both should cause the window to resize and redraw in realtime if the option is checked. I couldn't find a duplicate of this, so am opening new bug. Guessing component to be XP Apps: GUI features.

*** Bug 185598 has been marked as a duplicate of this bug. ***

Changing summary to 'Mozilla (resize grip, panes) should respect "show window contents while dragging" setting' to reflect the duped bug and cover things like the MailNews panes and such.

*** Bug 190485 has been marked as a duplicate of this bug. ***

*** Bug 196596 has been marked as a duplicate of this bug. ***

*** Bug 203280 has been marked as a duplicate of this bug. ***

*** Bug 208959 has been marked as a duplicate of this bug. ***

*** Bug 234000 has been marked as a duplicate of this bug. ***

*** Bug 244251 has been marked as a duplicate of this bug. ***

To fix this, Mozilla needs to handle the WM_NCHITTEST message. Mozilla should report HTBOTTOMRIGHT if the mouse cursor is over the resize grip. Windows then automatically changes the cursor, and if the user presses the left mouse button, Windows resizes the window. If the "show window contents while dragging" setting is disabled, only a resizing outline is shown (that's what this bug is about ;-) Handling the WM_NCHITTEST message is a standard technique; the status bar control of Windows and the IE do it the same way. The difficult part in implementing this is to detect if the mouse pointer is over the resize grip. Because the message WM_NCHITTEST is sent with every mouse move, the implementation must be very efficient.

*** Bug 248094 has been marked as a duplicate of this bug. ***

*** Bug 356385 has been marked as a duplicate of this bug. ***

Seems related to bug 365657.

This appears to be working on Windows 6 and 6.1 in the latest trunk builds.

(In reply to comment #14) > This appears to be working on Windows 6 and 6.1 in the latest trunk builds. Not here [1] (nightly build on Windows XP SP3). Note that the resize grip works and window resizing also works. This bug's scope is that resizing with the resize grip (not using the window bottom right border's resize handler, the resize grip is inside the window) does cause the window contents to be redrawn while the resize operation occurs (when it shouldn't whenever the "Show window contents while dragging" setting is disabled). Given that resizing with the bottom right border works as expected, this bug is even useful for testing redraw/content re-flow issues, but nevertheless this is IMO a small issue (with a beneficial side-effect, currently). :-) [1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090824 Namoroka/3.6a2pre (.NET CLR 3.5.30729)

As has been commented on previously the issue is the sizing grip does not respond correctly to WM_NCHITTEST messages. The code should return HTBOTTOMRIGHT to this message when the cursor is over the sizing grip. Windows will then step in and do resizing in exactly the same way as when you click on the border. To some people this is a small issue but to me it's an annoyance. I'm the author of "Sizer" (www.brianapps.net/sizer) a program that allows users to resize windows to exact dimensions. It relies on hooking into WM_NCHITTEST messages to work correctly. Because Mozilla does this incorrectly, it causes issues for my program and I get a lot of emails from users saying my Sizer doesn't work.

This is loosely based on the GTK2 implementation from bug 118299.

...which means it has nothing to do with WM_NCHITTEST, unfortunately for Brian.

(In reply to comment #15) >(In reply to comment #14) > >> This appears to be working on Windows 6 and 6.1 in the latest trunk builds. > >Not here [1] (nightly build on Windows XP SP3). Ok, Will double check that windows setting for this on Windows Vista/7 when I get home tonight. There also is a fair number of bugs about window resize events triggering reflow. A few of those mention the Windows setting in their comments.

Comment on attachment 396414 [details] [diff] [review] Proposed patch Trying new module owner ;-)

ah man I failed the job. I did a reorg of my inbox rules for reviews and forgot to check the new folder. :) So now I have a bunch of reviews to catch up on. Will be doing all of those tomorrow. Sorry for the delay.

That certainly fixes the problem. I didn't see any issues with every window I could open that had a grip. Hopefully it'll address Brian's issues as well. One change I went ahead and made, moving BeginResizeDrag up into the SECTION: nsIWidget::Move, nsIWidget::Resize, nsIWidget::Size section rather than placing it at the end of the file.

wince bustage fix: http://hg.mozilla.org/mozilla-central/rev/e866b92b28c4

(In reply to comment #23) > wince bustage fix: > > http://hg.mozilla.org/mozilla-central/rev/e866b92b28c4 Original changeset: 51b055be91bb

(In reply to comment #19) > (In reply to comment #15) > > >(In reply to comment #14) > > > >> This appears to be working on Windows 6 and 6.1 in the latest trunk builds. > > > >Not here [1] (nightly build on Windows XP SP3). > > Ok, Will double check that windows setting for this on Windows Vista/7 when I > get home tonight. > > I just realized I hadn't followed up on this. Retesting Vista (Win NT 6), I turned off the setting, so not sure if I got a fixed build yet, but I see the border respects setting, but grip still shows window contents. Will have to check the grip in a later build just to make sure.

This appears to have caused build failures and eventual timeout in test_resizer.xul (part of "mochitest-plain"): { > 86147 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_resizer.xul | Bad x for -1,-1 moving -1,-1 - got 200, expected 195 > 86148 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_resizer.xul | Bad y for -1,-1 moving -1,-1 - got 200, expected 195 > 86149 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_resizer.xul | Bad width for -1,-1 moving -1,-1 - got 300, expected 305 [snip] > 86434 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/base/test/test_resizer.xul | Bad height for 1,1 moving 1,1 - got 300, expected 305 > buildbot.slave.commands.TimeoutError: command timed out: 1200 seconds without output } http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1253920141.1253923490.9617.gz WINNT 5.2 mozilla-central test mochitests on 2009/09/25 16:09:01 That's not a known sporadic failure, and this looks pretty related, and nothing else in the guilty range looks related: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8b4d2fc47ecf&tochange=1aaedcad1634 Any thoughts? Should this be backed out?

This test failed in the subsequent cycle, as well (but without a timeout this time): http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1253924866.1253927132.17780.gz They also began failing on another box, with the same blame-range: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1253927225.1253928418.32089.gz Haven't gotten a response here, so I'm backing it out myself & reopening.

backout wince fix: http://hg.mozilla.org/mozilla-central/rev/325d29d32cf6 backout orig patch: http://hg.mozilla.org/mozilla-central/rev/2890940edd67

(In reply to comment #25) > Will have to check the grip in a later build just to make sure. Verified the patch fixes the gripper and border to respect the windows setting on Vista (NT 6) /Win 7 (NT 6.1) using latest trunk hourly 1253926411 - 19:40 build.

Comment on attachment 403020 [details] [diff] [review] With test fix Bah, I tried and failed to use :jimm :-(

Neil, Re-tested the latest trunk hourly on win7 and works. How was the test result?

Pushed changeset 1823ac975b47 to mozilla-central. (In reply to comment #32) > How was the test result? Not sure what you mean here; we can't automatically test native resizing.

Comment on attachment 403020 [details] [diff] [review] With test fix Nice bit of UI polish.

(In reply to comment #33) > Pushed changeset 1823ac975b47 to mozilla-central. > > (In reply to comment #32) > > How was the test result? > Not sure what you mean here; we can't automatically test native resizing. I just meant the new "with test fix" patch fixed the test which borked before.

Whoops, forgot to mark the bug resolved ;-) (In reply to comment #35) > I just meant the new "with test fix" patch fixed the test which borked before. It fixed nothing; it just stopped the now inapplicable test from running.

Comment on attachment 403020 [details] [diff] [review] With test fix approval1.9.2 requests aren't currently being monitored, since we're nearing RC freeze and there are too many outstanding requests, so I'm clearing this request. Feel free to re-request approval if you are confident that it's worth drivers' time to consider whether this non-blocker needs to land for 1.9.2 at this stage.