Open Bug 1226546 Opened 9 years ago Updated 2 months ago

[tracking] Support Tab Mix Plus as a webextension

Categories

(WebExtensions :: General, defect, P5)

Product:
WebExtensions
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: erikvvold, Unassigned)

References

(Depends on 11 open bugs, Blocks 5 open bugs)

Details

(Keywords: meta, Whiteboard: [awe:{dc572301-7619-498c-a57d-39143191b318}])

Kev Needham (http://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/) and Bill McCloskey (http://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/) have stated that Mozilla wants to support existing add-ons and not abandon support for existing popular add-ons. Tab Mix Plus has almost a million daily users, and obviously should not be abandoned, especially since the add-on sdk would have provided a means for this add-on to exist, before Kev made that impossible with the plan stated in http://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ It would be nice if someone above would describe how webextensions are going to support this add-on. I don't think saying it will "use the native.js idea" is good enough. This bug will need some real information.
Many of the tab mix plus APIs are supported in the new WebExtensions APIs. Some aren't and similar to bug 1232178 I'm not sure how useful this bug is. What would be really helpful is a list of APIs that we need to add to make this add-on usable in WebExtensions. Perhaps the add-on author would be able to help with that.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Reopening+adding whiteboard tag since this addon is under the "most widely adopted" section on http://arewewebextensionsyet.com/ and is not yet a web extension.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Whiteboard: [awe:{dc572301-7619-498c-a57d-39143191b318}]
status-firefox57: --- → ?
tracking-firefox57: --- → ?
I'm also using Firefox since the beginning (I changed from Netscape as firefox seems to be the future). With Tabmixplus Firefox got not only a better Tab System, but also a session management - which made it possible to restore all open tabs after a crash or a (program/computer) restart. Years later firefox also implemented an internal session management - and I thought I will use the internal one. But a lot of times after a new restart of firefox (after crash or new program restart) all the tabs and sessions were lost. Therefore I changed again to the session management of tabmixplus - till now. For me the session management in my work is existential because it stores not only the url but the real session (where on the page you where positioned and so on). I'm using it since more than 15 years often with 80+ tabs and it never (!) has disappointed me (it worked every time) Please provide a possibility that tabmixplus can exits further or implement the real working session management from tabmixplus into firefox - I think this should be possible... Thanks!
This bug is not actionable in its current state. If there are any specific APIs that are needed for TMP to be ported to use WebExtensions, they should be filed as individual bugs and added as dependencies to this bug.
status-firefox57: ? → ---
tracking-firefox57: ? → ---
Depends on: 1332447
Depends on: 1320585
Depends on: 1308059
Depends on: 1215064
Depends on: 1238314
Depends on: 1246706
Depends on: 1315558
Priority: -- → P5
I don't think there's an API that allows to open new tabs for history, bookmarks, address/search bar, which is one of the Tab Mix Plus features.
(In reply to jomo from comment #6) > I don't think there's an API that allows to open new tabs for history, > bookmarks, address/search bar, which is one of the Tab Mix Plus features. The ability to open new tabs from everywhere(history, bookmarks, address/search bar) should ba a native feature IMHO. There should be an option an about:config that reverses the roles or normal click/enter and CTRL + click/enter.
Depends on: 1393349
The Tab Focus feature is vital to me for accessibility reasons.
IMO, the tab focus on mouse hover should also be a native accessibility feature.
Depends on: 1393349
Could we also add "depends on" for 1335108? It was a feature removed from Firefox but achievable with TMP.
(In reply to Hlsg from comment #7) > (In reply to jomo from comment #6) > > I don't think there's an API that allows to open new tabs for history, > > bookmarks, address/search bar, which is one of the Tab Mix Plus features. > > The ability to open new tabs from everywhere(history, bookmarks, > address/search bar) should ba a native feature IMHO. There should be an > option an about:config that reverses the roles or normal click/enter and > CTRL + click/enter. The about:config key 'browser.search.openintab' does this for search already, but I haven't been able to find corresponding ones for bookmarks or the URL bar. I relied on this behavior heavily in my normal browsing habits, so having it missing is the most substantial grievance I have with 57.
(In reply to Gordon Dexter from comment #12) > The about:config key 'browser.search.openintab' does this for search > already, but I haven't been able to find corresponding ones for bookmarks or > the URL bar. I relied on this behavior heavily in my normal browsing habits, > so having it missing is the most substantial grievance I have with 57. For bookmarks, "browser.tabs.loadBookmarksInTabs". For the URL bar, bug 1394304 (that is, not possible yet unfortunately.)
Depends on: 1394304
No longer depends on: 1393349
(In reply to Gordon Dexter from comment #12) > (In reply to Hlsg from comment #7) > > (In reply to jomo from comment #6) > > > I don't think there's an API that allows to open new tabs for history, > > > bookmarks, address/search bar, which is one of the Tab Mix Plus features. > > > > The ability to open new tabs from everywhere(history, bookmarks, > > address/search bar) should ba a native feature IMHO. There should be an > > option an about:config that reverses the roles or normal click/enter and > > CTRL + click/enter. > > The about:config key 'browser.search.openintab' does this for search > already, but I haven't been able to find corresponding ones for bookmarks or > the URL bar. I relied on this behavior heavily in my normal browsing habits, > so having it missing is the most substantial grievance I have with 57. Aren't we allready able to open tabs from everywhere using the middle-mousebutton?
> Aren't we allready able to open tabs from everywhere using the > middle-mousebutton? I found these 3 settings that solved my problem for the moment: browser.bookmarks.openInTabClosesMenu ON A MENU, I CAN CTRL-CLICK A BOOKMARK AND THE MENU REMAINS OPEN browser.search.openintab browser.tabs.loadBookmarksInTabs This is really useful
(In reply to Christoph Gizewski from comment #15) > > (In reply to Hlsg from comment #7) > > The ability to open new tabs from everywhere (history, bookmarks, > > address/search bar) should be a native feature IMHO. > > Aren't we allready able to open tabs from everywhere using the > middle-mousebutton? Technically, yes, you could enter “mozilla.org” in the address bar, move your hand to the mouse, move your mouse cursor to the Go button, and middle-click. That might work if you opened, say, a single new page a day. That feature request, however, is about being able to open several new tabs in mere seconds. Without also having to remember to hold down Alt when pressing Enter. It is about being able to open new tabs without slowing down to *think* “careful now, I want to open a new tab”. We want new tabs *by default*, and only replace the previous page by conscious thought.
> That feature request, however, is about being able to open several new tabs in mere seconds. Without also having to remember to hold down Alt when pressing Enter. I didn't even know Ctrl+Enter opened the typed URL in a new tab. I've been using Ctrl+T to open a tab, then typing the URL. I don't think middle-clicking is too much of a hassle for opening links, since I have to click on them anyway. That said, a setting of "Open in new tab" as the default for the address bar as well as for clicked links would definitely be a handy thing to have.
(In reply to Yuri Khan from comment #17) > (In reply to Christoph Gizewski from comment #15) > > > (In reply to Hlsg from comment #7) > > > The ability to open new tabs from everywhere (history, bookmarks, > > > address/search bar) should be a native feature IMHO. > > > > Aren't we allready able to open tabs from everywhere using the > > middle-mousebutton? > > Technically, yes, you could enter “mozilla.org” in the address bar, move > your hand to the mouse, move your mouse cursor to the Go button, and > middle-click. That might work if you opened, say, a single new page a day. > > That feature request, however, is about being able to open several new tabs > in mere seconds. Without also having to remember to hold down Alt when > pressing Enter. > > It is about being able to open new tabs without slowing down to *think* > “careful now, I want to open a new tab”. We want new tabs *by default*, and > only replace the previous page by conscious thought. Nailed it!
The logics of browser.search.openintab option is reversed for me. Setting it to false actually opens a new tab from search, while if true it doesn't. And I second everything Yuri Khan says. This should be the default behavior, or at least configurable. I, for one, never use middle click for anything, as in Linux it's used for pasting text. Having to think whether I use it in terminal for one purpose or in FF for another purpose is too much of a hassle.
I have been using Tab Mix Plus since 2006 and its absence has been catastrophic to my productivity. It is not an exaggeration to say TMP was the reason that kept me from moving to the competition on several occasions. These are the features I miss a lot since the upgrade to Firefox 57: * Possibility to set the browser to open a new tab from addresses typed in the omnibar, by default; * Possibility to open a new tab, by default, upon clicking a link that points to another site; * Possibility to open a new tab, by default, upon clicking a bookmark, including those from the bookmarks bar; * Possibility to set which tab to focus once the current is closed; * Possibility to stylize to better highlight the current tab; and * Possibility to select a tab hovering the cursor, without necessarily clicking it.
> * Possibility to open a new tab, by default, upon clicking a bookmark, for this we have: browser.tabs.loadBookmarksInTabs
> * Possibility to set the browser to open a new tab from addresses typed in the omnibar, by default; > * Possibility to open a new tab, by default, upon clicking a link that points to another site; > * Possibility to open a new tab, by default, upon clicking a bookmark, including those from the bookmarks bar; > * Possibility to set which tab to focus once the current is closed; > * Possibility to stylize to better highlight the current tab; and > * Possibility to select a tab hovering the cursor, without necessarily clicking it. Most of those are possible with the webextension model or preferences as it stands. the only exceptions are the ominbar and tab cursor hovering.
Should we open a new bug for multi-row tab bar or reopen and reconsider bug 293593? Having a tab bar 6000px long and scrolling it through a 960px window just does not cut it.
(In reply to fiveNinePlusR from comment #23) > Most of those are possible with the webextension model or preferences as it > stands. the only exceptions are the ominbar and tab cursor hovering. Well, the tab cursor hovering is exactly *the* key feature :( But how can I go about the other ones besides the hovering? Thanks!
(In reply to Antunisio from comment #25) > (In reply to fiveNinePlusR from comment #23) > > > Most of those are possible with the webextension model or preferences as it > > stands. the only exceptions are the ominbar and tab cursor hovering. > > Well, the tab cursor hovering is exactly *the* key feature :( But how can I > go about the other ones besides the hovering? Thanks! I've just read all about:config entries containing the substring "tab" and I couldn't find what would be the other options above :(
>Antunisio > I've just read all about:config entries containing the substring "tab" and I > couldn't find what would be the other options above :( did you check these ones? browser.bookmarks.openInTabClosesMenu browser.search.openintab browser.tabs.loadBookmarksInTabs
A feature which was very helpful to my workflow which is now gone is "tab flipping": (left-)clicking on the active tab switches to the previously active tab for that window.
(In reply to crazymykl from comment #28) > (left-)clicking on the active tab switches to the previously > active tab for that window. Yes, this is one of the most essential features of TMP, in my opinion. Is there any way to make this work in 57+?
(In reply to fernando_fernald@bell.net from comment #27) > >Antunisio > > I've just read all about:config entries containing the substring "tab" and I > > couldn't find what would be the other options above :( > > did you check these ones? > > browser.bookmarks.openInTabClosesMenu > browser.search.openintab > browser.tabs.loadBookmarksInTabs Sorry, I was looking at this list here, which seems to be outdated: http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries Some of the entries you pointed are new to Firefox 57, like the first. But that isn't exactly any of those on my list :( The second, browser.bookmarks.openInTabClosesMenu, only works for the search bar, not the address bar. The third one was already mentioned above.
Depends on: 1344749
Please add Depends: bug 1416545 and/or bug 1397372, and help convincing the right people to reconsider the WONTFIX on them.
Depends on: Session_managers
No longer depends on: 1308059
Depends: bug 1422509, bug 1436738.
Depends on: 1422509
Depends on: 1436738
(In reply to Yuri Khan from comment #24) > Should we open a new bug for multi-row tab bar or reopen and reconsider > bug 293593 [sic]? Having a tab bar 6000px long and scrolling it through > a 960px window just does not cut it. Bug 292593 (note corrected number) asks for multi-row tabs in Firefox itself (see also bug 139272, which requests it in Seamonkey). I think it's probably better to open a new bug that asks for the *ability* to implement tab rows in the Webextensions API rather than asking tab rows to be implemented in Firefox directly. That new bug could then be listed as a blocker for this tracking bug.
(In reply to Adam Katz from comment #39) > I think it's > probably better to open a new bug that asks for the *ability* to implement > tab rows in the Webextensions API rather than asking tab rows to be > implemented in Firefox directly. That new bug could then be listed as a > blocker for this tracking bug. That’s probably covered by bug 1215064 + bug 1332447.
is anyone working on allowing user to decide what tab to focus after current is closed?
(In reply to larabe from comment #41) > is anyone working on allowing user to decide what tab to focus after current > is closed? See bug 1422509, which was marked as a dependent of this bug 8 days ago.
Depends on: 1442843
No longer depends on: 1436738
Depends on: 1452910
Depends on: 1459402
No longer depends on: 1422509
Depends on: tab-unloading
Product: Toolkit → WebExtensions
Depends on: 1467057
Can 1246706 please be re-opened. TMP has a number of features that rely on receiving mouse clicks on tabs, including: * Click current tab to switch focus to the previously-used tab * Click current tab with a modifier key held to lock, protect etc (stop the tab being closed, prevent navigation away etc)
Yep, I agree, those are unique features of TMP that need to come back.
Bulk move of bugs per http://bugzilla.mozilla.org/show_bug.cgi?id=1483958
Component: Untriaged → General
No longer depends on: 1344749
No longer depends on: 1394304
Depends on: 1455264
No longer depends on: 1238314
Depends on: 1410548
No longer blocks: webext
Hi everyone, this bug has a lot of off-topic and advocacy chatter. As a reminder, Bugzilla is an environment for tracking and implementation issues. Please see the etiquette guide for more details: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html Comments are now restricted to users with 'editbugs' permissions; if you're subscribed to this bug, you'll still see updates on blockers and dependencies.
Restrict Comments: true
Blocks: 1571368
Blocks: cuts-control
Blocks: cuts-addons
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.