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

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.

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.

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.

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

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

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.

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.

Mass-moving undated nsbeta2+ bugs to M18

fixed

marking fixed

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

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