75.35 KB, image/jpeg
70.25 KB, image/jpeg
67.74 KB, image/jpeg
33.27 KB, image/jpeg
1.11 KB, patch
|Details | Diff | Splinter Review|
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.
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
Created attachment 500722 [details] Link hovering over the center of a tab But drag target is on the left...
Created attachment 500723 [details] Link hovering to the far right of a tab Now the target is on top of the tab...
(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.
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.
> 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.
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).
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?
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.
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?
(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?
> You are not able to reproduce this effect? nyet, nein, non, nada, zilch.
(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).
> 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.
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.
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.
blocking-seamonkey2.1: --- → ?
Version: unspecified → Trunk
Created attachment 507061 [details] [diff] [review] Patch v1.0 Not enough .screenX
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #507061 - Flags: review?(neil)
Pushed to comm-central http://hg.mozilla.org/comm-central/rev/dc224a735250
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.