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

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

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.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Attachment: Patch

I think that the minimum size of border on blank area should be the system default value rather than 3px.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Attachment: Patch

Updated my strange comment.

Comment 3

[Jim Mathies [:jimm]]

for content click testing once I get this built.

Comment 4

[Jim Mathies [:jimm]]

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.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Hmm, it seems that NS_MOUSE_MOZHITTEST event doesn't work with content area??

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Attachment: Patch

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.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=116a81c7e855

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Comment on attachment 633374 [details] [diff] [review]
Patch

Er, maybe, we should do the hit test at "==" too.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Attachment: Patch

https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=4e97796f60d7

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a0ede175182d

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/a0ede175182d

Comment 12

[Jim Mathies [:jimm]]

backed out:

https://hg.mozilla.org/mozilla-central/rev/9c743145c60d

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

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.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

Attachment: Additonal change

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.

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

test builds here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-87fc79d4f05a/

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

jimm: ping

test builds will be:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=ff17ce2f2a2d

Comment 17

[Jim Mathies [:jimm]]

Comment on attachment 639214 [details] [diff] [review]
Additonal change

Sorry! dropped off the radar.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4abd71e551a2
https://hg.mozilla.org/integration/mozilla-inbound/rev/51daf14fd1f6

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4abd71e551a2
https://hg.mozilla.org/mozilla-central/rev/51daf14fd1f6