Last Comment Bug 622376 - Dragging a link to an existing tab doesn't work anymore
: Dragging a link to an existing tab doesn't work anymore
Status: RESOLVED FIXED
: regression
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: -- normal (vote)
: seamonkey2.1b2
Assigned To: Philip Chee
:
Mentors:
: 628011 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-01 18:10 PST by H. Hofer
Modified: 2011-01-28 02:47 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
final+


Attachments
Link hovering over the center of a tab (75.35 KB, image/jpeg)
2011-01-02 17:25 PST, H. Hofer
no flags Details
Link hovering to the far right of a tab (70.25 KB, image/jpeg)
2011-01-02 17:31 PST, H. Hofer
no flags Details
Link hovering in safe mode (67.74 KB, image/jpeg)
2011-01-02 19:14 PST, H. Hofer
no flags Details
Link hovering in new profile (33.27 KB, image/jpeg)
2011-01-04 04:42 PST, H. Hofer
no flags Details
Patch v1.0 Not enough .screenX (1.11 KB, patch)
2011-01-26 01:35 PST, Philip Chee
neil: review+
Details | Diff | Splinter Review

Description H. Hofer 2011-01-01 18:10:09 PST
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 2011-01-02 12:06:01 PST
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 2011-01-02 17:25:23 PST
Created attachment 500722 [details]
Link hovering over the center of a tab

But drag target is on the left...
Comment 3 H. Hofer 2011-01-02 17:31:11 PST
Created attachment 500723 [details]
Link hovering to the far right of a tab

Now the target is on top of the tab...
Comment 4 H. Hofer 2011-01-02 17:37:06 PST
(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 2011-01-02 18:43:00 PST
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 2011-01-02 18:47:09 PST
> 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 2011-01-02 19:14:25 PST
Created attachment 500734 [details]
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 2011-01-04 03:40:05 PST
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 2011-01-04 04:42:38 PST
Created attachment 500991 [details]
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 2011-01-04 06:59:29 PST
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 2011-01-04 08:39:16 PST
(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 2011-01-04 10:07:24 PST
> You are not able to reproduce this effect?
nyet, nein, non, nada, zilch.
Comment 13 H. Hofer 2011-01-04 22:07:06 PST
(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 2011-01-05 03:38:16 PST
> 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 2011-01-21 00:32:50 PST
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 2011-01-21 03:54:51 PST
Aha! Good work Sherlock! And Neil told me that changing .x to .screenX would be sufficient
Comment 17 neil@parkwaycc.co.uk 2011-01-21 04:00:54 PST
Well, there was something else that needed to be changed to .screenX and I apologise for not spotting it.
Comment 18 Philip Chee 2011-01-22 23:42:56 PST
*** Bug 628011 has been marked as a duplicate of this bug. ***
Comment 19 Philip Chee 2011-01-26 01:35:49 PST
Created attachment 507061 [details] [diff] [review]
Patch v1.0 Not enough .screenX
Comment 20 Philip Chee 2011-01-26 04:41:43 PST
Pushed to comm-central
http://hg.mozilla.org/comm-central/rev/dc224a735250

Note You need to log in before you can comment on or make changes to this bug.