622376 - Dragging a link to an existing tab doesn't work anymore

Status: RESOLVED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[H. Hofer]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110101 SeaMonkey/2.1b2pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110101 SeaMonkey/2.1b2pre

Probably since the landing of Bug 484968, existing tabs don't accept links as a drag target anymore.
Dragging is only possible to create a new tab before or after an existing one.

Reproducible: Always

Steps to Reproduce:
1. Open at least two tabs in browser
2. Browse to website with links.
3. Try to drag a link from one tab to another

Actual Results:  
The drop target arrow appears to the left or the right of the target tab. If the link is dropped, a new tab opens.

Expected Results:  
The arrow should appear on top of the existing tab. When dropped, the link should load in this tab.

Comment 1

[Philip Chee]

WORKSFORME:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110101 SeaMonkey/2.1b2pre

I remember testing for this exact scenario when working on Bug 484968

Comment 2

[H. Hofer]

Attachment: Link hovering over the center of a tab

But drag target is on the left...

Comment 3

[H. Hofer]

Attachment: Link hovering to the far right of a tab

Now the target is on top of the tab...

Comment 4

[H. Hofer]

(In reply to comment #1)
> WORKSFORME:
> 
> I remember testing for this exact scenario when working on Bug 484968

Well, on my two machines (XP and Windows 7) it doesn't, as least not really:

I found out, you have to drag to the far right of the tab to make it accept the link (see attachment 500723 [details], sorry IrfanView didn't capture the hovering link...).

In attachment 500722 [details], the link is hovering around the center of the tab, but it drops either to the left or the right.

Comment 5

[Philip Chee]

I notice that the new tabs button is on the right; and the all tabs button close tabs button are on the left. You appear to have some userChrome.css or an extension that puts the tabstrip into RTL direction. This might be confusing our drag-drop code. Please retest in safe-mode and/or remove any userChrome.css modifications you might have made.

Comment 6

[Philip Chee]

> Created attachment 500723 [details]
> Link hovering to the far right of a tab

> Now the target is on top of the tab...

Notice that the mouse is hovering over where the tab should be if the tabs were in RTL order as the rest of the tabstrip is. My code should deal with RTL ordering but only if all the elements of the tabstrip are in RTL mode not just some RTL and some LTR.

Comment 7

[H. Hofer]

Attachment: Link hovering in safe mode

(In reply to comment #5)

> Please retest in safe-mode and/or remove any userChrome.css modifications you might have made.

Same in safe mode (with or without sidebar).

Comment 8

[Philip Chee]

Create a new SeaMonkey profile for testing purposes:
<http://kb.mozillazine.org/Profile_manager#Creating_a_new_profile>
DO NOT install any extensions into it or customize it in any way. Does the problem exist in this new profile?

Comment 9

[H. Hofer]

Attachment: Link hovering in new profile

(In reply to comment #8)

> Create a new SeaMonkey profile for testing purposes

As you can see it's still wrong, but the offsets are smaller:
i.e., if you drag a _little bit_ more to the right, the drop target jumps to the right of the tab. Then, if you drag still a _little bit_ more to the right, it jumps back to the center of the tab.

Comment 10

[Philip Chee]

The code we use should put the drop indicator over the centre of the tab as long as the mouse pointer is within the middle 50% of the tab. So even if the middle of the tab isn't where we think it is, the indicator shouldn't jump backwards if you continue moving to the right, it should just jump to the next drop point to the right.

So I'm grasping at straws but at the OS level do you have a mouse driver with mouse acceleration turned on, or some non-linear scaling, or a "snap to" option?

Comment 11

[H. Hofer]

(In reply to comment #10)
> So I'm grasping at straws but at the OS level do you have a mouse driver with
> mouse acceleration turned on, or some non-linear scaling, or a "snap to"
> option?

No. Both machines have vanilla PS/2 Mice (Logitech without drivers on XP, Genius without drivers on Vista).

You are not able to reproduce this effect?

Comment 12

[Philip Chee]

> You are not able to reproduce this effect?
nyet, nein, non, nada, zilch.

Comment 13

[H. Hofer]

(In reply to comment #12)
> nyet, nein, non, nada, zilch.

Well, I don't know how to help now...

Are Venkman or Chromebug working again with SM 2.1?
If so, I could try some debugging, once I got the time (after Jan. 17).

Comment 14

[Philip Chee]

> Are Venkman or Chromebug working again with SM 2.1?
God knows. mutter mutter.

> If so, I could try some debugging, once I got the time (after Jan. 17).
That's very good of you to offer to help since as far as I can tell you're the only one who has noticed this strange behaviour.

Comment 15

[H. Hofer]

I seem to have narrowed it down further:
The problem seems to be in the coordinate calculation by '.screenX'.

If I push the browser window to the left edge of the screen, everything works as expected.

When I start to move the window towards the right, everything get offset by the number of pixels moved until it seems to pass a threshold, where it doesn't hit the correct tab anymore.

Of course, everything also works, if the browser is full screen. But I never use it that way.

Hope this helps a little.

Comment 16

[Philip Chee]

Aha! Good work Sherlock! And Neil told me that changing .x to .screenX would be sufficient

Comment 17

[[e-mail]]

Well, there was something else that needed to be changed to .screenX and I apologise for not spotting it.

Comment 19

[Philip Chee]

Attachment: Patch v1.0 Not enough .screenX

Comment 20

[Philip Chee]

Pushed to comm-central
http://hg.mozilla.org/comm-central/rev/dc224a735250