Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
Chrome Chromium GUI Google

No Tab Relocation Coming For Chrome 574

Posted by Unknown Lamer
from the trust-us-we're-designers dept.
shaitand writes about Google disagreeing with the desire of Chrome users to put tabs under (rather than above) the location bar: "This issue has had overwhelming feedback from users with no notable dissent. But Google revealed their view on the community, saying that feedback and comments aren't considered, and today moved to silence dissent and lock comments on the issue. [A Chromium developer] says, 'Commenting on this bug has absolutely no effect at all on the likelihood that we are going to reconsider. So that people don't get their hopes up falsely, I'm locking this bug to additional comments.'"
This discussion has been archived. No new comments can be posted.

No Tab Relocation Coming For Chrome

Comments Filter:
  • With tree-tabs! (Score:5, Informative)

    by Arker (91948) on Tuesday October 18, 2011 @05:38PM (#37755794) Homepage

    Seriously, this extension is a must: https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ [mozilla.org]

    I have always liked google and I still do, but their browser is not for me.

    And to those saying fork chrome - better to fork Firefox I think. It's already pretty much feature-complete and just needs to be yanked out of the hands of Mozilla before they figure out how to screw it up like chrome.

  • Re:This (Score:4, Informative)

    by shutdown -p now (807394) on Tuesday October 18, 2011 @06:04PM (#37756130) Journal

    Er, yes, you can.

    1. Right-click toolbar -> Customize -> Appearance.
    2. In "select which standard toolbars you want to show", check "Main bar" (it's a toolbar that is above the tab bar).
    3. Remove any predefined buttons on "Main bar", and place Back/Forward/Reload buttons, address and search fields etc on it, according to your taste. Now you have a duplicate address bar above tabs.
    4. Uncheck "Address bar" to hide the 'real' address bar (below tabs).

  • Re:Use Firefox (Score:5, Informative)

    by jlebar (1904578) on Tuesday October 18, 2011 @06:45PM (#37756644) Homepage

    These problems all exist because Firefox stubbornly clings to the antiquated and idiotic notion of having all tabs and windows run in a single process. [snip] When is Firefox going to stop wasting time on useless UI changes and actually fix their architecture?

    I think "stubbornly clings" is not supported by our actions. The multiprocess Firefox project is called Electrolysis. It's been going on for about two years now. We moved plugins to a separate process back in Firefox 3.6.4, in June 2010; that was part of the project. Firefox for Android uses two processes, to improve UI performance. Bringing multiprocess Firefox to the desktop is a priority, but it's hard.

    We're working on it, but it's a false dichotomy to suggest that we need to choose between improving our UI and improving our architecture. Indeed, if we choose one over the other, we lose. We have to do both.

    https://wiki.mozilla.org/Electrolysis [mozilla.org]

  • by DragonWriter (970822) on Tuesday October 18, 2011 @06:54PM (#37756712)

    From the last comment (#188) posted to the bug by a Googler:

    One more note here for the benefit of Slashdot (hi!) and anyone else who's not clear on this issue or how our bug tracker works.

    We made the decision not to make this configurable long, long ago, even before we WontFixed this bug in comment 59 (over a year ago itself). Accordingly the bug is closed because that reflects not only our current stance but the position we've had for a very long time.

    This does not mean either that we will never listen to user feedback, or that we used to be listening on this bug but decided to stop. The issue is that our bug tracker is specifically about tracking what we consider to be bugs, not a general forum for feedback and debate on our design decisions. That means that in general (this bug included), we can and will decide not to address particular requests, and when we do, commenting on the closed bug is not going to make us change our minds. On the contrary, we will not hesitate to lock things down in the bug tracker precisely to prevent things from spiraling out of control or misleading people into sharing their feedback here instead of where it's helpful

    We have other venues such as the chromium-discuss mailing list and our feedback forums where it is appropriate to share your opinions. The forums are a place where we are set up to track user feedback and surface the most critical issues to the team without impacting the productivity of us developers who are busy trying to make Chrome work better.

    We don't promise we'll change our minds, but we're not hostile to you expressing your point of view. This is just not the correct forum to do so.

Innovation is hard to schedule. -- Dan Fylstra

Working...