37835 - Splitter/grippy stopped working

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Steve Lamm]

The splitter no longer collapses in the sidebar. You cannot drag it closed and
you cannot click on the grippy.

Comment 1

[Peter Trudelle]

Why is this tagged as a smoketest blocker?  We should not be holding the tree
closed for minor bugs like this, especially ones with no real downside, and easy
workarounds.

Comment 2

[Steve Lamm]

If there is an easy workaround, I would like to use it.
Maybe this should not be marked as a smoketest blocker. However, I marked it as
such because it has to do with events not propagating properly anymore. Seems
like the kind of thing that will be harder to fix the longer we wait. 

The bug I really care about is 36628 ("visibility: collapsed" not working). That
makes all the sidebar panels stick open and it is blocking my current feature
work on the sidebar.

Comment 3

[Eric Vaughan]

Drag to close now works. Click to close is broken because of a regression in the 
event state manager. Trying to get a simple testcase together so I can reassigne 
this to joki.

Comment 4

[John Morrison]

Eric -- how about these for testcases (from 
http://bugzilla.mozilla.org/show_bug.cgi?id=23060)

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8416
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8417

Comment 5

[Eric Vaughan]

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

Comment 6

[Eric Vaughan]

This seems to have been caused by a regression in the event state manager. Here 
is how you reproduce:

1) Save out the attached file as "test.xul"
2) open it in viewer
3) click on the little blue grippy on the splitter

RESULT:
Nothing happens

Expected:
The splitter should snap closed.

The problem is on that in button (nsButtonBoxFrame) gets both a mouse down and a 
mouse up but no mouse clicked. The complicated part here is that the splitter 
(nsSplitterFrame) does a mouse grab. This has work correctly from many many 
months but broke a while back when some changes were made to the event state 
manager.

Comment 7

[joki (gone)]

Eric, thanks for the great test case.  So the problem turns out to be this: 
selection code in nsFrame is calling mouseCapture along with your splitterFrame 
code and confusing the splitter, making it think that it has capture.  The 
result is that the mousedown goes to the right place but the mouseup goes to the 
splitterframe since it thinks it has capture.  The eventstatemanager doesn't 
dispatch a click since the mousedown/up were on different frames.

I'd say you either need to change your splitterframe logic or discuss the 
captureMouse issue with mjudge and his selection code, though the problem 
doesn't seem to be necessarily with the multiple capture calls but confusion in 
splitterframe over whether it has capture.

Comment 8

[Peter Trudelle]

Mass-moving undated nsbeta2+ bugs to M18

Comment 9

[Eric Vaughan]

fixed

Comment 10

[John Morrison]

marking fixed

Comment 11

[John Morrison]

for 20000526nn mac/linux/win32 builds, the splitter can be collapsed either 
dragging or clicking .... whoohoo!

Comment 12

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.