Turn off tab animations
onlbk opened this issue · 21 comments
Tree Style Tab is great but you added tab animations that really ruins Tree Style Tab. It is a really bad idea to have a user interface target around. This isn't a videogame, keep things simple.
Please turn off tab animations
+1
i really appreciate your work, i couldnt live without your addon, but could you please turn off those animations or provide an option to do so??! the options make drag and drop impossible, especially when you want to make a tab a child of another tab. thanks.
Which animations are bothering you? Is it the tree growing shallower when auto-shrinking and deeper when auto-expanding?
I agree it's not necessary, there could be an option to enable/disable it. Personally I would be happy to keep the tree shallow at all times.
no im talking about the animation of the tabs when you drag other tabs around. for example, when you want to drag a tree into another tab/tree, trying to make it a child of that tab, the parent tab starts moving up and down, away from the tree your dragging, making it almost impossible to drop it properly. it didnt use to be like that, it mustve changed within the last couple of updates. just please include an option to disable it, if other people want the animations, so be it.
This! Please. Moving tabs around to organize them has become very unnerving since animations were introduced. I would highly appreciate an option to disable animations.
For what it's worth, they appear fine for me. (Firefox 21 under Ubuntu 32bit.)
You guys may want to report your version and OS, so the author can reproduce your frustration. :)
well im using the newest version 0.14.2013082301, firefox 23.0.1 on win7 x64. also, you have to have a tree with several tabs in it, including one or more child tabs. moving single tabs appears fine. btw, "browser.tabs.animate" doesnt do anything.
@wanabe
unfortunately that doesnt work. it doesnt seem to change the behaviour at all. btw, i tried boolean and string.
this "bug" is seriously p*****g me off more and more every day. i cant even switch back to an old version because the 0.14.2012081101 version doesnt work with firefox 23. i am seriously considering switching back to an older firefox, this is how much i need this addon to work. argh! why not make a simple option to disable animations? ironically, v0.14.2012081101 had an option like that, although it was grayed out in ff23. sigh..
The new pref works for me. Thanks a lot!!
I need to comment again just to express how happy I am with the option. Thank you so much! :D
the change is not (yet) in master but in the dragging-animation branch. i just cloned that and built the xpi. the preference was there from the beginning, i just toggled the value to false.
@zuckel
i dunno maybe im too stupid, i unpacked the xpi and added the pref in the treestyletab.js - but i couldnt find the base.js and tabbarDNDObserver.js didnt have the lines to remove. i tried with just the pref line in treestyletab.js but then the addon didnt work at all. could you please just send me your xpi? put it on mediafire or something. would be much appreciated.
Of course it would be better and safer if you just built the artifact yourself. I assume, however, that you are unfamiliar with how to do this for the moment. So I uploaded the xpi to my sugarsync:
https://www.sugarsync.com/pf/D1417624_133_662611818
The artifact should not be considered to be stable as it comes from a WIP branch of a project I do not develop. I will remove it from sugarsync in a couple days.
@zuckel
it worked! thank you so much! although its important to note that you need to turn "extensions.treestyletab.animation.drag.enabled" to false in t about:cache - otherwise it wont work.
i really hope he makes it a regular option to disable animations completely in the next version cause otherwise im not updating. btw you should leave this online for other people who might be looking for the same thing.
thanks again!
@sozey You're welcome.
I will keep the file up until the change finds its way into a master release or the maintainers ask me to remove it.
Bright day to everyone :D
Is the toggle going to be integrated to master anytime soon?
I'll never merge this change to the master. I commented the reason to the pull request in Japanese so I try to translate it to English.
Why I introduced such an animation effect?
Because it is introduced by Firefox itself. After the animation effect is activated on Firefox, I updated TST to follow it. However, it was unwelcome update for some people and I got many requests like "it is hard to operate tabs with drag-and-drop", "I want an option to disable animation effects during tabs are dragged." Actually, I can see two issues on the issue tracker:
- "Drag as Child" is difficult to perform with tab animation · Issue #399 · piroor/treestyletab
- Turn off tab animations · Issue #499 · piroor/treestyletab
The patch of the pull request adds a secret preference to do it. It is enough small and clear. If I added the option, I wrote just same patch.
But I disagree to merge the pull request, because I think that the approach of the patch is similar to a story: "Firefox's Gecko engine is too buggy and less compatibility to WebKit, so why don't you delete all codes of Gecko and introduce WebKit with Firefox-like UI?" In other words, it is very easy to add new option which is requested by people, however, I'm extremely reluctant to do it because it is opposed to my policy on Tree Style Tab project.
Basic premises and my policies.
Basically, this project depends on Mozilla Firefox project --which is very large and uncontrollable by me-- and it is unavoidable to be tossed up and down by the storm of changes in Firefox. Actually, on my another project, I had to rewrite the addon for new versions of Firefox again and again. I learned through the bitter experience that I should have some strict policies on my addon projects:
-
Don't re-implement a feature included in Firefox itself.
For example, Tab Mix Plus has its own session management mechanism, because TMP project is started before the session management feature is introduced by Firefox itself. If the TMP project was started after that, they project team didn't implement such a custom session manager. There is no merit to implement a custom feature which conflicts to Firefox's.To reduce maintenance cost, and to keep better compatibility with other addons which are developed based on Firefox's APIs, I think I should update and re-construct my addons for new APIs introduced by Firefox. It is better than I struggle to keep old custom implementations against Firefox's changes.
-
However, sometimes I decide to keep my custom implementations, when it is hard to rewrite codes for Firefox's new API for me.
For example, TST uses a library "JSDeferred" to process asynchronous operations easily. On the other side, lately Firefox uses Promise and Task for the same purpose. I know I should rewrite TST based on them instead of JSDeferred, but I still don't do it because: 1) TST is strongly designed based on JSDeferred. 2) Promise/Task are not available on the current ESR (Firefox 17).
(In other words, I'll merge pull requests to do such a reconstruction, if there is no disadvantage about compatibility with other addons.) -
When the API of Firefox's library is too untrustworthy for me, I decide to use my custom library based on very low stable APIs.
For example, Firefox has a system named "preference" which can save/restore users' configurations. Because it is not developer-friendly (ex. there are three different types -- boolean, integer, and string--, and hard to observe changed configurations dynamically), Firefox provides some libraries like FUEL. But, such libraries are untrustworthy and risky for me because Firefox team sometimes changes those APIs despite they promised those APIs are developer-friendly --obviously they should be stable and safe--. I don't want to spend time to update my codes for such unstable APIs, so I actually use my custom library modules/lib/prefs.js which is based only on very stable low APIs. It is one of reasons why I don't update my codes for Promise/Task yet.
Anyway, I think that FUEL APIs are untrustworthy because Firefox team created FUEL just for third party add-on developers, not themselves. Because Promise/Task are used everywhere in Firefox, Firefox team will keep them stable for themselves.
-
-
Don't depend on deprecated features.
For example, "E4X" became obsolete on lately Firefox. TST used E4X in some cases, so I had to decide that I keep E4X for TST or I give up. Some projects (not mine) decided to re-implement E4X by themselves, but I decided to give up and rewrite codes without E4X. -
Don't include features not related to the main concept.
The basic concept is: what I want to use, one feature per one addon, and, as minimum as possible.In my old blog entry (note: written in Japanese), I told that: features which I never use or unrelated to the main concept may satisfy users in the short term, but it will shorten life of the project in the long term. Basically I develop and publish my addons on GitHub because I need it and I want to keep it available for me. So I don't want to introduce changes which can disrupt the concept.
-
Provide highly compatible, natural look-and-feel for Firefox's built-in features and other addons.
For example, Firefox has a feature "auto hide toolbox" for the fullscreen mode started by F11 key. And, TST also provides "auto hide tab bar" feature. Yes, it is not related to "tree" feature. But if TST doesn't have the feature, you'll see unexpected vertical tab bar in the fullscreen mode. You press F11, you expect that the web page becomes fullscreened, then the vertical tab bar should not appear on the scene.This is the main reason why I took much time to update TST to support drag-and-drop animation effects. Before the animation effect is introduced to Firefox, I respected behaviors of drag-and-drop around layers and objects on Adobe Illustrator. This behavior is still available when you drag a link to the tab bar.
Reasons why the pull request is unacceptable for me.
Based on the above policies, I disagree to merge this pull request to TST's master, because:
- Firefox has no option to disable animation effect of dragging tabs.
- There are different and large codes for both cases: with and without animation.
- However, animation-less operations in rare cases seem to be inhospitable (for me), contrastively basic operations with animation are developed actively.
- So I forecast that codes for animation-less operations can be removed from future versions of Firefox.
It is risky that I develop TST strongly based on such a disappearing implementation.
- Because there is no option to enable/disable animation effects, I think that Firefox team basically designs Firefox to do drag-and-drop operations with animations. Then, I should keep TST along the design of Firefox itself.
-
I believe that animation effects in GUI often provide better user experiences. I'm affirmative about such a policy of Firefox project.
-
Actually disabling animation effects by userChrome.css or other ways sometimes break Firefox itself.
For example, the internal operation to finalize closed tabs uses "TransitionEnd" DOM event to trigger itself, but it didn't work correctly because the event was never fired if the animation effect was disabled by userChrome.css. (I don't know the bug is already fixed or not.)I don't think my addon should be specially hospitable for people who live without animation effects, because Firefox itself disfavors them.
-
- I disagree to add new option to disable animation effects, for a request like "it is hard to operate tabs with animation effects." Instead, I think I should improve usability of tab operations with animation effects, to reduce frustrations around such operations.
- If you don't have to operate tabs manually, you won't suffer from animations. If you have to operate tree of tabs manually to put them as you want, then TST should build tree of tabs automatically more intelligently to set you free from stressful manual operations.
- If it is hard for you to drop the tab to the favorite position with animation effects, then TST should make it easy, instead of disabling animation effects.
- Currently I have no plan to use Firefox without animation effects. I don't want to maintain codes for a feature I never use.
- Of course, disabling animation effects is useful for some people who suffer from visual transitions, about accessibility.
However, remember, Firefox itself is not providing ability to disable animations, for such people. And, this addon is "Tree Style Tab." I think TST should not include custom accessibility features which is missing on Firefox itself --it should be done by Firefox project--.- If you seriously suffer from the problem, you should file a bug for the issue, induce developers to implement ability to disable animation effects. Or, you should create a new addon which is based on a simple concept: disabling animation effects. (Note, I never develop such an addon because I never use it!) The user script zzzz-removeTabMoveAnimation.uc.js for userChrome.js seems to be written for the purpose.
The conclusion: fork this project freely.
This is just my personal, current opinion. Of course I don't think this is the final truth of the topic. If you have information which can solve my worrying, or if you explain compelling reasons that I should do it, then I possibly merge such a change.
Otherwise, I'm sorry but I never merge such pull requests to my master repository. Then please fork this project, extend, maintain, and release it for people who have same distress - it is my stance on this project. To keep my codes forkable -- this is one of reasons why I distribute all codes of TST under OSS licenses.
Hi @piroor,
thanks for the in-depth reply. Much appreciated. I hope you do not feel pushed by my comment. It was just a factual question.
I don't know much about your codebase or about how your plugin works internally and how it integrates with firefox. From my experience of writing smaller plugins and user scripts I was assuming that it was mostly stand-alone and only using basic functionality of firefox. From your post I understand that TST is a lot more complex than I thought. In this case I understand completely that it is vital to keep a codebase small and focused. You should not include any features that you do not use yourself. They will only break and slow you down. It's also important to use stable and basic interfaces that allow you to base your own framework upon, no question. All in all, you know what is best for your TST.
As you mentioned that it might be possible to make TST smarter in the sense that I will not need to move tabs anymore, I will give you insight into how I use TST at work. There are a few tabs that are pinned, like time-booking and the daily canteen plan. Apart from that I use static named tabs (e.g. title = to read) to categorize my tabs. There will be a tree of JIRA tickets that I monitor, a tree of tickets I need to finish today, a tree of articles I plan to read up on when I find the time. Trees can get as deep as ~5 levels and up to ~10 tabs. In this way TST organizes my whole work every day, and it is a lot more efficient than other means. But I will end up moving a lot of tabs from one category to the other, and it gets frustrating quickly with the animations. This was just for your information.
I will have a look into where the animations actually come from and also look into alice0775's script. Maybe I can write my own little user script to make the behaviour better fit my working needs.
Thanks again and thank you even more for TST.
But due to tabs’ animation it's impossible to include one tab (or tab-tree) into other! I try to drag one tab to other, but see only animation of dragging tab onto other and returning it back. Or swapping these tabs. I try hard dozens of times, but that is not work!
I close this for triage.