173658 - Dragging multiple webloc files or bookmarks to content area, only one opens

Status: RESOLVED DUPLICATE of bug 92737

(Core :: Widget: Cocoa, defect)

Description

[Nalmar]

When I take 2 .webloc files on the desktop and drag them on the sidebar, only
one bookmark is created

Comment 1

[Greg K.]

Nalmar, what build ID are you reporting this bug against?

Comment 2

[Simon Fraser [no longer active]]

I'll have to figure out how cocoa handles multiple drag items (if it can).

Comment 3

[Jasper]

Bump, we landed code to handle multiple .webloc and .url drag to the dock and
tab bar so I asume it shouldn't be to difficult anymore to also accept it for
the conent area.

Comment 4

[Jasper]

Hm seems I didn't read the summary that well, the person who fixes this bug
might aswell fix that dragging multiple files to the content area aswell :)

Comment 5

[Josh Aas]

bumping this to 0.9 as it strikes me as a pretty big problem that we don't
handle this correctly

Comment 6

[Josh Aas]

This bug is now really about two issues:

1. Dragging two webloc files to the bm manager only adds one bm
2. Dragging two webloc files to the content area only opens one bm

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sorry if you've already checked this scenario out, but can one drag multiple
weblocs to the tab bar and get multiple new tabs?  

I can't tell right now because of bug 269995 and bug 265994. (However, dragging
two weblocs to a single tab widget does load one in the tab and create a new tab
to load the second.)

Comment 8

[Josh Aas]

I'm not going to get to this.

Comment 9

[Bruce Davidson]

Happy to take this one on as it appears to be resolved by the latest patch for
the regression in bug 155484. With that patch dragging two webloc files to the
BMM creates two bookmarks; dragging them to the tab bar creates two tabs.

Comment 10

[Bruce Davidson]

This was fixed by one of the regression patches on bug 155484 that Pink checked
in yesterday.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #6)

> 2. Dragging two webloc files to the content area only opens one bm

This particular issue is still present, so reopening.   Everything else seems to
work great!

Comment 12

[Samuel Sidler (old account; do not CC)]

Updating summary to reflect the actual bug now as mentioned in comment 11.

Bruce, can you fix this last issue?

Comment 13

[Josh Aas]

-> wevah as he's good at this stuff

Wevah: It would be really nice to have this for 0.9, but until we have a patch I'm bumping it from the list. 
Feel free to mark this 0.9 if you can come up with something.

Comment 14

[Samuel Sidler (old account; do not CC)]

Wevah, have you had a chance to look at this?

Comment 15

[Wevah (Nate Weaver)]

(In reply to comment #14)
> Wevah, have you had a chance to look at this?

I looked at it back when it was assigned to me; there's code in our tab bar
class that checks if it's dropped on the content area, but I don't know if it
actually gets drags to the content area at all.

Comment 16

[Chris Lawson (gone)]

I might be able to take a look at this soon-ish if Wevah can't. I'll add it to my to-do list.

cl

Comment 17

[Chris Lawson (gone)]

(In reply to comment #15)
> (In reply to comment #14)
> > Wevah, have you had a chance to look at this?
> 
> I looked at it back when it was assigned to me; there's code in our tab bar
> class that checks if it's dropped on the content area, but I don't know if it
> actually gets drags to the content area at all.

This is a bug in Mac widget code. The nsIDragHelperService isn't properly accepting multiple drags.

CCing Mark and Josh for more input.

cl

Comment 18

[Chris Lawson (gone)]

(In reply to comment #17)
> This is a bug in Mac widget code. The nsIDragHelperService isn't properly
> accepting multiple drags.

Either that, or we're not properly processing them in CHBrowserView.mm. I haven't entirely decided which :-\

cl

Comment 19

[Chris Lawson (gone)]

OK, here's the deal.

|performDragOperation:| handles this in CHBrowserView.mm (line 1319). It calls |findEventSink:forPoint:inWindow|, which finds the widget at the drag target and QIs to an event sink.

We need to see if the widget at the drag target is something that can accept text drags (like, for example, a <textarea> or <input type="text">) or if it's just the generic "content area". If it's the content area, we need to handle the drag in Camino's code itself, but if it's a widget that accepts text drags, we need NOT to break our current drag-n-drop functionality.

I'm not real clear on how to accomplish the above, but hopefully this will make some sense to Josh and/or Mark.

cl

Comment 20

[Chris Lawson (gone)]

If you keep the Bookmarks Manager open in one window and keep a second window for browsing (I don't do this personally but I've talked to users who do), and you try to drag multiple bookmarks from the manager to another Camino window's content area, only the first one loads. The root problem is the same as with supported .*loc files.

Right now, dragging a Camino bookmark from the manager onto the content area of a second window behaves exactly the same as if you had dragged a .webloc file. If you drop the bookmark on a textarea, you get the URL inserted in the textarea. If you drop it on the content area, you get it loaded in that tab.

This should also be fixed. The same logic can be applied to both with this if statement:

if ([[[sender draggingPasteboard] types] containsObject:kCaminoBookmarkListPBoardType] || [[sender draggingPasteboard] containsURLData])

cl

Comment 21

[Chris Lawson (gone)]

This same code is also responsible for bug 315504, as far as I can tell, so if that's not fixed by the time someone gets around to this one, whomever fixes this should take a look over there too.

cl

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Simon wrote/fixed a lot of the drag code in the 0.9 era so we could actually drag to textareas/inputs instead of trying to load dragged items as URLs or simply rejecting drags (see bug 168378, bug 225862, and their dupes).

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Can anyone provide some guidance re: comment 19?

Comment 24

[Chris Lawson (gone)]

Comment 19 should have been able to be accomplished the same way we implemented |isTextFieldFocused| in CHBrowserView.mm (currently at line 1386). When I wrote comment 19, it would have been really easy to fix on our end if I had only known what to look for. (Hindsight is 20/20, I guess.)

However, bug 332913 moved this to Widget:Cocoa (and probably would have regressed any fix I had written at the time), so I'm going to do what we should have done two years ago and kick it over there.