Treestyletab: Cannot drag and drop a tab to the browser's bookmark toolbar anymore

[C4rter]

Short description

I'm unable to drag a tab from the TST to anywhere else in the browser. A black "not allowed" kind of sign blocks any interaction with the browser except inside the TST area.
Until recently, I could drag and drop a tab from TST to my bookmarks toolbar. That's not working anymore.

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. Open website.
4. Try dragging the tab onto the bookmark toolbar.
5. A symbol shows and blocks dropping the tab on the bookmarks toolbar.

Expected result

Dragging the tab to the toolbar and dropping it there should create a bookmark.

Actual result

Unable to drop the tab over over the bookmark toolbar.

Environment

• Platform (OS): Windows 7
• Version of Firefox: 62.0
• Version (or revision) of Tree Style Tab: 2.5.4

[C4rter]

Alright I found it in the Debug section in the settings:
Activating "AllowBookmarkCreationFromDraggedTree" fixed it.

I'm not sure why this is hidden inside the debug section but I'm glad it was somewhere.

[cameel]

I've just noticed this behavior too and came here to report it.

Looks like it's intentional, introduced in 59811e8c18a09b38866db6ea6f5834ed544cd401:

Allow to tear off dragged ttree from window by default.
Shift-drag allows to create links or bookmarks from dragged tree.
This commit also introduces a new configuration to invert behaviors for regular drag and shift-drag.

So now we can add bookmarks only while holding Shift (or by turning on this debug option).

Honestly, I liked the old default behavior more. It's already too easy to tear off a tab accidentally by dropping it not in the exact right spot or by going a pixel outside the bookmark menu and having it close on you suddenly. Making it even easier is not what I need. Fortunately there's this setting but it really shoudn't be hidden in the Debug menu given it was the official default behavior just a version ago.

Why not keep the old behavior as default and add an option for switching to the new one?

[piroor]

Why not keep the old behavior as default and add an option for switching to the new one?

Because the old behavior depended on a Gecko specific API DataTransfer.mozSetDataAt. It is now deprecated and unavailable on Firefox 63 and later. You still can use the API by a secret preference, but its availability is not guaranteed in future versions of Firefox.

[cameel]

OK. Thanks for the insight. It makes sense in that case.

Does this mean that creating bookmarks with drag an drop as a whole requires this deprecated API and that Shift + drop will stop working too when they remove the API?

[piroor]

Actually the old behavior was built on two technologies: the deprecated "mozSetDataAt" and an internal data type "text/x-moz-place". When URLs are transferred with the data type, Firefox allows to create bookmarks but disallows to create shortcuts on the desktop. However, in this case we need to set each URL via the deprecated "mozSetDataAt" method. Without the method we cannot transfer multiple data with the type. (The public "setData" method allows to transfer just one URL as the type "text/x-moz-place".)

On the other hand, the current version transfers dragged tabs as two types "application/x-treestyletab-tree" and "text/x-moz-url". (Both these types allow to transfer multiple URLs with the "setData" method.)
"application/x-treestyletab-tree" is TST's internal type, it is impossible to be dropped to both the desktop and bookmarks. "text/x-moz-url" is droppable on both the desktop and bookmarks. To allow to detach the tab by dragging, we need to disallow dropping to the desktop. So, when I want to allow detaching of tabs by dragging, TST doesn't set "text/x-moz-url" data type and it also disallows dropping to bookmarks. When I want to allow dropping to bookmarks, TST sets "text/x-moz-url" data type and it also allows to drop tabs to the desktop (to create shortcuts). Those behaviors are sadly exclusive.

[cameel]

I see. So with this new method you had a choice to either use text/x-moz-url as the default (which breaks tearing off when dropping on desktop) or to use application/x-treestyletab-tree as the default default (which breaks adding bookmarks).

At least now I know that it's just a necessary trade-off between two features rather than a random UI change. I'd personally have preferred to break tearing off but that's simply because I'm rarely ever using that feature. People who use it more would likely disagree.

Thanks for taking your time to explain it. And for making this great extension :)

By the way, I see that the reason they're deprecating mozSetDataAt() is primarily because they think no one is using it:

• Non-standard DataTransfer APIs have been deprecated

Given that Telemetry proves no public usage, these APIs will be completely removed in the near future.

• Consider removing gecko-only DataTransfer APIs
  I was looking at these counters with Ehsan earlier today, and we saw basically no usage of the main problematic APIs (mozClearDataAt, mozSetDataAt, mozGetDataAt, mozTypesAt, and mozItemCount).

It's probably too late for them to back off from this change now but I wonder if they would have reconsidered if they knew that Tree Style Tab does rely on it.

On the other hand, the current version transfers dragged tabs as two types "application/x-treestyletab-tree" and "text/x-moz-url". (Both these types allow to transfer multiple URLs with the "setData" method.)

I just tried it and with Shift pressed it adds only one bookmark. Is it a bug?

I can add multiple tabs as bookmarks only when I have allowBookmarkCreationFromDraggedTree enabled.

[piroor]

I just tried it and with Shift pressed it adds only one bookmark. Is it a bug?

Oh... it is a bug, not a desired result. I forgot to block selection by Shift-click. You couldn't drag whole tree because just one tab was selected by Shift-click before you start dragging. I must fix this problem in the next release.

Edit: I misunderstood my past work. TST was designed to drag just one tab without descendants when the drag action is started with Shift key. So I need to redesign drag action to keep four different results: dragging one tab for a bookmark, dragging one tab for tearing off, dragging tree for bookmarks, and dragging tree for tearing off.

[piroor]

So I need to redesign drag action to keep four different results: dragging one tab for a bookmark, dragging one tab for tearing off, dragging tree for bookmarks, and dragging tree for tearing off.

Now I'm planning to implement a new UI for these operations. The idea is:

• A small "tab" will appear at the edge of the mouseover tab.
• When the small "tab" get mouseover state, it will be expanded automatically and there are some draggable handles (with icons?) for different operations:
  
  
  
  1. dragging for tearing off the whole tree.
  
  
  2. dragging for bookmarking the whole tree.
  
  
  3. dragging for tearing off just one tab.
  
  
  4. dragging for bookmarking just one tab.
  
  

I think such an visual UI will help people who don't know such secret actions with modifier keys.

[piroor]

The tab drag handle is now available on the development build.
https://piro.sakura.ne.jp/xul/xpi/nightly/treestyletab-we.xpi

By pointing on edge of each tab, small palette will appear near the cursor.

[C4rter]

It stopped working for me in the official version and the debug option is gone.
Shift+Drag still works.

Will this new palette replace the old Drag+Drop feature in the release now or why was it removed?

[piroor]

On the latest release version, you can change configs at a new section "Drag and Drop" in the options page.

[C4rter]

With the latest version this stopped working for me. I'm unable to drag an drop the tab to the bookmarks.

[piroor]

By default you need to shift-drag TST's tab to drop bookmarks. Did you try that?

[C4rter]

It started working again today, with and without shift. Don't know what that was yesterday. Sorry for the inconvenience.