Closed theres-waldo closed 5 years ago
I hope to migrate TST to WebExtensions, but there are many missing features yet. This is a list of strongly depending bugs:
SessionStore.setWindowValue
and SessionStore.setTabValue
I've had a request for SnapLinks v3 (a web extension version) to re-add compatibility with TST. Do you expect the new cross-plugin API to be radically different than the exiting XUL based addon?
That's sad, only one of those bugs has even been actioned, and even the one that has - looks like its low priority, with no updates aside from discussion on the bug.
As for, 1280347 - wouldn't that be better accomplished if Mozilla: 1) Allow Tabs on the Top|Bottom, and an alternate top-down listing so they can be displayed Left|Right. 2) Allow to negate default styling on tabs. 3) Allow any tab-related-addons to "listen" for changes: Tabs closing, opening, moving - so they can react. 4) Allow for New-Tab to be modified by listening addons, so it can be inserted into the correct position.
As proposed 1280347 seems like it would be a significant undertaking on Mozilla's behalf compared to the 4 points above. Is there anything missing in the 4 points that you addressed in 1280347 that would still not be possible?
Does the feature in Nightly to put tabs in a category have anything to do with being able to store extra-data in the tab object/session ?
@piroor You don't need bug 1280347 if bug 1332447 is fixed right ?
Mozilla has also added "Test Pilot", along with "Tab Center"
https://testpilot.firefox.com/experiments/tab-center
This would seem to be heading towards where Tree Style Tab can move forward to Firefox 57 as a Web Extension if a way is provided to store "Tab Specific data" within the session files. No?
How can we help?
@mimoo It is written, only Link can defeat Ganon!
For anyone who's looking for a WE replacement: https://addons.mozilla.org/en-US/firefox/addon/tree-tabs/
Tried that one a while back, but it's not the same, and last I checked there are some things missing from it being proper replacement.
Tabs were still on top, so you'd have tabs on top and on the side last I tried, and with TST I have my pinned bookmarks on the bottom. The first one was a WE limitation last I checked, though. The last one I am not sure of.
From developer comment on a review: "Hiding tab bar is unavailable from Web extensions for now. Please join conversation at bugzilla to convince Web Extensions team to give us this possibility, here: https://bugzilla.mozilla.org/show_bug.cgi?id=1332447"
Tabs were still on top, so you'd have tabs on top and on the side last I tried
You can add the following to userChrome.css to hide the top bar (tested in Fx 55).
#TabsToolbar {
visibility: collapse;
}
@TheSweetLily The API has been approved, it just needs someone to work on the proposal.
Sorry if this is a naive question, and we still have some time to go, but what else might be done to push this ahead? Relying on the main Mozilla devs to generously spend time fixing bugs that don't jetpack or make FF look more like chrome seems like wishful thinking to me.
I mean, how complex are the problems, and how many/which are likely to be fixed as part of the larger FF upgrade project? Can any of the knowledgeable folks here answer that in like, a sentence or two for those of us non-programmers anxiously tapping our toes?
If one of the bugs is looking unattended as the dreaded WE time approaches, what can we do? Are they (comparatively) simple enough that we could hire someone on fiverr to do some work? Or another programming equivalent of that kind of service?
Sorry to push things along here without really contributing, but TST has been the number one essential part of my FF/web browsing experience since its inception. Tree Tabs has been ported (or perhaps concurrently programmed) from Vivaldi, and has a lot of promise, but it would be a shame to abandon such a long-standing project as this.
@photonometric FYI: https://wiki.mozilla.org/WebExtensions#Additional_APIs & https://wiki.mozilla.org/WebExtensions/RoadMapFirefox57.
If some APIs can not come in Firefox 57, we can continue to develop in future versions, as well as got it and improve once it landed in Nightly. If some WebExtension APIs or requirements cannot be approved, we can try to find a better idea, or expect Mozilla to change their minds, or wait for a third party to make a patch / build for broader APIs.
@photonometric All the remaining APIs have been approved, they just need to be implemented by someone. If you're an extension dev, you can help out by making a WebExtensions experiment.
The main blocker is the API to hide the native tabbar, which is likely going to be implemented soon as Tab Center needs it (there's already a pretty advanced replacement out there btw: https://github.com/eoger/tabcenter-redux).
@YFdyh000 (love your avatar!!!) Thanks for that, good to know there are more options than I thought for "worst case scenario," so to speak...I've been making comments to that effect in the Tree Tabs thread in the Vivaldi forum, since several people there were stating that TST was abandoned and I felt the need to stick up for him/it/us ;)
Perhaps there should be some more obvious "we're not dead yet" statements (or indeed any mention of the impending WE problem) on the 3 or 4 documentation areas for this plugin, so me linking repeatedly to this issue isn't the only indicator users of other browsers have that the project is still alive ^^;;; I mean, Tree Tab began development because the general browser community, developers included, thought WE was going to kill this plugin....that indicates some lack of communication as to intention.
@ntim: no, as I made clear, I'm no kind of dev. But I've spent hours over the lifetime of this project trying to help figure out bugs and keep it "in service." Needless to say I feel helpless not being able to do anything, which is why I asked about would could be done to "pay" someone to fix a bug (or implement the needed APIs, as you say). Hopefully it won't be necessary, or if not completed in time for WE deadline, will be fixed somehow soon after.
@photonometric I know you're not a dev, but I'm mentioning it in case someone comes across the comment and wishes to contribute. One way you can help is asking developers you may know if they can help.
Latest 57 nightly broke the TST sidebar, but native tab bar hiding seems to work, so I currently have no tabs whatsoever :) I really hope things work out best for TST in the end, it's my favourite addon ever in a browser (and it's such a shame no other browsers have anything similar)
Is there a way to donate money to this project? It is an essential part of Firefox for me.
@mimoo - Yes. You can either go to the version update notification page -- http://tabmixplus.org/version_update2.htm -- which has prominent donate buttons, or to the Tab Mix Plus homepage -- http://tabmixplus.org -- which has a donate button in the top center. I myself made a donation yesterday for the very same reason as you... it's too essential for me to lose it.
EDIT sorry - As I noted below, I got my plugins intermixed as I'm watching both Tab Mix Plus and Tree Styel Tab's migration to Web Extensions. So this comment does not apply. Sorry about that :(
@Javaru but tab mix plus doesn't seem to support tree style tabs, which is the whole point of using this addon (at least not from anything I could find in their help docs)
Tab Mix Plus has nothing to do with this add-on as far as I know, so donating there won't help anything here.
@mimoo I agree, TST is also essential for me as well! Looking at #761 and the project README, the TST author is grateful for the idea, but doesn't want donations at this time.
D'oh - Sooooo sorry - I'm watching both Tab Mix Plus and Tree Style Tab's migration to Web Extensions and misread which one this was when I saw mimoo's comment in my e-mail inbox (as Tab Mix was fresh in my mind from having just made a donation to its conversion effort). In my defense, I had not yet had my morning caffeine. Sorry for the confusion.
Issues I hope to fix before the initial release of the WebExtensions version:
certainly
maybe
impossible?
intentionally dropped features
TST WebExtensions will work only on Firefox 57 or later, because there are many required APIs initially implemented at Fx57 (browser.sessions.setTabValue()
, browser.sessions.getTabValue()
, browser.sessions.setWindowValue()
, browser.sessions.getWindowValue()
, browser.tabs.Tab.openerTabId
). In other words, legacy version will live until Fx56. I have no plan to fix bugs on the combination TST legacy with Fx57.
@piroor is there a prebuilt webextensions build like the nightly that we can be using for the webextensions version, or is it not functional yet?
@BrianGilbert There is no nightly build yet. You need to make it yourself, sorry. Steps to build XPI on Linux (including Bash on Ubuntu on Windows 10) or macOS:
$ git clone --recursive https://github.com/piroor/treestyletab.git
$ cd treestyletab/webextensons/
$ make
required commands: git
, zip
and (maybe GNU) make
@piroor do I need to change an about:config flag for it to load in FF Nightly? it says it's not compatible with 57.0a1 when I try and install from file.
@BrianGilbert "57.0" to "57.0a1" in manifest.json
@yfdyh000 thanks, thats didn't work tho.. I managed to get it to install by setting the version to 56.0 instead.
One point to note. WebExtensions limits the version string to Chrome compatible format + beta strings. In Chrome, each version part must be "positive integer", and it is limited to 0 - 65535. The format of x.y.yyyymmdd like now will not be accepted.
see Error message for versions like 1.4.0-pre.0 · Issue #1439 · mozilla/addons-linter
@piroor
1323 Suppress to render tree items for in-progress operations like "duplicate tree across windows"
Not sure what you mean by this.
1333 Provide context menu on tabs and tree items
Make an HTML element that shows on the "contextmenu" event ? You can check Tab Center Redux's implementation: https://github.com/eoger/tabcenter-redux/blob/master/src/contextmenu.js
It's probably not as fancy as the native context menu, but it's definitively better than not having one.
1334 Support container tabs
See the contextualIdentities API
You can also use the cookieStoreId property on the Tab object: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/Tab
Example usage of this API: https://github.com/jonathanKingston/sea-containers
It's probably not as fancy as the native context menu, but it's definitively better than not having one.
As I told at https://bugzilla.mozilla.org/show_bug.cgi?id=1280347 I don't want to include any "context menu" implementation (not "context menu item"!) in my addon, because it introduces new hell - I'll have to struggle to synchronize my own menu to Firefox's tab context menu for new features, removed features, and so on. Moreover, it won't help us from incompatibility of multiple addons - some addon will adds context menu items for Firefox's tab context menu, but it will ignore TST's menu even if TST provides any API to insert custom context menu items from other addons.
I don't want to include any "context menu" implementation (not "context menu item"!) in my addon
I was just replying to the "Impossible?" part. It is possible to have a context menu.
Sorry, I meant that there is no specific WebExtensions API to provide "context menu for a tab, on sidebar" yet. I hope that such an API to be implemented before Fx57...
@piroor If you're waiting for bug 1280347, IMO, this is unlikely going to happen for 57, as comment 10 suggests. Another reason I don't think it's going to be implemented any time soon, is that the suggested API is quite different than the other WE APIs, which mean it will likely require more thinking before it can be done.
I would personally recommend implementing a small separate context menu module, that you can rip out easily when bug 1280347 comes out. A benefit of implementing your own context menu, is that you can have TST specific features in the context menu.
I've suggested an alternative approach that will probably require less thinking API-wise: https://bugzilla.mozilla.org/show_bug.cgi?id=1396031
Now a development build for WebExtensions version is available at http://piro.sakura.ne.jp/xul/xpi/nightly/ (treestyletab-we.xpi
)
@piroor thanks for the nightly WE build, it's uninstallable on FF Nightly because of the version constraints though.
Nightly build installs now.. thanks @piroor
I could install it, but when opening it spins on 100% CPU and in the side bar it just shows the dot jumping left and right. (I have a couple 100 tabs open, so not sure if it would eventually finish.)
Can I help to debug this somehow?
@mh2 Because this is quite in-progress project, sometimes you'll get completely broken build. If the problem still there on the latest build, turn the "Debug mode" checkbox ON at TST's configuration and see logs in the browser console (Ctrl-Shift-J). If you see some similar set of logs repeatedly, please open new issue and paste the log there. Thanks.
@nh2 if you checkout 8952edaf801055fcd0e8e5a85ceb2153e2138968 and built it, that will work..
@BrianGilbert Thanks, that worked. I've attached the built .xpi
for convenience of others who don't want to build from source (though it builds within a few seconds): treestyletab-we-git-8952eda.xpi.zip
Is it no possible to open bookmarks and Tree Style Tab together? I suppose the APIs don't allow it...
@nt1m
I see that you are quite familiar with WE APIs. Do you think there is any way to design an API that would be approved for auto-hiding and auto-showing the tab bar ?
It's a key TST feature IMHO. I like how it doesn't displace content either, unlike Firefox address bar in full screen.
@Okamoi Even if it becomes available, I think the feature should be provided separately from TST.
@okamoi Depends what you mean by tabbar, whether it means browser tabbar or the tab sidebar added by TST.
If it's the former: https://bugzilla.mozilla.org/show_bug.cgi?id=1332447 If it's the latter: https://bugzilla.mozilla.org/show_bug.cgi?id=1341126
@nt1m I meant the latter yeah, the same feature as legacy TST. When the mouse gets near the edge of the screen (does that count as a user action ?), the tab sidebar opens over content without displacing it, and it closes itself once the mouse leaves the area. The second bug you linked to does seem like it would allow that, can you confirm ? The mouse thing might not work though, it may have to be another type of user action like keypress or a button, or maybe a mouse gesture.
@Piroor Awww. Ok then, but can a third-party extension control a panel that TST made ? (I guess only if TST implements an API for it, not sure that's worth it) What about hide/show triggered by a keypress or a button or a gesture ? It's not "auto" anymore then. Just asking since I'm not sure whether your issue is with the auto part of "autohide" or the hide part.
Mozilla recently announced that starting in Firefox 57, Firefox will no longer support addons that are not WebExtensions.
Is it possible to convert Tree Style Tab to be a WebExtension, so it can continue working in Firefox 57 and beyond?