45411 - Drag, hover over tab should open tab

Status: RESOLVED WONTFIX

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[Blake Ross]

It would be nice if a tab opened if you hovered over it for a second while 
dragging something (very similar to how win32 will switch to another program if 
you drag something over its button in the taskbar and then hover for a 
second).  Not for this release, obviously.

Comment 1

[Peter Trudelle]

yup, accepting for future- thanks!

Comment 2

[Matthew T (active 1999-2002)]

The display should return to the original tab if the drag is not dropped, but
continues outside of the <tabcontrol> element -- just as an automatically-opened
folder window in the Finder closes if you drag outside it.

Comment 3

[Peter Trudelle]

sounds right. ->pink

Comment 4

[Mike Pinkerton (not reading bugmail)]

i think this would be up to the designer of the tab (or tree, or slider, or
whatever) to interpret the dragOver, spawn a timer, and switch tabs if
applicable. It's not necessarily in the realm of the drag system to do this, but
if you want _me_ to do it, I can. I just think this is better handled by the
owner of said widget.

who would that be? ben? hyatt?

Comment 5

[Daniel Wang]

shouldn't be a bug...

I'm using Moz 1.1a and when I drag and drop a link over an inactive link, the
respective tab window will come to the foreground and load it. The tab doesn't
activate when I just drag the pointer over it, but I think it's not a big deal.
The tab control's default mouse-event interpretation is good enough :)

Comment 6

[Mike Pinkerton (not reading bugmail)]

default owner

Comment 7

[Martijn Wargers (dead)]

I have added this to the list of events in tabbox.ml#tab:
chrome://global/content/bindings/tabbox.xml#tab

    <handler event="dragenter">
     <![CDATA[
		var now = new Date().getTime();
              this.loadTimer = now;
      ]]>
    </handler>
    <handler event="dragover">
     <![CDATA[
		var now = new Date().getTime();
    if (this.loadTimer && (now-350>this.loadTimer)) {
      this.loadTimer = null;
              this.parentNode.selectedItem = this;
};
      ]]>
    </handler>
   <handler event="dragexit">
     <![CDATA[
		this.loadTimer = null;
      ]]>
    </handler>

It works for me as far as I know.
I use the same pause as for the dragenter event in the bookmarks menu.
chrome://browser/content/bookmarks/bookmarksMenu.js
  springLoadedMenuDelay: 350, // milliseconds

Comment 8

[Martijn Wargers (dead)]

Attachment: A xpi file which installs the desired dragover behavior

For my own learning purposes, I've made a xpi file, which installs a binding
which extends the tab behavior with the desired drag over behavior.
Warning: use at your own risk!
This will overwrite your existing userChrome.css (if you use this).
Only tested it with recent Firebird builds (doesn't work -and worse your tabs
becomes invisible- in november builds since after that they changed the widgets
dir back to bindings dir).

Comment 9

[Christopher Hoess (gone)]

Attachment: Attached as patch

Patch containing the code inline in the comment.

Comment 10

[jag (Peter Annema)]

I don't think it's good to hardcode that 350 (milliseconds) in here. Don't we
have some way to get this value from the OS or some config file?

Comment 11

[[e-mail]]

Unfortunately nsILookAndFeel is not a public interface.

Btw, we can now use Date.now() instead of new Date().getTime()
(in fact I would use this.dragTime = Date.now() + 350)

Also you're missing a <field> for the time.

Comment 12

[Martijn Wargers (dead)]

Attachment: Possible patch, improved

Ok, I've made the changes and created a new patch of it.
I've never done this before, so it could be I've done something wrong with
cvs/diff etc.

Comment 13

[[e-mail]]

Comment on attachment 140154 [details] [diff] [review]
Possible patch, improved

While the discussion as to how or why this should be done rages, here are some
nits:

>       </handler>
>+    <handler event="dragenter">
Indentation mismatch.

>+      if (this.dragTime && (Date.now()>this.dragTime))
Should have spaces around > (as per &&)

>+      { this.dragTime = null;
While we have a choice of brace styles, this is not one of them. Please choose
between
if (...) {
  ...
}
and
if (...)
{
  ...
}

>+        this.parentNode.selectedItem = this;
>+      };
No ; after }

Comment 14

[Martijn Wargers (dead)]

Attachment: revised patch

Ok, fixed the indentations, white space and the rest.

Comment 15

[Rene Pronk]

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

Comment 16

[jag (Peter Annema)]

Comment on attachment 140161 [details] [diff] [review]
revised patch

sr=jag.

At some point we should really replace that 350 with something OS based /
defined though.

Comment 17

[Christopher Hoess (gone)]

Comment on attachment 140161 [details] [diff] [review]
revised patch

requesting r= from ben; if there's a better/more available candidate for
reviews, feel free to change it.

Comment 18

[Asa Dotzler [:asa]]

not going to block 1.7 for this feature request. adding danm and blaker as
possible reviewers

Comment 19

[Prognathous]

Since Blake Ross reported this bug, how about asking him to review the patch?

Prog.

Comment 20

[Martijn Wargers (dead)]

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

Comment 21

[Mike Connor [:mconnor]]

Comment on attachment 140161 [details] [diff] [review]
revised patch

Looks good.  The toolkit version of this patch has to be sure to act right with
the drag and drop reordering patch that landed last night.

Comment 22

[Martijn Wargers (dead)]

Ok, I just tested: the Firefox version of the patch has to be changed, to take
into account the fix for bug 179656. 
When dragging tabs to another spot, the dragovered tab shouldn't become selected.

Comment 23

[Prognathous]

The revised patch has r and sr. Is there any reason this bug is not fixed yet?

Prog.

Comment 24

[Martijn Wargers (dead)]

(In reply to comment #23)
> The revised patch has r and sr. Is there any reason this bug is not fixed yet?

See comment 22, when dragging tabs to another spot, the dragovered tab shouldn't become selected, at least, I think that would be a confusing behavior for the user.

Comment 25

[Martijn Wargers (dead)]

Oh wait, this is the Seamonkey bug, Seamonky doesn't have the onmousedown select tab behavior, so the patch is still relevant.

Comment 26

[Martijn Wargers (dead)]

Comment on attachment 140161 [details] [diff] [review]
revised patch

Sorry, comment 25 isn't right, the dragovered tab still shouldn't be selected when a tab is dragged.

Comment 28

[:Hb]

SM2 has this nice blue arrow (onmousedown?) over the drop target now. WONTFIX