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

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: nnbugzilla, Assigned: neil)

Tracking

(Blocks 1 bug)

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
*** Bug 185598 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

17 years ago
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
(Assignee)

Updated

17 years ago
No longer blocks: 190485
(Assignee)

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

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

Comment 7

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

Comment 8

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

Comment 9

15 years ago
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

Comment 12

13 years ago
Seems related to bug 365657.

Updated

12 years ago
Duplicate of this bug: 399305

Updated

10 years ago
OS: Windows 98 → Windows XP

Updated

10 years ago
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)

Comment 16

10 years ago
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.
(Assignee)

Comment 17

10 years ago
Posted 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)
(Assignee)

Comment 18

10 years ago
...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.
(Assignee)

Comment 20

10 years ago
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.
Posted 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)

Updated

10 years ago
Attachment #402877 - Flags: review?(jmathies) → review+
(Assignee)

Comment 24

10 years ago
(In reply to comment #23)
> wince bustage fix:
> 
> http://hg.mozilla.org/mozilla-central/rev/e866b92b28c4

Original changeset: 51b055be91bb
Status: ASSIGNED → RESOLVED
Last Resolved: 10 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.
(Assignee)

Comment 30

10 years ago
Posted patch With test fixSplinter Review
Attachment #402877 - Attachment is obsolete: true
Attachment #403020 - Flags: review?(enndeakin)
(Assignee)

Updated

10 years ago
Attachment #403020 - Flags: review?(jmathies)
(Assignee)

Comment 31

10 years ago
Comment on attachment 403020 [details] [diff] [review]
With test fix

Bah, I tried and failed to use :jimm :-(

Updated

10 years ago
Attachment #403020 - Flags: review?(enndeakin) → review+

Updated

10 years ago
Attachment #403020 - Flags: review?(jmathies) → review+
Neil, Re-tested the latest trunk hourly on win7 and works.  How was the test result?
(Assignee)

Comment 33

10 years ago
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.
(Assignee)

Comment 34

10 years ago
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.
(Assignee)

Comment 36

10 years ago
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
Last Resolved: 10 years ago10 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.