Open Bug 315504 Opened 19 years ago Updated 2 years ago

Loading a page in a blank window/tab via drag-drop fails to focus content area

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect

Tracking

()

People

(Reporter: alqahira, Unassigned)

References

Details

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.
Severity: normal → minor
Target Milestone: --- → Camino1.1
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.
Any ideas on how to address comment 4?
Assignee: mikepinkerton → nobody
QA Contact: general
Target Milestone: Camino1.1 → Camino1.2
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*.
Target Milestone: Camino1.6 → ---
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.
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
Product: Camino → Core
QA Contact: general → cocoa
Hardware: Macintosh → All
Blocks: 332913
Assignee: joshmoz → nobody
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.