Bug 179656 (MoveTabs)

Allow drag-and-drop reordering of tabs

VERIFIED FIXED in Firefox1.5

Status

()

Firefox
Tabbed Browser
P1
enhancement
VERIFIED FIXED
15 years ago
4 years ago

People

(Reporter: Ben Escoto, Assigned: mconnor)

Tracking

(Blocks: 1 bug)

unspecified
Firefox1.5
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking-aviary1.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 6 obsolete attachments)

(Reporter)

Description

15 years ago
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

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

-->WONTFIX
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX

Comment 2

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

Comment 3

15 years ago
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.
Status: RESOLVED → VERIFIED

Comment 4

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

Comment 5

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

Comment 6

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

Comment 7

14 years ago
"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).
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---

Updated

14 years ago
Blocks: 126299

Comment 8

14 years ago
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

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

Assignee: firefox → bugs
Status: UNCONFIRMED → NEW
Component: General → Tabbed Browser
Ever confirmed: true
OS: Linux → All
QA Contact: asa → firefox.tabbed-browser
Hardware: PC → All
Summary: Allow more drag and drop operations on tabs → Allow more drag and drop reorder of tabs

Comment 10

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

Comment 11

14 years ago
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
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

14 years ago
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

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

Updated

14 years ago
Summary: Allow more drag and drop reorder of tabs → Allow drag-and-drop reordering of tabs

Comment 15

14 years ago
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

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

Comment 17

14 years ago
*** Bug 261909 has been marked as a duplicate of this bug. ***
*** Bug 262075 has been marked as a duplicate of this bug. ***
*** Bug 263829 has been marked as a duplicate of this bug. ***

Comment 20

13 years ago
neat feature for 1.0
Flags: blocking-aviary1.0+

Comment 21

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

Comment 22

13 years ago
nominating
Flags: blocking-aviary1.0?
We're waaaay tooooo close to 1.0 final to even dream about taking a change like
this. blocking-aviary1.0-
Flags: blocking-aviary1.0? → blocking-aviary1.0-
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.
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...
*** Bug 266635 has been marked as a duplicate of this bug. ***

Comment 27

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

Comment 28

13 years ago
Isn't this a dupe of bug 105885 ?

Comment 29

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

That one is for Suite, this one is Firefox specific
*** Bug 273462 has been marked as a duplicate of this bug. ***

Comment 31

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

Comment 32

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

Comment 33

13 years ago
What about to target this for Firefox1.1 or maybe Firefox1.2?
*** Bug 276793 has been marked as a duplicate of this bug. ***
*** Bug 277961 has been marked as a duplicate of this bug. ***

Comment 36

13 years ago
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

13 years ago
(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

13 years ago
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.
*** Bug 280101 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary1.1?
*** Bug 282404 has been marked as a duplicate of this bug. ***

Comment 41

13 years ago
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

13 years ago
(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.
Alias: MoveTabs
*** Bug 284540 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking-aviary1.1+

Updated

13 years ago
Depends on: 105885

Comment 44

13 years ago
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...
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

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

Updated

13 years ago
Assignee: bugs → mconnor
Blocks: 290395
(Assignee)

Comment 47

13 years ago
Created attachment 181656 [details] [diff] [review]
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.
(Assignee)

Comment 48

13 years ago
Created attachment 181657 [details]
tab drag indicator (goes to toolkit/themes/winstripe/global/tabDragDrop/tabDragIndicator.png

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

Comment 49

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

Comment 50

13 years ago
Created attachment 181712 [details] [diff] [review]
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.
Attachment #181656 - Attachment is obsolete: true
(Assignee)

Comment 51

13 years ago
Created attachment 181791 [details] [diff] [review]
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
Attachment #181791 - Flags: review?(bugs)
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...
(Assignee)

Updated

13 years ago
Attachment #181791 - Attachment is obsolete: true
Attachment #181791 - Flags: review?(bugs)
(Assignee)

Comment 53

13 years ago
Created attachment 181930 [details] [diff] [review]
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.
Attachment #181930 - Flags: review?(bugs)

Comment 54

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

Comment 55

13 years ago
(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

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

Comment 57

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

Comment 58

13 years ago
Created attachment 181970 [details] [diff] [review]
patch
(Assignee)

Updated

13 years ago
Attachment #181712 - Attachment is obsolete: true
Attachment #181930 - Attachment is obsolete: true
Attachment #181970 - Flags: review?(bugs)
(Assignee)

Updated

13 years ago
Attachment #181930 - Flags: review?(bugs)
(Assignee)

Comment 59

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

Updated

13 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox1.1

Comment 60

13 years ago
(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.
(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

13 years ago
> 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.
Blocks: 293029
(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
No longer blocks: 293029

Updated

13 years ago
Blocks: 293029

Comment 64

13 years ago
(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.

Updated

13 years ago
Blocks: 163993

Updated

13 years ago
No longer blocks: 163993
(Assignee)

Comment 65

13 years ago
Created attachment 184618 [details]
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
Attachment #181970 - Attachment is obsolete: true
Attachment #184618 - Flags: review?(bugs)
(Assignee)

Updated

13 years ago
Attachment #181970 - Flags: review?(bugs)

Comment 66

13 years ago
(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

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

Comment 68

13 years ago
(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

13 years ago
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.
(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 on attachment 184618 [details]
same patch, with keyboard shortcuts

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

Comment 72

13 years ago
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).
Attachment #184618 - Attachment is patch: false
Attachment #184618 - Flags: review?(bugs)
(Assignee)

Comment 73

13 years ago
Created attachment 184696 [details] [diff] [review]
unbreak ctrl-w, sync behaviour to tabbox fixes in 295721
Attachment #184618 - Attachment is obsolete: true
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.
We should disable tooltip onmousedown.
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)
(Assignee)

Comment 77

13 years ago
(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

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

Comment 80

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

Comment 81

13 years ago
(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.

(Assignee)

Updated

13 years ago
Attachment #184696 - Flags: review?(vladimir)
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.
Attachment #184696 - Flags: review?(vladimir) → review+
(Assignee)

Updated

13 years ago
Attachment #184696 - Flags: approval-aviary1.1a2?
Comment on attachment 184696 [details] [diff] [review]
unbreak ctrl-w, sync behaviour to tabbox fixes in 295721

a=shaver
Attachment #184696 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
(Assignee)

Comment 84

13 years ago
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!
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Depends on: 297005
Blocks: 105885
No longer depends on: 105885
*** Bug 297961 has been marked as a duplicate of this bug. ***

Comment 86

13 years ago
Just an FYI Mac bug 298799 seems to stem from this.
Verified with Deer Park builds:
Windows 2005-07-01-06-trun
Mac 2005-07-01-07-trunk

Comment 88

13 years ago
verified with Deer Park build:

Linux firefox2005-06-29-05-trunk

Works well, thanks to all.
Status: RESOLVED → VERIFIED
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

13 years ago
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

13 years ago
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.
*** Bug 302635 has been marked as a duplicate of this bug. ***
*** Bug 303397 has been marked as a duplicate of this bug. ***

Comment 94

13 years ago
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

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

Updated

9 years ago
Depends on: 502574
Depends on: 586153
You need to log in before you can comment on or make changes to this bug.