Closed Bug 4647 Opened 26 years ago Closed 25 years ago

[PP]Draggable frame separator impossible to drag

Categories

(Core :: Layout: Form Controls, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: ramiro)

References

()

Details

Open apprunner, see the mostly closed sidebar on the left When you mouse over the separator between the frames, the cursor will change to a cross. Try to drag the sidebar open and it's almost impossible. You can only do it if you move the mouse about 3 pixels at a time and let the frame separator catch up before moving the mouse again. I think the separator frame is losing focus when the mouse moves outside of it. We had similiar problems on macOS a while ago because we weren't grabbing all events correctly. cc'ing sdagley because he was in on that fix.
Actually pierre fixed the old/previous problem by baking sure that if the mouse was still down the initially clicked object kept getting the mouse moved events even when the cursor was no longer over the initial object boundary.
I confirm what Steve said. Two notes: - Don't forget to dispatch NS_MOUSE_ENTER and NS_MOUSE_EXIT in addition to NS_MOUSE_MOVE. - On the Mac, the EventHandler keeps pointers on the "lastWidgetHit" and "lastWidgetPointed" in order to send the different NS_MOUSE events to the right widgets. We had the following problem: if we AddRef these pointers, we get circular references on the widgets and it causes memory leaks or windows that never close; if we don't AddRef, the widgets can go away in our back and we crash the next time we try to access them. The solution was to not AddRef them but make them notify a "nsDeleteObserver" when they are deleted. But maybe nothing of this applies to Unix?
Assignee: karnaze → ramiro
yes, i know about this problem and its one of the top items for me to fix. thanks for the hints and info reassigning to myself
Summary: Draggable frame separator impossible to drag → [PP]Draggable frame separator impossible to drag
Status: NEW → ASSIGNED
Target Milestone: M5
marking assigned m5, assigned.
------- Additional Comments From alecf@netscape.com 04/13/99 17:47 ------- Some comments on the observed behavior: The frame seems to drag correctly if the mouse is over the splitter at during the end of when the splitter is redrawn. if the mouse moves outside the splitter area during the redraw, then the splitter thinks that dragging is over. However, it also seems to remember that the mouse is down, so the next time you enter the splitter's drawing area, it thinks the mouse is down and will allow you to drag (again, assuming the mouse stays inside the splitter's drawing area) basically I think it's saying something like: while (mouseIsDown && mouseisoversplitter) redraw(); when it should have captured the mouse until the mouseUp, and then said: while (mouseIsDown) redraw(); ...I think somehow by not capturing the mouse, it's also not receiving the mouseUp event...
*** Bug 4630 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
the problem was that we were not remembering the "drag" target widget. I added some code to do this, that fixes this problem. However, because our resizing code is jerky, the frame resizing is jerky as well. At least you can resize frames and the apprunner side bar now. marking fixed.
to verify this bug, see demo 9 on the viewer, or try resizing the apprunner side bar. if you find problems, which there are some remaining wrt to resizing stuff, please file them as separate bugs. thanks.
Status: RESOLVED → VERIFIED
verifying that this is fixed. i'll search bugzilla for the jittery resize and the seemingly lost mouse-up event. (sometimes the frame separator follows the cursor after mouseup).
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
You need to log in before you can comment on or make changes to this bug.