If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
Widget: Cocoa
--
minor
12 years ago
8 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

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

Comment 2

12 years ago
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)

Comment 3

12 years ago
(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

Comment 4

12 years ago
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.
Depends on: 173658
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 → ---

Comment 7

9 years ago
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

Updated

9 years ago
Blocks: 332913

Updated

9 years ago
Assignee: joshmoz → nobody
You need to log in before you can comment on or make changes to this bug.