Last Comment Bug 666246 - Accidentally dragging a single tab moves it to the right edge of the tab bar.
: Accidentally dragging a single tab moves it to the right edge of the tab bar.
Status: RESOLVED FIXED
:
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: unspecified
: x86 Windows 2000
: -- minor (vote)
: seamonkey2.5
Assigned To: Philip Chee
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-22 06:52 PDT by Stefan A. Möller
Modified: 2011-08-03 22:55 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed
fixed


Attachments
Patch v1.0 Return early if source index == destination index (1.67 KB, patch)
2011-07-24 21:15 PDT, Philip Chee
neil: review+
Details | Diff | Splinter Review
Patch v1.1 as checked in. r=Neil (1.93 KB, patch)
2011-07-25 08:18 PDT, Philip Chee
philip.chee: review+
iann_bugzilla: approval‑comm‑aurora+
iann_bugzilla: approval‑comm‑beta+
Details | Diff | Splinter Review

Description Stefan A. Möller 2011-06-22 06:52:09 PDT
User-Agent:       Mozilla/5.0 (Windows NT 5.0; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1
Build Identifier: Mozilla/5.0 (Windows NT 5.0; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1

If you have only one single tab opened, and then accidentally drag this tab a little bit, it jumps to the right edge of the tab bar.

Reproducible: Always

Steps to Reproduce:
1. Set browser.tabs.autoHide to "false".
2. Close all but one tab.
3. Grab this tab with the mouse and move it a little bit in any direction, a few pixels are enough.
4. Release the mouse button.

Actual Results:  
Tab jumps to the right edge of the tab bar.

Expected Results:  
Tab should not move.
Comment 1 Philip Chee 2011-06-23 06:01:49 PDT
Eeek.
Comment 2 Philip Chee 2011-07-24 19:12:29 PDT
[13:01:28]<RattyAway>NeilAway: eek Bug 666246 - Accidentally dragging a single tab moves it to the right edge of the tab bar.
[13:01:33]<RattyAway>How do I fix this?
[13:10:24]<NeilAway>RattyAway: check for aDestIndex != aSrcIndex perhaps
[13:11:59]<NeilAway>RattyAway: actually, in moveTabTo, just changing the check to aDestIndex > aSrcIndex seems to fix it for me
Comment 3 Philip Chee 2011-07-24 21:15:04 PDT
Created attachment 548092 [details] [diff] [review]
Patch v1.0 Return early if source index == destination index

> in moveTabTo, just changing the check to aDestIndex > aSrcIndex seems to fix it for me
Didn't work for me. I looked at the Firefox implementation and it returns early when the destination position is the same as the source position. Also nothing checks the return value of moveTabTo so I removed the return value.
Comment 4 neil@parkwaycc.co.uk 2011-07-25 01:16:23 PDT
Comment on attachment 548092 [details] [diff] [review]
Patch v1.0 Return early if source index == destination index

>             this._browsers = null; // invalidate cache
>             this.mLastRelatedIndex = 0;
Nit: don't need to do this if we're not actually going to move the tab.
Comment 5 Philip Chee 2011-07-25 08:13:37 PDT
I found the Firefox bug that fixed the same problem:
Bug 541393 - gBrowser.moveTabTo(gBrowser.selectedTab, 0) with only one tab open moves the tab after the new tab button
Comment 6 Philip Chee 2011-07-25 08:18:37 PDT
Created attachment 548188 [details] [diff] [review]
Patch v1.1 as checked in. r=Neil

Pushed
http://hg.mozilla.org/comm-central/rev/bb52e3b67d0a
Comment 7 Philip Chee 2011-07-25 08:20:59 PDT
Comment on attachment 548188 [details] [diff] [review]
Patch v1.1 as checked in. r=Neil

This bug was exposed when I made the tabbar scrollable. Needs backporting to SeaMonkey 2.4 and 2.3. Too late for 2.2.

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