Open
Bug 420296
Opened 18 years ago
Updated 2 years ago
Holding the tabdrop indicator over a tab for a moment should open this tab to allow drag&drop of content from one tab to another tab" (Port Bug 248612).
Categories
(SeaMonkey :: Tabbed Browser, enhancement)
SeaMonkey
Tabbed Browser
Tracking
(Not tracked)
NEW
People
(Reporter: sgautherie, Assigned: philip.chee)
References
Details
(Whiteboard: [FF2SM])
Attachments
(1 file, 1 obsolete file)
4.23 KB,
patch
|
InvisibleSmiley
:
feedback-
|
Details | Diff | Splinter Review |
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre] (nightly) (W2Ksp4)
Works, per bug 248612.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
When hovering the target tab,
I get the (drag & drop) blue arrow centered above the tab,
but the tab does not "activate".
Reporter | ||
Comment 1•14 years ago
|
||
[Mozilla/5.0 (Windows NT 5.0; rv:2.2a1pre) Gecko/20110331 Firefox/4.2a1pre SeaMonkey/2.2a1pre]
Bug still there.
Assignee: general → nobody
Component: General → Tabbed Browser
QA Contact: general → tabbed-browser
Whiteboard: [FF2SM]
![]() |
Assignee | |
Updated•14 years ago
|
Assignee: nobody → philip.chee
OS: Windows 2000 → All
Hardware: x86 → All
Summary: Port "Bug 248612 – holding drag&drop pointer over a tab for a moment should open this tab to allow drag&drop of content from one tab to another tab" to SeaMonkey → Holding the tabdrop indicator over a tab for a moment should open this tab to allow drag&drop of content from one tab to another tab" (Port Bug 248612).
![]() |
Assignee | |
Comment 2•14 years ago
|
||
> + <field name="_dragOverDelay">1000</field>
Should be 350ms but I set it to 1s for testing this patch.
> + <field name="_supportedLinkDropTypes"><![CDATA[
> + <method name="_setEffectAllowedForDataTransfer">
Minimal port. I didn't port the bits for supporting tear off tabs. For one thing I don't have any way of testing that.
> + <parameter name="aEvent"/>
> + <body>
> + <![CDATA[
> + var dt = aEvent.dataTransfer;
I could have sworn that Jens had a patch somewhere to update tabbrowser to the latest and greatest DragDrop API.
> <method name="onDragExit">
> + if (aDragSession.sourceNode &&
> + aDragSession.sourceNode.parentNode == this.tabContainer &&
> + aDragSession.canDrop) {
This fixes the case where the tabdrop indicator isn't hidden if you focus another tab and drop some text into a text area. This isn't perfect. If you accidentally mouse too close to the edge of the tab on the way to content the tabdrop indicator ends up frozen in between two tabs. I don't know how to fix this.
Attachment #530638 -
Flags: review?(neil)
Attachment #530638 -
Flags: feedback?(jh)
![]() |
Assignee | |
Updated•14 years ago
|
Attachment #530638 -
Flags: feedback?(sgautherie.bz)
![]() |
Assignee | |
Comment 3•14 years ago
|
||
<ImperceptibleSmiley>
> RattyAway: OK with Default. With Modern, the drop indicator is hidden while hovering over another tab and comes back when leaving the tab area
> qualifies for f-, but I'll continue testing of course
In Modern:
.tabbrowser-strip {
padding-bottom: 3px;
So there is this 3px strip between the tabs and the content area. This seems to be causing my patch to fail but I don't know how to fix it.
Comment 4•14 years ago
|
||
Comment on attachment 530638 [details] [diff] [review]
Patch v1.0 Proposed fix.
This would surely be nice to have!
(In reply to comment #2)
> I could have sworn that Jens had a patch somewhere to update tabbrowser to
> the latest and greatest DragDrop API.
Nah, I had done some local tweaks to MailNews message d&d using the new API but got stuck due to missing back-end support. No bug filed for any of that, though.
(In reply to comment #3)
> So there is this 3px strip between the tabs and the content area. This seems
> to be causing my patch to fail but I don't know how to fix it.
Either way we need a solution or workaround for that, hence f- for the moment.
[I didn't look too closely at the patch so I cannot tell whether the issue there is with finding a correct node or a timing issue. The former might be fixed by setting class attributes on nodes, the latter might be fixed using an asnyc call (setTimeout).]
Attachment #530638 -
Flags: feedback?(jh) → feedback-
Reporter | ||
Updated•14 years ago
|
Attachment #530638 -
Flags: feedback?(sgautherie.bz)
Comment 5•14 years ago
|
||
(In reply to comment #2)
> If you accidentally mouse too close to the edge of the tab on the way
> to content the tabdrop indicator ends up frozen in between two tabs.
> I don't know how to fix this.
Seems to be a drag-n-drop bug; it should automatically generate an exit/leave on the previous drag element when you drag over a new element. But the code doesn't take frames into account; it only compares against other elements in the window. One workaround is to respond to dragover events on the tabpanels element and use that to hide the indicator.
Comment 6•14 years ago
|
||
Comment on attachment 530638 [details] [diff] [review]
Patch v1.0 Proposed fix.
>+ var effects = this._setEffectAllowedForDataTransfer(aEvent);
Why does it matter what you're dragging?
>+ if (effects == "link" && aEvent.target.localName == "tab") {
If we're considering dropping on a tab, we must be hovering it...
>+ if (!this._dragTime)
>+ this._dragTime = Date.now();
>+ if (Date.now() >= this._dragTime + this._dragOverDelay) {
So, does this really mean "moving around over a tab for at least (350) ms"?
>+ ib.collapsed = true;
Not really true, as the user might have just have slow reactions rather than wanting to switch tabs.
![]() |
Assignee | |
Updated•11 years ago
|
Attachment #530638 -
Flags: review?(neil)
Comment 7•11 years ago
|
||
Philip on irc: "it's stuck at the moment since it doesn't work with certain themes."
Updated•2 years ago
|
Attachment #9385732 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•