Closed Bug 11291 Opened 25 years ago Closed 25 years ago

Drag that starts in url bar shows drop feedback on toolbars

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: buster)

References

Details

Click on the text in the url bar and drag it so that you select some text. Now keep the mouse down and move the mouse outside the text widget to the far right, using some slop to select all the text to the right of the cursor. Notice that the drop feedback on the toolbar now kicks in, even though all you're doing is selecting text and not actually dragging anything.
Status: NEW → ASSIGNED
Summary: Drag that starts in url bar extends out into toolbars → Drag that starts in url bar shows drop feedback on toolbars
Target Milestone: M9
accepting bug for M9
Target Milestone: M9 → M10
This happens because there is no mouseListener on the text widget so the mouse down is bubbling up to the toolbar mouseListener. We don't want this to happen, but instead want a mouseListener on the text widget to interpret the click and drag accordingly and not let the event bubble. The toolbar will still get the mouseMoved event, but it will be meaningless because it never saw the initial mouseDown. I can put in something to get this working for now until Ender lands, but we really need to wait for Ender as form elements to do this right. Moving to M10.
i have a fix for this until ender lands and will check it in. However, I'll keep this bug open until so we can revisit when ender lands.
Blocks: 12666
Whiteboard: waiting for gfx text widget to land
Target Milestone: M10 → M11
pushing out, waiting on ender to land to make sure all is ok.
Whiteboard: waiting for gfx text widget to land → 1 day, waiting for gfx text widget to land
Target Milestone: M11 → M12
moving to m12. this is just polish and i already have a solution that will probably work alright when ender lands (though i'll have to stop calling it a hack at that point, i guess).
moving all d&d post beta. Lame.
moving dogfood-related d&d stuff back to M12. woohoo!
Whiteboard: 1 day, waiting for gfx text widget to land
Now that gfx widgets have landed, we need to make sure that drag-gesture events don't leak out into the containing content. Since this is mostly relevant for html form controls, it needs to live in C++ (we can't hang JS that eats the event off every form control in a webpage), and probably within the editor code. my only question/concern is how it would interact with the real ender d&d code. since none of that exists yet, i don't quite know where to shim this listener in and I don't want to do anything stupid. buster? any ideas? i have the listener already written, just need ot know where i should put it.
it'll take a little research. since this bug is marked M12, I'll have to defer looking at it for a few days. sorry. ping me again thursday or friday, after M11 lands. thanks!
this is also a to-do for gfx scrollbars.
Priority: P3 → P1
P1, working on this next.
Assignee: pinkerton → buster
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → Editor
kicking this off to buster after adding a line to the nsEditorDragListener that doesn't bubble dragGesture events. The problem now is that there are _two_ nsEventStateManagers under an ender text widget and they can still confuse each other at times, such as when you start the drag w/in the text and continue it off the end of the text. This is now an ender- specific problem, washing my hands of it ;) I've done all that I know how to do.
QA Contact: phillip → sujay
Status: NEW → ASSIGNED
is this really P1? It's not dogfood. Is it really M12?
no, that's just what i had it at as i was finishing up the drag&drop stuff. feel free to change these to reflect your own priorities.
Priority: P1 → P3
Target Milestone: M12 → M13
thanks for the quick response, pink. changing to M13, P3.
I don't see this happening any more on windows. Pink? Sujay? Is this a problem on any platform today?
yes, it does still happen. the way that you reproduce it is to start dragging w/ in the text and then drag out into the area of the url bar where there is no text. On the console, you will see the printout: ******** GENERAL DRAG *********** which means that the drag gesture has bubbled up to the top level navigator window and the dump() was tripped by the handler registered there. The event should not bubble to the top.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fixed in M13. I don't know if this fix will be migrated back to M12 or not.
verified in 12/21 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.