Closed Bug 733630 Opened 10 years ago Closed 10 years ago

It's difficult to resize window by dragging top border of it if the window shows Firefox button

Categories

(Core :: Widget: Win32, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla20

People

(Reporter: masayuki, Assigned: masayuki)

References

()

Details

(Keywords: regression)

Attachments

(2 files, 3 obsolete files)

If Firefox button is displayed, it seems that the top border of the window is collapsed. At that time, I can see the mouse cursor which is for resizing (N-S, NW-SE, NE-SW) only on the topmost edge (maybe only 1px). It make me difficult to resize the window by dragging the top border of the window.

Opera keeps the top window border except on the Opera button.
Attached patch Patch (obsolete) — Splinter Review
I think that the minimum size of border on blank area should be the system default value rather than 3px.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #631872 - Flags: review?(jmathies)
Attached patch Patch (obsolete) — Splinter Review
Updated my strange comment.
Attachment #631872 - Attachment is obsolete: true
Attachment #631872 - Flags: review?(jmathies)
Attachment #631877 - Flags: review?(jmathies)
for content click testing once I get this built.
Comment on attachment 631877 [details] [diff] [review]
Patch

(In reply to Jim Mathies [:jimm] from comment #3)
> for content click testing once I get this built.

Per this test, this patch prevents the user from clicking content along a 1px border around the content area. We can't filter mouse clicks here.
Attachment #631877 - Flags: review?(jmathies) → review-
Hmm, it seems that NS_MOUSE_MOZHITTEST event doesn't work with content area??
Attached patch Patch (obsolete) — Splinter Review
Okay, I see the cause. We're not performing to do the hit test if the result is left, right or bottom border. We should do it when cursor is inside the mNonClientMargin.
Attachment #631877 - Attachment is obsolete: true
Attachment #633374 - Flags: review?(jmathies)
Comment on attachment 633374 [details] [diff] [review]
Patch

Er, maybe, we should do the hit test at "==" too.
Attachment #633374 - Flags: review?(jmathies)
Attachment #633384 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/a0ede175182d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Depends on: 769212
Depends on: 769214
backed out:

https://hg.mozilla.org/mozilla-central/rev/9c743145c60d
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Wow, sorry for such big mistake and thank you for the report and backout. I'll check this tomorrow if I can, but maybe, next week.
Attached patch Additonal changeSplinter Review
I separated the additional change to this patch. If you like landing a patch, let me know it.

The cause is, contentMayOverlap indicates if content may overlap the border. So, it's not necessary check. We need to do the hit test inside window border too.
Attachment #639214 - Flags: review?(jmathies)
Comment on attachment 639214 [details] [diff] [review]
Additonal change

Sorry! dropped off the radar.
Attachment #639214 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/4abd71e551a2
https://hg.mozilla.org/mozilla-central/rev/51daf14fd1f6
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.