The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in seamonkey2.1b2

Status

SeaMonkey
Tabbed Browser
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: H. Hofer, Assigned: Philip Chee)

Tracking

({regression})

Trunk
seamonkey2.1b2
regression

Firefox Tracking Flags

(blocking-seamonkey2.1 final+)

Details

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
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.
(Assignee)

Comment 1

6 years ago
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
(Reporter)

Comment 2

6 years ago
Created attachment 500722 [details]
Link hovering over the center of a tab

But drag target is on the left...
(Reporter)

Comment 3

6 years ago
Created attachment 500723 [details]
Link hovering to the far right of a tab

Now the target is on top of the tab...
(Reporter)

Comment 4

6 years ago
(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.
(Assignee)

Comment 5

6 years ago
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.
(Assignee)

Comment 6

6 years ago
> 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.
(Reporter)

Comment 7

6 years ago
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).
(Assignee)

Comment 8

6 years ago
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?
(Reporter)

Comment 9

6 years ago
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.
(Assignee)

Comment 10

6 years ago
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?
(Reporter)

Comment 11

6 years ago
(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?
(Assignee)

Comment 12

6 years ago
> You are not able to reproduce this effect?
nyet, nein, non, nada, zilch.
(Reporter)

Comment 13

6 years ago
(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).
(Assignee)

Comment 14

6 years ago
> 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.
(Reporter)

Comment 15

6 years ago
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.
(Assignee)

Comment 16

6 years ago
Aha! Good work Sherlock! And Neil told me that changing .x to .screenX would be sufficient
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well, there was something else that needed to be changed to .screenX and I apologise for not spotting it.
(Assignee)

Updated

6 years ago
Duplicate of this bug: 628011
blocking-seamonkey2.1: --- → ?
Keywords: regression
Version: unspecified → Trunk
(Assignee)

Comment 19

6 years ago
Created attachment 507061 [details] [diff] [review]
Patch v1.0 Not enough .screenX
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #507061 - Flags: review?(neil)

Updated

6 years ago
Attachment #507061 - Flags: review?(neil) → review+
(Assignee)

Comment 20

6 years ago
Pushed to comm-central
http://hg.mozilla.org/comm-central/rev/dc224a735250
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
blocking-seamonkey2.1: ? → final+
(Assignee)

Updated

6 years ago
Target Milestone: --- → seamonkey2.1b2
You need to log in before you can comment on or make changes to this bug.