86740 - Mac windows automatically grow by 1 pixel (both v and h) for a click and release in the grow area

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Scott Collins]

click and release (without moving the mouse) in the grow box of Mac window

expected behavior:
  grow outline should draw, then go away
  no change should occur in layout

actual behavior
  window grows by 1 pixel horizontally and vertically
  page reflows

Comment 1

[Mike Pinkerton (not reading bugmail)]

F.

Comment 2

[basic]

Changing platform

Comment 3

[Simon Fraser [no longer active]]

Sounds like this is being caused by some code that pierre put in to fix an older 
bug.

Comment 4

[Pierre Saslawsky]

Related to bug 6988 and bug 12672. See my comments from [1999-10-11 16:12] in bug 
6988.

Comment 5

[John Morrison]

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

Comment 6

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 7

[John Morrison]

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

Comment 8

[lws]

Attachment: Bug patch...

werd...

Comment 9

[Mike Pinkerton (not reading bugmail)]

the +1's are from the fix for bug 6988. in what cases do we still need them?
only on os9?

Comment 10

[lws]

In comment number 6 from bug 6988 it says it would entitle moving the 
live-resizing code from nsMacMessagePump to nsMacWindow.  This has 
been done.   It may still need those +1's in OS 9, I doubt it does, but I 
haven't checked.  Also with BoundsChanged events calling SizeWindow, 
which is the root cause of this bug, is not necessary.  As long as the 
variables for the size passed to it are not changed from the current 
window size the Resize function does not call SizeWindow, luckily. When 
the +1's were there it was calling SizeWindow. If there is a problem on 
OS9 then there is a discrepancy with the window bounds reported to us, 
though apple probably won't fix something that small, so maybe it would 
be wise to make Resize also accept zeros to not call SizeWindow.

Furthermore, this is probably a CarbonLib bug also. 
kEventWindowBoundsChanged should not be sent at the same time as 
kEventWindowResizeComplete (unless on OS 9), BoundsChanged 
should only be sent if the bounds really do change(which would be the 
case on OS 9).  Anybody want to submit this to apple's radar website?

Comment 11

[Mike Pinkerton (not reading bugmail)]

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

Comment 12

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 83936 [details] [diff] [review]
Bug patch...

r=pink

i tried this on os9 and it seems the behavior we were trying to correct has
gone away.

Comment 13

[Blake Ross]

Comment on attachment 83936 [details] [diff] [review]
Bug patch...

rs=blake

Comment 14

[Mike Pinkerton (not reading bugmail)]

landed on trunk. requesting branch approval. this is a very simple fix to take
that fixes an annoying polish quirk.

Comment 15

[Judson Valeski]

please land on the 1.0.1 branch ASAP. once landed, please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.

Comment 16

[scottputterman]

adding adt1.0.1+.  Please check into the 1.0 branch as soon as possible.

Comment 17

[Mike Pinkerton (not reading bugmail)]

landed on trunk and branch.