STR: 1. Uncheck "load hoem page" for new windows or new tabs. 2. Create new window/tab 3. Load new page by dragging link/webloc into content area or blank tab's widget Results: focus still in URL bar Expected: focus in content area, like with normal page loads. See also bug 299548 and bug 310395. Wevah, do you think the same "call" is not being made in all three of these bugs?
Synching severity and target with the other two...sorry for the bugspam.
I've found what may be another symptom of this. Steps To Reproduce: 1. Cmd-L 2. Begin typing something that will have auto-complete options 3. Click on one of the the auto-complete options (confirmed on 1.0 and various other builds by several on #camino)
(In reply to comment #2) > I've found what may be another symptom of this. Steps To Reproduce: > > 1. Cmd-L > 2. Begin typing something that will have auto-complete options > 3. Click on one of the the auto-complete options I think that's a separate bug, and one that may be a WONTFIX. (We can debate that elsewhere once it's filed.) Ian, you wanna take this one, since you're fixing the other two "see also" bugs? If you can't, I probably can. This should be pretty simple. cl
Oh, heh. This is busted for the same reason that bug 173658 is. When we drop something onto the content area, Gecko code takes over and looks for a drag event sink. The |overContentArea| check is a no-op, since AFAICT it doesn't actually check properly for a drag terminating over the content area. One way around this bug (and only this bug) may be to tweak the assignment of overContentArea in performDragOperation: so that it actually works properly. What we *really* ought to do is to focus the control that is the target of the drag, but that's going to be pretty complicated (see bug 173658). CCing Josh and Mark on this one too.
12 years ago
Any ideas on how to address comment 4?
Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
I think properly implementing comment 4 is what ought to happen, but that's going to require some work in Widget:Cocoa, since all the D&D code now lives there. (CHBrowserView implemented it at the time, but no longer.) Kicking this to Widget:Cocoa for now.