179656 - (MoveTabs) Allow drag-and-drop reordering of tabs

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, enhancement, P1)

Description

[Ben Escoto]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4

It would be nice if tabs could be dragged.  When searching I found a similar bug
for Mozilla:

http://bugzilla.mozilla.org/show_bug.cgi?id=113934

but phoenix and mozilla seem to use different tab systems so maybe this isn't a
duplicate?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[David P James]

The tabbed browsing extension enables this behaviour (tabs can be dragged along
the tab bar and repositioned).

-->WONTFIX

Comment 2

[Simon Paquet [:sipaq]]

*** Bug 204346 has been marked as a duplicate of this bug. ***

Comment 3

[Brant Gurganus]

VERIFYING obvious WONTFIX bugs.  Filter on firebirdWontFix to filter these bugs.
 I skipped a few that I'm unsure about from their summary and will manually go
through them.

Comment 4

[Jason Barnabe (np)]

*** Bug 232259 has been marked as a duplicate of this bug. ***

Comment 5

[Simon Paquet [:sipaq]]

*** Bug 233837 has been marked as a duplicate of this bug. ***

Comment 6

[Jesse Ruderman]

*** Bug 238822 has been marked as a duplicate of this bug. ***

Comment 7

[Jesse Ruderman]

"There is an extension that does this" is never a valid reason to WONTFIX a
feature request.  If anything, it is a reason *not* to WONTFIX a request,
because it indicates that someone wants the feature enough to implement it as an
extension.  Reopening.

Like most features that involve dragging, this feature would add no UI
complexity, so I see no reason to WONTFIX it.

There is a problem with Opera's partial implementation of this feature that
makes it annoying: it will often interpret a click on a tab as an attempt to
drag it.  Opera fails to activate the clicked tab as a result.  But there's no
reason for Firefox to duplicate that annoying behavior -- starting to drag a tab
could activate it (bug 218146?), or a drag could start only when the cursor
leaves the tab (cf bug 211818).

Comment 8

[shadytrees]

Just a FYI: Mozilla has a sister bug for this. Probably bears no relevance on 
this one, though.
http://bugzilla.mozilla.org/show_bug.cgi?id=105885

Comment 9

[Neil Paris]

Confirming; -> Tabbed Browser; -> All, All; Slightly updated summary.

Comment 10

[Bill Mason]

*** Bug 250477 has been marked as a duplicate of this bug. ***

Comment 11

[Richard Corbin]

Just a quick question. If an extension that performs the re-ordering exists,
then would it not be easy to build this into Firefox?

Found out about this through a post on Asa's blog:
http://weblogs.mozillazine.org/asa/archives/006125.html

The extension which does a god job of drag n drog of tabs is the "MiniT
(drag+indicator) extension":
http://update.mozilla.org/extensions/moreinfo.php?id=176&vid=335&category=Tabbed%20Browsing

I am not sure whether it's an easy process to port an extension into the core
Firefox code, but thought I'd make it known that an extension exists to resolve
this if checked in.

Rgds, Rich

Comment 12

[Ricardo Sánchez-Sáez]

The tabbrowser extension
(http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en) does this too. It
also add functionality requested in this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=159357 and a *bunch* of other useful
tab related features. The problem is that it is slow and buggy as hell.

Comment 13

[shadytrees]

The problem with extensions is that the extension is often a hack and a proper
fix would require patching the actual Firefox code. Dunno if this is one of
those cases or not. A Mozillazine thread did mention that TBE does this along
the lines of closing the tab you're trying to drag and then re-opening it at a
different location, so that it looks like it's been dragged and dropped.

Comment 14

[Bill Mason]

*** Bug 254022 has been marked as a duplicate of this bug. ***

Comment 15

[junk]

