360779 - Drag n drop links to open tab causes leftmost tab to load link

Status: RESOLVED FIXED

(Camino Graveyard :: Drag & Drop, defect)

Description

[Ben Thompson]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061114 Camino/1.1a1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061114 Camino/1.1a1+

When dragging a link to an existing open tab, the link actually gets loaded into the leftmost tab rather than the intended one. Dropping links onto empty space on the tab bar still correctly loads the link in a brand new tab.

Camino 1.0.3 loads the intended tab correctly so appears to be a regression since then.

Reproducible: Always

Steps to Reproduce:
1. Open 3 tabs
2. Load a page in the second tab
3. Drag a link on the second tab page to the third tab


Actual Results:  
Link loads in the leftmost tab 

Expected Results:  
Link should open in the tab it was dragged onto

This is a standard installation of Camino, no extensions/enhancements are installed. Computer is running a stock build of 10.4.8 PPC.

Comment 1

[Stuart Morgan]

Confirming.  Broke between 11/6 and 11/8, so it's almost certainly bug 320668.

Comment 2

[Stuart Morgan]

Yeah, for raw URL handling we replaced a loop that did the right thing in the single-url case but a variety of bad things in the multi-url case with a loop that pretty much always does the wrong thing (basically the same behavior as bug 321055).

Comment 3

[Ben Thompson]

(In reply to comment #2)
> Yeah, for raw URL handling we replaced a loop that did the right thing in the
> single-url case but a variety of bad things in the multi-url case with a loop
> that pretty much always does the wrong thing (basically the same behavior as
> bug 321055).
> 

Ok, cheers for checking - I did see bug 321055 before posting but wasn't sure it was the same thing or not. 

Comment 4

[Stuart Morgan]

Attachment: fix for the single-bookmark case

This fixes the single-URL case and improves the logic of the tab DnD handler to prevent this kind of thing from happening again by treating all sources of URLs the same.

The multi-URL case is still broken, but it's broken in exactly the same way it always has been, and fixing that belongs in bug 321055. (This does change the behavior of DnD of tab groups slightly, in that it used to be special-cased to remove all extra tabs and now is treated like any other multi-URL source, but I think consistency is a good thing.)

Comment 5

[Maximilian Ruderburg [:max] (Arctic Revolution)]

Comment on attachment 245904 [details] [diff] [review]
fix for the single-bookmark case

r=me on the code. I didn't test it though.

(Also can you give 8 lines of context in future patches? It makes reviewing easier.)

Comment 6

[Stuart Morgan]

Comment on attachment 245904 [details] [diff] [review]
fix for the single-bookmark case

Someone should put this through its paces.

Comment 7

[Stuart Morgan]

Attachment: unbitrotted

Same great taste, now without bitrot.

Comment 8

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

Comment on attachment 247149 [details] [diff] [review]
unbitrotted

r=ardissone; everything seems halal to me.

Comment 9

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 247149 [details] [diff] [review]
unbitrotted

sr=pink

Comment 10

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH