Allow rearranging of thumbnails in the all tabs panel

VERIFIED FIXED in Firefox 3.7a1

Status

()

enhancement
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: tdowner, Assigned: dao)

Tracking

(Blocks 1 bug)

Trunk
Firefox 3.7a1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
If you wish to drag and drop to rearrange the previews in the tab preview window, it should do so. Also, it should match the rearrangement by moving the tabs on the tab bar.

Updated

10 years ago
Duplicate of this bug: 485674

Updated

10 years ago
Blocks: 485674
(Reporter)

Updated

10 years ago
No longer blocks: 485674
(Reporter)

Updated

10 years ago
Depends on: 465076
(Assignee)

Updated

10 years ago
Blocks: 505404
(Assignee)

Updated

9 years ago
Summary: Allow rearranging of Thumbnails in Tab Preview → Allow rearranging of thumbnails in the all tabs panel
(Assignee)

Comment 2

9 years ago
Posted patch patch (obsolete) — Splinter Review
This was surprisingly trivial, thanks to the solid drag and drop API and due to the fact that browser-tabPreviews.js handled the TabMove event already.
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #421818 - Flags: review?(mconnor)

Comment 3

9 years ago
Oh, so then it is a duplicate. Wow, I thought you would never get to this! Thanks :)

Updated

9 years ago
Duplicate of this bug: 485674

Comment 5

9 years ago
Comment on attachment 421818 [details] [diff] [review]
patch

>+      <handler event="dragover"><![CDATA[
>+        if (event.dataTransfer.types.contains("application/x-moz-node"))

You may want to check the (tab.parentNode == gBrowser.tabContainer) condition here in the dragover listener as well.

 
>+      <handler event="drop"><![CDATA[
>+        let tab = event.dataTransfer.mozGetDataAt("application/x-moz-node", 0);
>+        if (tab && tab.parentNode == gBrowser.tabContainer) {
>+          let newIndex = Array.indexOf(gBrowser.tabContainer.childNodes, this._tab);
>+          gBrowser.moveTabTo(tab, newIndex);
>+        }
>+      ]]></handler>

Is there a gap between or at the ends of the preview buttons where the user might want to drop? The above would only support dropping right on another button, no?
(Assignee)

Comment 6

9 years ago
Posted patch patch v2Splinter Review
(In reply to comment #5)
> You may want to check the (tab.parentNode == gBrowser.tabContainer) condition
> here in the dragover listener as well.

Makes sense.

> Is there a gap between or at the ends of the preview buttons where the user
> might want to drop? The above would only support dropping right on another
> button, no?

There are no gaps between the previews. There can be space at the end; for instance, if there were 7 previews in 3 rows, there would be two empty slots. However, the previews' container doesn't have a visible border, so it would probably feel odd if the drop zone equaled the container.
Attachment #421818 - Attachment is obsolete: true
Attachment #422821 - Flags: review?(enndeakin)
Attachment #421818 - Flags: review?(mconnor)

Updated

9 years ago
Attachment #422821 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 7

9 years ago
http://hg.mozilla.org/mozilla-central/rev/97745a2b2de9
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
(Assignee)

Updated

9 years ago
Depends on: 541393

Updated

9 years ago
Depends on: 541415
(Reporter)

Comment 8

9 years ago
V Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100206 Minefield/3.7a2pre ID:20100206050229
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.