Yeah, just installed MiniT. Awesome (though comments note it doesn't work on OSX).

I don't see why something so basic (well, basic to the whole "tabs" idea anyway)
and helpful isn't added right into the browser.

Comment 16

[José Jeria]

*** Bug 261568 has been marked as a duplicate of this bug. ***

Comment 17

[José Jeria]

*** Bug 261909 has been marked as a duplicate of this bug. ***

Comment 18

[Peter van der Woude [:Peter6]]

*** Bug 262075 has been marked as a duplicate of this bug. ***

Comment 19

[Tuukka Tolvanen (sp3000)]

*** Bug 263829 has been marked as a duplicate of this bug. ***

Comment 20

[Fareed Rizkalla]

neat feature for 1.0

Comment 21

[Wolf [:wolf]]

Only aviary peers can set blocking +/- flags.. Everybody else should nominate ?
the flag for a peer ro grant or deny. :-)

Comment 22

[Fareed Rizkalla]

nominating

Comment 23

[Johnny Stenback (:jst)]

We're waaaay tooooo close to 1.0 final to even dream about taking a change like
this. blocking-aviary1.0-

Comment 24

[Ricardo Sánchez-Sáez]

Is it really that hard to implement?

The "MiniT Drag+Indicator" extension
http://update.mozilla.org/extensions/moreinfo.php?id=176&vid=797 does this
feature only, and it seems the code it is pretty small.

I think a lot of new users would find this very useful: it is one of those
little things that add up to make Firefox clearly superior to MS Explorer.

Comment 25

[Johnny Stenback (:jst)]

Hard or not, it's way too late for new features. And it's not like it's trivial,
may not be a ton of code, but it's certainly not low-impact at this stage in any
way...

Comment 26

[Phil Ringnalda (:philor)]

*** Bug 266635 has been marked as a duplicate of this bug. ***

Comment 27

[Bill Mason]

*** Bug 270837 has been marked as a duplicate of this bug. ***

Comment 28

[Ian Macfarlane]

Isn't this a dupe of bug 105885 ?

Comment 29

[José Jeria]

