Closed Bug 675451 Opened 13 years ago Closed 13 years ago

Allow users to return to the old tab drag behavior

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: laurencedurant1, Unassigned)

References

Details

Bug 455694 introduced tab drag animations, but at the cost of functionality. Various bugs and regressions were introduced alongside the feature which the UX team seem unusually stubborn about addressing. These usability breakages include working with multiple windows, Panorama, tab bookmarking, tab duplication and cancelling drags. Put simply; pretty tab animations are, in the grand scheme of things, inconsequential to me. So these breakages are simply that; regressions with no added benefit. If the regressions are too difficult or too time consuming to revert, could you instead allow us to choose the old method so that we can continue using the browser as we have done just without the animations? As a more general observation, I fail to see the appeal of reducing the depth and richness of drag and drop interactions. Given the ubiquitous nature of drag and drop in modern computing I would assume the opposite would be desirable.
Blocks: 455694
Status: UNCONFIRMED → NEW
Ever confirmed: true
When this is fixed, let tab animations be disabled by default. It takes a lot of CPU time with the present implementation.
Please could we get some clarification on what is going to become of these regressions? Is the plan to simply ignore the use cases brought up in the various follow-up bugs or will they be addressed at a later stage?
Oops, I had planned to add more to that comment. I basically wanted to state my frustration that the follow up bugs I'm referring to have had little to no recognition from the UX team, and have mostly been brushed aside frivolously. Whether this is the concern is unique to me, I don't know. But I don't think the attention they received is really appropriate and more consideration should be made to how people have used the browser in the past.
(In reply to sdrocking from comment #1) > When this is fixed, let tab animations be disabled by default. It takes a > lot of CPU time with the present implementation. What's the point of implementing them in the first place? You think users will jump into about:config to enable them? Yeah right.
This request is not going to happen. Feel free to file regression bugs if you find regressions that are not already filed. We don't intend to make this feature optional. If you'd like to pursue that, take it to add-on space.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
(In reply to Asa Dotzler [:asa] from comment #5) > This request is not going to happen. Feel free to file regression bugs if > you find regressions that are not already filed. We don't intend to make > this feature optional. If you'd like to pursue that, take it to add-on space. Given Firefox's history of allowing users to control and/or turn off new features and revert to old behavior, this decision seems somewhat inconsistent. Any chance of us users getting an explanation of the rationale behind this?
(In reply to solcroft from comment #6) > (In reply to Asa Dotzler [:asa] from comment #5) > > This request is not going to happen. Feel free to file regression bugs if > > you find regressions that are not already filed. We don't intend to make > > this feature optional. If you'd like to pursue that, take it to add-on space. > > Given Firefox's history of allowing users to control and/or turn off new > features and revert to old behavior, this decision seems somewhat > inconsistent. > > Any chance of us users getting an explanation of the rationale behind this? Carrying old features around when we've got new features which have replaced them is not free and if we've got a history of doing a lot of that in the past, we've got a history we need to move away from. It costs in terms of code complexity. It costs additional QA resources. It costs in terms of usability. It costs application size and even performance. We have a wonderful mechanism for non-standard features to be added to Firefox called extensions. You're going to have a lot more success trying to get extensions written to mimic old features than you are going to have trying to get Firefox to keep every flavor of every feature it's ever had available as an option.
(In reply to solcroft from comment #6) > Given Firefox's history of allowing users to control and/or turn off new > features and revert to old behavior, this decision seems somewhat > inconsistent. This feature can be disabled via userChrome.css. See: http://groups.google.com/group/mozilla.dev.apps.firefox/msg/86efd22617fe13d8?
Whiteboard: See comment 8 for solution
The above code doesn't appear to restore the lost functionality of the basics like drag tabs to bookmark, which I consider a huge loss in usability. Its gone from one simple movement, to five times as much work to add a bookmark to a chosen location. Is sacrificing a simple but powerful feature for the sake of a bit of something 'flashy' really what its come down to?
Well damn, you learn something new every day. *Gets off high horse* Much obliged!.
(In reply to Asa Dotzler [:asa] from comment #5) > This request is not going to happen. Feel free to file regression bugs if > you find regressions that are not already filed. We don't intend to make > this feature optional. If you'd like to pursue that, take it to add-on space. Okay, this is of course very disappointing, but why can't there be at least some leeway given? Particularly in regards to duplicating tabs, which is no longer possible with the stock browser. At the very least, can we get a proper explanation as to why you're quite happy to gut tab duplication, which has been available as long as I can remember? It just seems like such a fundamental thing to be able to do and surely trivial to implement. Many of the other annoying bugs this introduced look like they will be addressed with bug 674925, but even that seems uncertain as to whether it will go ahead.
Whiteboard: See comment 8 for solution
(In reply to Pavel Cvrcek (Mozilla.cz) [:JasnaPaka] from comment #8) > (In reply to solcroft from comment #6) > > Given Firefox's history of allowing users to control and/or turn off new > > features and revert to old behavior, this decision seems somewhat > > inconsistent. > > This feature can be disabled via userChrome.css. See: > http://groups.google.com/group/mozilla.dev.apps.firefox/msg/86efd22617fe13d8? I suppose that'll have to do as a wokaround. Thanks.
Bug 455694 was there in bugzilla for 3 years like many other UI features request. UX team just pick up one of those, "FIX" it, break many function, leave other teams and add-on developer to fix it, when people asking for disable for good reasons(like above), without further discussion then mark it RESOLVED WONT FIX, bravo. How can UX team do thing like that? And may I so bold to ask do UX team ever have a poll of users before makes these UI no-backway changes? Or just some artists have discussion... make decisions... Sorry for my impolite, qoute a paragraph in google group topic above: > The cost of providing this option is not free. There is additional code > complexity overhead, test coverage overhead, and developer mindshare > overhead (you have to be aware of more things that could break). > So have you ever consider about back it out, if add option disable make code complex? A UI animation, users gain nothing, and it not on FF8's roadmap. The function break is for real, just look what went wrong: (In reply to Lozzy from comment #0) >These usability breakages include working with multiple windows, >Panorama, tab bookmarking, tab duplication and cancelling drags. User in his right mind will make a quick decision which they rather prefer, an useless animation or normal behaivor they got used to
(In reply to dindog from comment #14) > User in his right mind will make a quick decision which they rather prefer, > an useless animation or normal behaivor they got used to That's a false dilemma. Users won't be forced to choose between tab dragging animations and broken functions, the latter are regressions that are going to get fixed. If you can't handle bugs, maybe you shouldn't be on the Nightly channel.
I just hope the fixes land before it's pushed over to Aurora...
Congratulations! One time more show us the firefox devs, they are completely feedback resistant. They give us a useless tab animation and kick the old drag & drop behavior to the trash. Hello???? Yes, Asa this new future cost all of them what you have wrote above...terms of code complexity, additional QA resources, applications size and the best is the argument with terms of usability. But this all was no arguments for the devs to implement this useless tab animation.
Problem using identibox to bookmark page?
Someone please make an add-on to disable tab animation. TIA Sorry for bugspam.
@Peter Henkel [:Terepin] You will not believe it, but Drag & Drop was not only necessary to bookmark pages. Yes it is true, there are extensions which work with this basic functionality. You need an example? Tabgroupsmanager.
(In reply to TheRave from comment #17) > Congratulations! One time more show us the firefox devs, they are completely > feedback resistant. > > They give us a useless tab animation and kick the old drag & drop behavior > to the trash. Hello???? Yes, Asa this new future cost all of them what you > have wrote above...terms of code complexity, additional QA resources, > applications size and the best is the argument with terms of usability. But > this all was no arguments for the devs to implement this useless tab > animation. They have also killed RSS instead of allowing to integrate it inside address bar (like they did with Reload/Stop buttons). I use QupZilla and Midori web browsers which are far better than the defunct fox. Sham on you, Mozilla. Some of us, including myself, have donated money to you in the past for good reasons. By the way, why did you stop the Ubiquity Mozilla project? Did big-money corporations have bribed you once again to neglect another good project? So long Mozilla, and thanks for all the fish - June 2012
@Khazar Why do you come here to whine more than two years later? The issues were fixed not much later actually...
You need to log in before you can comment on or make changes to this bug.