Closed Bug 185533 Opened 18 years ago Closed 11 years ago

Mozilla (resize grip, panes) should respect "show window contents while dragging" setting

Categories

(Core :: Widget: Win32, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: nnbugzilla, Assigned: neil)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

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.
Summary: Resize grip should respect "show window contents while dragging" setting → Mozilla (resize grip, panes) should respect "show window contents while dragging" setting
Blocks: 190485
No longer blocks: 190485
*** 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.
Product: Core → Mozilla Application Suite
*** Bug 248094 has been marked as a duplicate of this bug. ***
*** Bug 356385 has been marked as a duplicate of this bug. ***
Assignee: bross2 → win32
Component: XP Apps: GUI Features → Widget: Win32
Product: Mozilla Application Suite → Core
QA Contact: pawyskoczka → ian
Seems related to bug 365657.
Duplicate of this bug: 399305
OS: Windows 98 → Windows XP
Blocks: 365657
Assignee: win32 → nobody
QA Contact: ian → win32
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.
Attached patch Proposed patch (obsolete) — Splinter Review
This is loosely based on the GTK2 implementation from bug 118299.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #396414 - Flags: review?(emaijala)
...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 ;-)
Attachment #396414 - Flags: review?(emaijala) → review?(jmathies)
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.
Attached patch Updated patch (obsolete) — Splinter Review
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.
Attachment #396414 - Attachment is obsolete: true
Attachment #402877 - Flags: review?(jmathies)
Attachment #396414 - Flags: review?(jmathies)
Attachment #402877 - Flags: review?(jmathies) → review+
(In reply to comment #23)
> wince bustage fix:
> 
> http://hg.mozilla.org/mozilla-central/rev/e866b92b28c4

Original changeset: 51b055be91bb
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Attached patch With test fixSplinter Review
Attachment #402877 - Attachment is obsolete: true
Attachment #403020 - Flags: review?(enndeakin)
Attachment #403020 - Flags: review?(jmathies)
Comment on attachment 403020 [details] [diff] [review]
With test fix

Bah, I tried and failed to use :jimm :-(
Attachment #403020 - Flags: review?(enndeakin) → review+
Attachment #403020 - Flags: review?(jmathies) → review+
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.
Attachment #403020 - Flags: approval1.9.2?
(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.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
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.
Attachment #403020 - Flags: approval1.9.2?
You need to log in before you can comment on or make changes to this bug.