(In reply to comment #28)
> Isn't this a dupe of bug 105885 ?

That one is for Suite, this one is Firefox specific

Comment 30

[Phil Ringnalda (:philor)]

*** Bug 273462 has been marked as a duplicate of this bug. ***

Comment 31

[Bill Mason]

*** Bug 274332 has been marked as a duplicate of this bug. ***

Comment 32

[Gilles Durys]

*** Bug 276472 has been marked as a duplicate of this bug. ***

Comment 33

[Benjamin Lippelt]

What about to target this for Firefox1.1 or maybe Firefox1.2?

Comment 34

[:Gavin Sharp [email: [e-mail]]]

*** Bug 276793 has been marked as a duplicate of this bug. ***

Comment 35

[Peter van der Woude [:Peter6]]

*** Bug 277961 has been marked as a duplicate of this bug. ***

Comment 36

[Ravi]

since there are a million duplicates for this bug, i'm ex

eventhough portability might be an issue for this feature i'm asking for but i
would like to see the drag and drop work across different open windows of
firefox. this extends the tab organization capability that firefox is so popular
for.

essentially i would like to drag a tab from one open window to another. the
destination window could show this as new tab as it's rightmost tab. wether or
not the source window continues to display the moved tab is a use case based
decision upto the design team.  -rk

Comment 37

[James Norris]

(In reply to comment #36)
> since there are a million duplicates for this bug, i'm ex
> 
> eventhough portability might be an issue for this feature i'm asking for but i
> would like to see the drag and drop work across different open windows of
> firefox. this extends the tab organization capability that firefox is so popular
> for.
> 
> essentially i would like to drag a tab from one open window to another. the
> destination window could show this as new tab as it's rightmost tab. wether or
> not the source window continues to display the moved tab is a use case based
> decision upto the design team.  -rk


This is a nice idea, personally, I would like to be able to dock windows that
firefox 'forgot' for force into a new tab into a tab on my main window.

Comment 38

[Sameer Ajmani]

A related feature I'd like to see is the ability to convert a tab to a separate
browser window.  This could be done by dragging the tab to the desktop or as a
right-click-menu option ("Open Tab in New Window").  This is expecially useful
if you want to bookmark the remaining tabs in the old window together.

Comment 39

[Phil Ringnalda (:philor)]

*** Bug 280101 has been marked as a duplicate of this bug. ***

Comment 40

[:Gavin Sharp [email: [e-mail]]]

*** Bug 282404 has been marked as a duplicate of this bug. ***

Comment 41

[Hiro]

The patch is submitted with bug105885. 
https://bugzilla.mozilla.org/attachment.cgi?id=174710

Firefox might also do fix by a similar change. 

Comment 42

[Worcester12345]

(In reply to comment #23)
> We're waaaay tooooo close to 1.0 final to even dream about taking a change like
> this. blocking-aviary1.0-

Not too close for 1.1.

(In reply to comment #24)
> Is it really that hard to implement?

Is it?

(In reply to comment #25)
> Hard or not, it's way too late for new features. And it's not like it's trivial,
> may not be a ton of code, but it's certainly not low-impact at this stage in any
> way...

"This stage" has passed, and it is now a good time.


(In reply to comment #33)
> What about to target this for Firefox1.1 or maybe Firefox1.2?


Please do.


(In reply to comment #41)
> The patch is submitted with bug105885. 
> https://bugzilla.mozilla.org/attachment.cgi?id=174710
> 
> Firefox might also do fix by a similar change. 

There you go! I can't wait for the fix to come in.

Comment 43

[:Gavin Sharp [email: [e-mail]]]

*** Bug 284540 has been marked as a duplicate of this bug. ***

Comment 44

[Paul Feakins]

I've just tried MiniT Drag+Indicator and it is awesome! This is a feature I feel
Firefox really needs to implement in release 1.1 or 1.2.

It makes you wonder why programs in the Windows task bar can't reordered by
dragging and dropping...

Comment 45

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The code in the MiniT extension isn't very good (or wasn't - apparently it's
been rewritten since I started working on bug 105885).  The patch in that bug is
a very modified derivative of the extension's code - porting it to Firefox once
it's done should not be difficult.

Comment 46

[Worcester12345]

(In reply to comment #45)
> The code in the MiniT extension isn't very good (or wasn't - apparently it's
> been rewritten since I started working on bug 105885).  The patch in that bug is
> a very modified derivative of the extension's code - porting it to Firefox once
> it's done should not be difficult.

So, does a patch exist based on this "new" code? Just curious.

Comment 47

[Mike Connor [:mconnor]]

Attachment: work in progress

work in progress patch based on miniT, still needs a bit/lot more cleanup.

Dorando, care to take a look? I haven't done anything about flowing tabs, in
theory that shouldn't crash anyways, but the extension should be able to roll
in your compat fix once this is core functionality.

This also is untested on rtl locales.

Comment 48

[Mike Connor [:mconnor]]

Attachment: tab drag indicator (goes to toolkit/themes/winstripe/global/tabDragDrop/tabDragIndicator.png

Asa did this a while back, works rather nicely. :)

Comment 49

[Dorando]

> Dorando, care to take a look?
Sure.

> I haven't done anything about flowing tabs, in
> theory that shouldn't crash anyways, but the extension should be able to roll
> in your compat fix once this is core functionality.
The crash did only happen with the old (ordinal using) approach.

>+function initTabDragDrop() {
>+  if (!gBrowser)
>+    gBrowser = document.getElementById("content");
It might be better to pass the browser to initTabDragDrop as a parameter

>+    transferData.data.addDataForFlavour("text/x-minit-tab", event.target._tPos);
...
>+    flavours.appendFlavour("text/x-minit-tab");
text/x-moz-tab

>+    var newIndex;
>+
>+    if(event.clientX < gBrowser.mTabs[0].boxObject.x) newIndex = 0;
>+    else if(event.target.localName != "tab") newIndex = gBrowser.mTabs.length;
>+    else newIndex = Number(event.clientX < event.target.boxObject.x +
event.target.boxObject.width / 2 ? event.target._tPos : event.target._tPos-0+1);
var newIndex = this.getNewIndex(event);

>+            var uniqueId = "panel"+(new Date()).getTime()+position;
...
>+            var uniqueId = "panel"+(new Date()).getTime()+i;
|Date.now()| might be faster than |(new Date()).getTime()| at least I planned to
use it for next release

>+            //if (this.mPrefs.getBoolPref("tablib.tabs_open_relative"))
this.moveTabTo(t,this.mCurrentTab._tPos+1);
Shh

>+    for(var i = event.target.localName == "tab" ? event.target._tPos : 0; i <
gBrowser.mTabs.length; i++)
>+      if(event.clientX < gBrowser.mTabs[i].boxObject.x +
gBrowser.mTabs[i].boxObject.width / 2)
>+        return i;

    if (window.getComputedStyle(gBrowser.parentNode, null).direction == "ltr") {
      for(var i = event.target.localName == "tab" ? event.target._tPos : 0; i <
gBrowser.mTabs.length; i++)
        if(event.clientX < gBrowser.mTabs[i].boxObject.x +
gBrowser.mTabs[i].boxObject.width / 2) return i;
    } else {
      for(var i = event.target.localName == "tab" ? event.target._tPos : 0; i <
gBrowser.mTabs.length; i++)
        if(event.clientX > gBrowser.mTabs[i].boxObject.x +
gBrowser.mTabs[i].boxObject.width / 2) return i;
    }

The indicator code also needs to be modified (I was only able to get it
partially working). Perhaps someone can come up with something better

>     <vbox id="appcontent" flex="1">
>+      <hbox id="tab-drop-indicator-bar">
>+        <hbox id="tab-drop-indicator"/>
>+      </hbox>
>       <tabbrowser id="content" disablehistory="true"
For users who http://kb.mozillazine.org/Move_the_tabbar_(Firefox) to the bottom
it might be better to move this before .mTabBox.firstChild (either really or
script wise)

>+  gBrowser.mPanelContainer.__defineSetter__("selectedIndex",
gBrowser.mPanelContainer.__lookupSetter__("selectedIndex") );
>+  gBrowser.mPanelContainer.__defineGetter__("selectedIndex", function(){
return gBrowser.mTabContainer.selectedIndex; });
Or change all |.mPanelContainer.selectedIndex| to |.mTabContainer.selectedIndex|
in tabbrowser.xml

>+      <property name="browsers" readonly="true">
Some of http://lxr.mozilla.org/mozilla/search?string=.browsers in /browser/
should be rewritten as this can get slow

>+          for(var i = 0; i < this.mTabContainer.childNodes.length; i++)
At construction time there should only be one here

>+          if (this.mTabContainer.childNodes.length > 0)
>+            this.mCurrentTab.selected = true;
Hmm, why had I used |> 0| here? Anyway, this should not be needed.

Comment 50

[Mike Connor [:mconnor]]

Attachment: getting there

feedback is good, I'm not sure if we want to move everything into tabbrowser,
or leave it like this.	I do like the ability to selectively enable this via
the init function, without it we get old-style drag behaviour.

Comment 51

[Mike Connor [:mconnor]]

Attachment: patch

I'll add placeholder bits for pinstripe since Kevin's away, he may or may not
want to do something different for OS X, in the meantime I want to get this in
for 1.1a

Comment 52

[Ben Goodger (use ben at mozilla dot org for email)]

Wait, why is there any code independent of <tabbrowser> at all? This
functionality should be available to all tabbrowsers without having to have the
embedding XUL file hook anything up...

Comment 53

[Mike Connor [:mconnor]]

Attachment: all in tabbrowser

Ben and I talked about this, anyone who doesn't want this can just deal, if we
do get requests, we can add an attr to disable this, but I don't think that's
needed anymore.

Comment 54

[Dorando]

> The indicator code also needs to be modified

rtl portion:

 if (newIndex == gBrowser.mTabs.length) {
   ind.style.marginRight = gBrowser.boxObject.width + gBrowser.boxObject.x -
                           gBrowser.mTabs[newIndex-1].boxObject.x + 'px';
  } else {
   ind.style.marginRight = gBrowser.boxObject.width + gBrowser.boxObject.x -
                           gBrowser.mTabs[newIndex].boxObject.x -
                           gBrowser.mTabs[newIndex].boxObject.width + 'px';
  }

>+        <xul:hbox id="tab-drop-indicator-bar">
>+          <xul:hbox id="tab-drop-indicator"/>

Might be better to change these to class and make tab-drop-indicator-bar
referenceable as mDragSomething

>+    <!--  <method name="getSupportedFlavours">
...
>+      </method> -->

Hmm

>       <method name="onDragOver">
...
>+            if (aDragSession.canDrop) {

&& aDragSession.sourceNode.parentNode == this.mTabContainer

Comment 55

[Mike Connor [:mconnor]]

(In reply to comment #54)
> > The indicator code also needs to be modified
> 
> rtl portion:

added, needs testing by someone who knows rtl bits


> >+    <!--  <method name="getSupportedFlavours">
> ...
> >+      </method> -->
> 
> Hmm

oops.

> >       <method name="onDragOver">
> ...
> >+            if (aDragSession.canDrop) {
> 
> && aDragSession.sourceNode.parentNode == this.mTabContainer

fixed.

new patch in a minute.

Comment 56

[Kevin Benton]

Mike - do you want to change this bug's status to assigned since you're working
on it?

Comment 57

[James [silentj]]

Mike, that last patch you made was against ver 1.77 of tabbrowser.xml, it has
been updated to ver 1.78 since and I had (obvious) trouble trying to patch my
source. thanks -J

Comment 58

[Mike Connor [:mconnor]]

Attachment: patch

Comment 59

[Mike Connor [:mconnor]]

I'm not sure why it wouldn't still apply, still works fine here, and the merge
worked fine too.  I already updated CVS and no changes to the diff other than
line numbers, so I won't add yet another patch here.

Comment 60

[Paul Archer]

(In reply to comment #36)
> since there are a million duplicates for this bug, i'm ex
> 
> eventhough portability might be an issue for this feature i'm asking for but i
> would like to see the drag and drop work across different open windows of
> firefox. this extends the tab organization capability that firefox is so popular
> for.
> 
> essentially i would like to drag a tab from one open window to another. the
> destination window could show this as new tab as it's rightmost tab. wether or
> not the source window continues to display the moved tab is a use case based
> decision upto the design team.  -rk


I'd like to see this feature as well. It would dovetail very nicely with the
current ability to drag a link/URL from a webpage to the tab bar to open the
link in a new window.

Comment 61

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #60)
> (In reply to comment #36)
> > essentially i would like to drag a tab from one open window to another
>  
> I'd like to see this feature as well. It would dovetail very nicely with the
> current ability to drag a link/URL from a webpage to the tab bar to open the
> link in a new window.

That can't presently be done, for many reasons.

Comment 62

[alanjstr]

> eventhough portability might be an issue for this feature i'm asking for but i
> would like to see the drag and drop work across different open windows of
> firefox. 

Please file a separate bug, dependent on this one.

Comment 63

[Peter van der Woude [:Peter6]]

(In reply to comment #62)
> > eventhough portability might be an issue for this feature i'm asking for but i
> > would like to see the drag and drop work across different open windows of
> > firefox. 
> 
> Please file a separate bug, dependent on this one.
-> bug 293029

Comment 64

[s.maister]

(In reply to comment #48)
> Created an attachment (id=181657) [edit]
> tab drag indicator (goes to
> toolkit/themes/winstripe/global/tabDragDrop/tabDragIndicator.png
> 
> Asa did this a while back, works rather nicely. :)

The tab drag indicator in the Tab Mix extension is more visible and just looks
better... It's just a black arrow superimposed onto the tabs so it doesn't
impinge on the either the bookmarks toolbar or the current page.

Comment 65

[Mike Connor [:mconnor]]

Attachment: same patch, with keyboard shortcuts

This adds the following keyboard shortcuts when the tab has focus.  (Note that
left/right will be flipped in RTL locales.  This should work with bidi just
fine, but please test this if you can!)

Ctrl-Left/Up - Move tab left
Ctrl-Right/Down - Move tab right
Ctrl-End - Move tab to the end
Ctrl-Home - Move tab to the beginning

Comment 66

[Bogdan Stroe]

(In reply to comment #65)
> This adds the following keyboard shortcuts when the tab has focus.  (Note that
> left/right will be flipped in RTL locales.  This should work with bidi just
> fine, but please test this if you can!)
> 
> Ctrl-Left/Up - Move tab left
> Ctrl-Right/Down - Move tab right
> Ctrl-End - Move tab to the end
> Ctrl-Home - Move tab to the beginning

Isn't Ctrl-End and Ctrl-Home supposed to move to the start/end of the displayed
page? Do you have distinct states tab is selected/content of the tab is
selected, or how does this work?

Comment 67

[Kevin Benton]

Comment on attachment 184618 [details]
same patch, with keyboard shortcuts

I noticed you did a -8 meaning that the diff would include 8 lines of code on
either side of the update.  This makes it very difficult for people who have
customizations to incorporate your code.  Unless the Bugzilla community
utilizes -8 as a standard, please consider using less context.	Also, the keys
you chose to use are already defined (ctrl-right goes one word to the right,
ctrl-left, one word to the left, ctrl-home top of the document, and ctrl-end
bottom of the document).  I'm thinking putting keystrokes into this patch will
make it more difficult to get landed.  You may want to pull that back out and
once this is landed, request another update, landing your keyboard shortcuts.

Comment 68

[Mike Connor [:mconnor]]

(In reply to comment #67)
> (From update of attachment 184618 [details] [edit])
> I noticed you did a -8 meaning that the diff would include 8 lines of code on
> either side of the update.  This makes it very difficult for people who have
> customizations to incorporate your code.  Unless the Bugzilla community
> utilizes -8 as a standard, please consider using less context.

Read the hacking docs, -u8 is a standard (which I actually helped define) and a
minimum in most cases.  In some cases using more is appropriate in order to
ensure that a patch is appropriately clear.  The point is to get good review,
not to provide easy patching for custom builds.

> Also, the keys
> you chose to use are already defined (ctrl-right goes one word to the right,
> ctrl-left, one word to the left, ctrl-home top of the document, and ctrl-end
> bottom of the document).  I'm thinking putting keystrokes into this patch will
> make it more difficult to get landed.  You may want to pull that back out and
> once this is landed, request another update, landing your keyboard shortcuts.

These shortcuts apply when the tab has context, as my comment indicated.  The
keyboard shortcuts are essential for accessibility reasons, or we're violating
section 508, which blocks us from being deployed in federal government
environments.  In any case, thanks for your attempts to be helpful, but I know
what I'm doing, and what'll get accepted.

Comment 69

[Worcester12345]

I know this bug isn't the best place to ask, but since tabbed interface is being
worked on, is it possible to roll in a couple other very simple pieces as well?
Those would be TabX, Duplicate Tab, and UndoCloseTab extensions' functions.
Thanks, and sorry to add to this one. If there is an open bug for these, I
haven't found it yet.

Comment 70

[Jeff Walden [:Waldo]]

(In reply to comment #69)
> I know this bug isn't the best place to ask

Rhetorically, then, why are you asking?  Do some searching, CC yourself to
existing bugs, and open new bugs if necessary.

> since tabbed interface is being worked on, is it possible to roll in a couple
> other very simple pieces as well? Those would be TabX, Duplicate Tab, and
> UndoCloseTab extensions' functions.

These probably aren't "simple" pieces, and they're functionally separate from
what's being done here.  (Of course, you knew this because you realized this
wasn't the right place to ask.)  Adding somewhat extensive and mostly unrelated
changes will just make reviewing the patch more difficult.  Once this is in,
tho, I'm sure people would be amenable to reviewing patches posted in new bugs.

Comment 71

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 184618 [details]
same patch, with keyboard shortcuts

This breaks Ctrl+[T|W|...] when a tab has focus.

Comment 72

[Mike Connor [:mconnor]]

Comment on attachment 184618 [details]
same patch, with keyboard shortcuts

ok, I broke a couple shortcuts here, and I need to fix tabbox's impl to match
this (and native tabs).

Comment 73

[Mike Connor [:mconnor]]

Attachment: unbreak ctrl-w, sync behaviour to tabbox fixes in 295721

Comment 74

[Asaf Romano (gone)]

Comment on attachment 184696 [details] [diff] [review]
unbreak ctrl-w, sync behaviour to tabbox fixes in 295721

>Index: toolkit/content/widgets/tabbrowser.xml
>===================================================================

>+      <method name="moveTabTo">
>+        <parameter name="aTab"/>
>+        <parameter name="aIndex"/>
>+        <body>
>+        <![CDATA[
>+          this.mTabFilters.splice(aIndex, 0, this.mTabFilters.splice(aTab._tPos, 1)[0]);
>+          this.mTabListeners.splice(aIndex, 0, this.mTabListeners.splice(aTab._tPos, 1)[0]);
>+
>+          aIndex = aIndex < aTab._tPos ? aIndex: aIndex+1;
>+          this.mCurrentTab.selected = false;
>+          this.mTabContainer.insertBefore(aTab, this.mTabContainer.childNodes[aIndex]);
>+          var i;
>+          for (i = 0; i < this.mTabContainer.childNodes.length; i++) {
>+            this.mTabContainer.childNodes[i]._tPos = i;
>+          }
>+          this.mCurrentTab.selected = true;
>+          return aTab;
>+        ]]>
>+        </body>
>+      </method>


This method should care about the "first-tab" and "last-tab" <tab> element
attributes which are used by both themes and some nsITheme implementors.

Comment 75

[Zibi Braniecki [:zbraniecki][:gandalf]]

We should disable tooltip onmousedown.

Comment 76

[Zibi Braniecki [:zbraniecki][:gandalf]]

It would be also nice to change visual behaviour from this arrow to updating an
order while moving so moved tab will be placed under the pointer (with some
alpha blend if possible)

Comment 77

[Mike Connor [:mconnor]]

(In reply to comment #76)
> It would be also nice to change visual behaviour from this arrow to updating an
> order while moving so moved tab will be placed under the pointer (with some
> alpha blend if possible)

No, this is visually confusing if you drag out of the tab bar, we didn't want to
go that way with this feature.

As for the tooltip bit, I'm not sure that's necessary or desirable.

Comment 78

[Brian Schack]

(In reply to comment #77)
> > It would be also nice to change visual behaviour from this arrow to updating an
> > order while moving so moved tab will be placed under the pointer (with some
> > alpha blend if possible)
> No, this is visually confusing if you drag out of the tab bar, we didn't want to
> go that way with this feature.
In Adium and Colloquy dragging a tab out of the tab bar causes the tab to turn into a new window. If 
you continue holding down the mouse button and drag it back into the tab bar, it turns into a tab 
again. This seems very elegant to me.

Comment 79

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to comment #77)
> No, this is visually confusing if you drag out of the tab bar, we didn't want to
> go that way with this feature.

At the moment, yes. But what we want to have is the ability to move tab between
windows, tabs, to create a window from tab and tab from a window, right?

The arrow is imho not a good choice because it doesn't fit our skin.
 
> As for the tooltip bit, I'm not sure that's necessary or desirable.

When I'm pressing mouse button and starting dragging the tab I don't want the
tooltip to appear in the place where my pointer was when I clicked mousedown.
I think it's a bug.

Comment 80

[Mike Connor [:mconnor]]

Except that dragging between/out of windows simply isn't feasible these days, so
the only thing we'd do then is cancel the drag, popping the tab back to its
original location.

And I don't get a tooltip where the mouse pointer is, and when I mouse down, it
doesn't show a tooltip.... and I think the arrow is very winstripe-like, but if
our art guys come up with a better indicator, great.  I'm not going to spend the
last month of feature-time tweaking this to no end.  I'm happy with the look and
feel, as is Ben, so I doubt we'll be making any significant changes to the UI part.

Comment 81

[Mike Connor [:mconnor]]

(In reply to comment #74)
> This method should care about the "first-tab" and "last-tab" <tab> element
> attributes which are used by both themes and some nsITheme implementors.

Yeah, well, they're already horribly broken, we'll fix after this goes in to
avoid making this patch any bigger.

Comment 82

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 184696 [details] [diff] [review]
unbreak ctrl-w, sync behaviour to tabbox fixes in 295721


r=vladimir

Would be nice to have feedback for the case of dragging a URL to the tab bar
(which works now.. you can drag a link to a tab or to the new tab area, but you
get no feedback while doing it), but that can come in a followup at some point.

Comment 83

[Mike Shaver (:shaver emeritus)]

Comment on attachment 184696 [details] [diff] [review]
unbreak ctrl-w, sync behaviour to tabbox fixes in 295721

a=shaver

Comment 84

[Mike Connor [:mconnor]]

landed, with placeholder code for pinstripe.  Note that this won't actually
break with other themes, the feedback will just be absent.

Please report issues as new bugs, this bug is done, I hope!

Comment 85

[:Gavin Sharp [email: [e-mail]]]

*** Bug 297961 has been marked as a duplicate of this bug. ***

Comment 86

[Wayne Woods]

Just an FYI Mac bug 298799 seems to stem from this.

Comment 87

[Tracy Walker [:tracy]]

Verified with Deer Park builds:
Windows 2005-07-01-06-trun
Mac 2005-07-01-07-trunk

Comment 88

[Benjamin Lippelt]

verified with Deer Park build:

Linux firefox2005-06-29-05-trunk

Works well, thanks to all.

Comment 89

[Zibi Braniecki [:zbraniecki][:gandalf]]

there is a minor issue with current implementation.

1) Click on one tab
2) Click on another (not active) tab and drag it a bit while mousedown
3) the tab is active but in drag&drop state after mouseup.

This behaviour is quite irritating. I can reproduce it easly on Linux - didn't
try other OSes. You can't reproduce it with clic'n'move on active tab - only on
not active one.

Comment 90

[Benjamin Lippelt]

Actual, the tab on which the user clicks becoms active always (seems to be a
MouseDown-event or so, seeing this on Linux and Windwows). I think it would be
more intuitive if the tabs could be dragged around without becoming active.

=> opening new bug 299921

Comment 91

[Michael Osipov]

This change will break switching thru tabs known from many apps with
Ctrl+Left/Right.
FF supports this thru TabSwitcher extensions.

I would rather prefer for this change Ctrl+Shift+Left/Right

I switch way more often tabs than rearranging them.

more than 50 % of all users (presubambly) will never use rearrange anyway.

Comment 92

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 302635 has been marked as a duplicate of this bug. ***

Comment 93

[Peter van der Woude [:Peter6]]

*** Bug 303397 has been marked as a duplicate of this bug. ***

Comment 94

[Hari Kumar G]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050907
Firefox/1.6a1

working in 1.4 builds but broken in latest trunk on win2k.  

Comment 95

[Wayne Woods]

The regression for drag and drop tab reordering has been filed as bug 307256.