Closed Bug 616014 Opened 13 years ago Closed 13 years ago

Add a close icon to the add-on bar to dismiss it

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 4.0b8
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: jboriss, Assigned: dietrich)

References

Details

(Whiteboard: [addon bar][strings][target-betaN])

Attachments

(2 files, 5 obsolete files)

Mockup: Close button on OSX and Window's (Aero glass) add-on bar
183.26 KB, image/png
Details
v6
7.58 KB, patch
dietrich
: review+
Details | Diff | Splinter Review 
An X should be displayed on the far left side of the add-ons bar (or rather, the opposite side of where add-on icons start, if any platforms start on the left).  It should use the same type of close icon as the  Find-in-page bar has.  This X should dismiss the add-ons bar, but not reveal it.  This is mainly because any UI to reveal the bar would need to be ever-present at the bottom of the browser window - an area we're trying to keep minimal in the default state.  Bug XXXXX proposes a keyboard shortcut to reveal the bar, and a menu opion on Firefox's chrome will do so also.
Bug (In reply to comment #0)
>  Bug XXXXX proposes a keyboard shortcut to reveal the bar, and a menu opion on
> Firefox's chrome will do so also.

Bug XXXXX, of course, being Bug 616015
Component: Theme → Toolbars
QA Contact: theme → toolbars
Attached patch v1 (obsolete) — — Splinter Review 
* re-using strings for tooltip, title
* re-using findbar's close button css
Attachment #494622 - Attachment is obsolete: true
Attachment #494745 - Flags: review?(dao)
Comment on attachment 494745 [details] [diff] [review]
v1

sorry, meant that as feedback? request. still need to test on other platforms and write the test.
Attachment #494745 - Flags: review?(dao) → feedback?(dao)
(In reply to comment #3)
> * re-using findbar's close button css

I don't think we should put findBar.css in browser.xul. Instead, we should just copy the relevant CSS into browser.css.
Attached patch v2 (obsolete) — — Splinter Review 
css moved
Attachment #494745 - Attachment is obsolete: true
Attachment #494983 - Flags: feedback?(dao)
Attachment #494745 - Flags: feedback?(dao)
Comment on attachment 494983 [details] [diff] [review]
v2

> <?xml-stylesheet href="chrome://browser/content/browser.css" type="text/css"?>
> <?xml-stylesheet href="chrome://browser/content/places/places.css" type="text/css"?>
> <?xml-stylesheet href="chrome://global/skin/webConsole.css" type="text/css"?>
>+<?xml-stylesheet href="chrome://global/skin/findBar.css" type="text/css"?>

remove 

>              toolbarname="&addonBarCmd.label;" accesskey="&addonBarCmd.accesskey;"
>              collapsed="true"
>              class="toolbar-primary chromeclass-toolbar"
>              context="toolbar-context-menu" toolboxid="navigator-toolbox"
>              mode="icons" iconsize="small" defaulticonsize="small"
>              lockiconsize="true"
>              defaultset="status-bar"

Need to update the defaultset.

>              customizable="true" align="right">

align="right" should probably be dropped now.

>+      <toolbarbutton id="addonbar-closebutton" class="addonbar-closebutton"

class should be dropped, id suffices.

>+                     tooltiptext="&closeCmd.label; &addonBarCmd.label;"

This won't work for various locales.

>+                     title="&closeCmd.label;" removable="false"

Neither of these attributes does anything, I think.

>+                     oncommand="setToolbarVisibility(this.parentNode, false);"/>
>+      <toolbarseparator id="addonbar-separator" flex="1"/>

This should probably be a <toolbarspring>.

>--- a/browser/themes/pinstripe/browser/browser.css
>+++ b/browser/themes/pinstripe/browser/browser.css

>+.addonbar-closebutton:hover {
>+  list-style-image: url("chrome://global/skin/icons/closetab-hover.png") !important;
>+}
>+
>+.addonbar-closebutton:hover:active {
>+  list-style-image: url("chrome://global/skin/icons/closetab-active.png") !important;
>+}

!important shouldn't be needed here.

>--- a/browser/themes/winstripe/browser/browser.css
>+++ b/browser/themes/winstripe/browser/browser.css

>+.addonbar-closebutton {
>+  border: 1px solid transparent;
>+  padding: 2px !important;
>+  list-style-image: url("chrome://global/skin/icons/close.png");
>+  -moz-appearance: none;
>+  -moz-image-region: rect(0, 16px, 16px, 0);
>+}
>+
>+.addonbar-closebutton > .toolbarbutton-icon {
>+  -moz-margin-end: 0px !important;
>+  -moz-padding-end: 2px !important;
>+  -moz-padding-start: 2px !important;
>+}

see bug 615735
Attachment #494983 - Flags: feedback?(dao)
Attachment #494622 - Attachment is obsolete: false
Attached patch v3 (obsolete) — — Splinter Review 
fixed comments, except the last one. that fix doesn't need to block this, and isn't finished yet, so i'm not going to make those changes until they're finalized.
Attachment #494983 - Attachment is obsolete: true
Attachment #495469 - Flags: review?(dao)
Hardware: x86 → All
Whiteboard: [addon bar] → [addon bar][late l10n]
L10n, this patch adds a new tooltip string for the close button on the add-on bar.
(In reply to comment #8)
> fixed comments, except the last one. that fix doesn't need to block this, and
> isn't finished yet, so i'm not going to make those changes until they're
> finalized.

It's finalized, I r+'d the patch with some pending modifications. Please don't copy wrong code just because the fix hasn't landed yet. Take a look at webConsole.css, it already does it the right way.
Comment on attachment 495469 [details] [diff] [review]
v3

>+             defaultset="addonbar-spring,status-bar"

The close button is missing here.
(In reply to comment #10)
> It's finalized, I r+'d the patch with some pending modifications. Please don't
> copy wrong code just because the fix hasn't landed yet. Take a look at
> webConsole.css, it already does it the right way.

I copied the code already checked-in, instead of code that he hasn't confirmed works yet in that bug. If that code is already in the web console with your suggested modifications, then I'm ok with using it. Is that the case?
The "already checked-in" code is ancient. Don't copy.
webConsole.css has the right code, except that you want a different padding here (mentioned in bug 615735).
Attached patch v4 (obsolete) — — Splinter Review 
ok, does this look right?
Attachment #495469 - Attachment is obsolete: true
Attachment #495482 - Flags: review?(dao)
Attachment #495469 - Flags: review?(dao)
Comment on attachment 495482 [details] [diff] [review]
v4

>+      <toolbarspring id="addonbar-spring"/>

This doesn't quite work, because toolbarsprings get special treatment in the toolbar customization code. You can avoid that by making this a hbox with flex="1", e.g. <hbox id="addonbar-spring" flex="1"/>. r=me with that
Attachment #495482 - Flags: review?(dao) → review+
Attached patch v5 (obsolete) — — Splinter Review 
fixed review comment, added test.
Attachment #495482 - Attachment is obsolete: true
Attachment #495521 - Flags: review?(dao)
Comment on attachment 495521 [details] [diff] [review]
v5

>                  browser_tabMatchesInAwesomebar.js \
>                  file_bug550565_popup.html \
>                  file_bug550565_favicon.ico \
>                  browser_overLinkInLocationBar.js \
>                  browser_aboutHome.js \
>                  app_bug575561.html \
>                  app_subframe_bug575561.html \
>                  browser_contentAreaClick.js \
>+								 browser_addon_bar_close_button.js \

replace tabs with spaces

>+  is(addonbar.collapsed, false, "addon bar is not collapsed after toggle");

ok(!addonbar.collased, ...);

>+  closeButton.click();

I'm not sure what this is doing under the hood. Tests usually use synthesizeMouseAtCenter.
Attachment #495521 - Flags: review?(dao) → review+
Keywords: uiwanted
Attached patch v6 — — Splinter Review 
review comments addressed, ready for check-in.
Attachment #495521 - Attachment is obsolete: true
Attachment #495799 - Flags: review+
Whiteboard: [addon bar][late l10n] → [addon bar][late l10n][can land after 0.8 branch]
Whiteboard: [addon bar][late l10n][can land after 0.8 branch] → [addon bar][strings][can land after 0.8 branch]
Is there a reason to really wait with this until after beta 8?
Not for l10n, but that's not a "yes, land it".
Why is addonbar-spring not an actual 'flexible space' toolbar item? And as far as I can tell, the close button isn't removable either.

The thing I've been going on about in all of my add-on bar comments (which were ultimately duped here) is that the add-on bar should look and behave just like a regular toolbar. So, from the standpoint of a user who values the customizability of their toolbars, I find these kind of non-customizable element really aggravating.

Also, why is the close button always visible? It seems that it would only be relevant when the toolbar is shown because an extension was installed that added something to the toolbar (Bug 598923 and Bug 616419). Otherwise, the addon-bar is visible because I want it to be, and the presence of a close button is both unnecessary and unwanted.
(In reply to comment #22)
> Why is addonbar-spring not an actual 'flexible space' toolbar item?

See the previous comments in this bug.

> And as far as I can tell, the close button isn't removable either.

Correct. "Removable" implies "movable to other toolbars", which we don't want.
(In reply to comment #23)
> (In reply to comment #22)
> > Why is addonbar-spring not an actual 'flexible space' toolbar item?
> 
> See the previous comments in this bug.

Which AFAICT didn't elaborate on what the problems actually are.

> > And as far as I can tell, the close button isn't removable either.
> 
> Correct. "Removable" implies "movable to other toolbars", which we don't want.

I don't see how this would be entirely undesirable. It would be nice to have a toolbar widget that could be used to toggle the addon-bar visibility. The Web Developer extension has this for the web developer toolbar, and I make heavy use of it.


I guess my point is that I've been tryinf to get the add-on bar to basically be a plain old toolbar... but these changes are a step back from what it currently is.
1) Toolbarsprings aren't designed to be fixed items, that's all. For the details, please see toolbar.xml and customizeToolbar.js.

2) The tab strip isn't moveable, the menu bar isn't movable, fullscreen window controls aren't movable. "plain toolbar" doesn't mean no fixed items.
(In reply to comment #25)
> 1) Toolbarsprings aren't designed to be fixed items, that's all. For the
> details, please see toolbar.xml and customizeToolbar.js.

Why does it need to be fixed? If, say, I add the Status Text widget from Status-4-Evar, I don't want another flexible spacer on the toolbar.

> 2) The tab strip isn't moveable, the menu bar isn't movable, fullscreen window
> controls aren't movable. "plain toolbar" doesn't mean no fixed items.

Yes, that's true, but overall the number of fixed items have been going down. The "All tabs" drop-down and "New tab" buttons were made movable. Though the lack of customizability of the Firefox button (Linux) and Bookmarks menu button continue to be a great annoyance. But at least the latter can be removed.

I just don't understand the rationale behind making these fixed items. Making the close button into a visibility toggle, and making it and the spring movable, would make an overall more flexible UI and add superior functionality.
Blocks: 599225
One reason the "X" on the toolbar should be static is consistency.  Every close button in Firefox and in operating system is a part of the chrome of the window or object it effects, and thus isn't modifiable.  In Firefox, this is the case in every window and in every panel close is allowed on (such as find-in-page and arrow notifications).  If we allowed these buttons to be modifiable, we'd basically be encouraging people to make a browser that goes beyond customized and has inconsistent behavior throughout.

The default case of adding add-on icons to the toolbar should place them a standard distance apart.  Making flexible spacing isn't behavior we particularly want to encourage.  However, if the user's customize window is open and they drag a space into the add-on bar, it may as well work if possible.  It doesn't take away anything for this "easter egg" to work.
(In reply to comment #27)
> However, if the user's customize window is
> open and they drag a space into the add-on bar, it may as well work if
> possible.  It doesn't take away anything for this "easter egg" to work.

I was under the impression that the toolbar customize window was how one customized toolbars. Calling it an "easter egg" is a bit of a stretch. I had customized this toolbar the second it was added and I'm sure plenty of others will too. It's a toolbar and all the normal toolbar stuff applies.

That being said, I do agree that a fixed close button position is perfectly fine as it would give undefined results to move it out of the bar and there's no pressing reason to switch the side of the bar it's on.

You could however add a close button to the toolbar customization palette which would not leave the palette when dropped, similar to the spacers and separator, and allow one per bar to be dropped into any place. That'd be nifty, but outside the scope of this bug. It would have the benefit of allowing addon-bar-like behavior for custom created toolbars, but without a way to add a keyboard shortcut or button or something to show them easily it wouldn't be really useful. This all would then probably add more complexity than is warranted for most people, at which point I'd say this sort of thing is probably better suited to be implemented as an extension. ;)
http://hg.mozilla.org/mozilla-central/rev/e968527f1f6f
http://hg.mozilla.org/mozilla-central/rev/181ae0e690b7
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [addon bar][strings][can land after 0.8 branch] → [addon bar][strings]
Target Milestone: --- → Firefox 4.0b8
(In reply to comment #27)
> The default case of adding add-on icons to the toolbar should place them a
> standard distance apart.  Making flexible spacing isn't behavior we
> particularly want to encourage.  However, if the user's customize window is
> open and they drag a space into the add-on bar, it may as well work if
> possible.  It doesn't take away anything for this "easter egg" to work.

I'm not talking about flexible spacing. I'm talking about a flexible toolbar item (i.e. like the location or search bars). If I put my flexible item on the toolbar, and there's a permanent flexable spacer already there (à la addonbar-spring) then they're going to fight over space.

And this is not an "easter egg". Toolbar springs are standard toolbar items available in the customization palette. And I do know that previous versions of Firefox did have customizable toolbar springs on the menu toolbar (maybe others too) by default. So this is not a foreign concept.

The only surprise here is that now there's an invisible, non-removable spacer on the toolbar. Granted, they'll only discover this aggravating surprise if they try to put a flexible item on the addon bar. And don't say this wont happen. According to AMO, I've got ~6000 active Status-4-Evar users, and I'm betting a fair few of them are using the status text widget. So, assuming this is not changed, I now have to programmatically handle this, which is really not appreciated.
comment #27, in addition to using a false analogy and displaying nonsensical logic, also manages to be offensive.  who are you to encourage or discourage behavior?

yes, an extension will be needed to fix this mess..
Why is the app-bar any different than any other toolbar ?  There is no close button on the bookmarks bar, or the nav-bar, or the menu-bar... so what's the point of adding it to the app-bar, when if you want it back later, you are still forced to go to the Menu-button and 're-enable' it.. just like any other toolbar you decide you want to turn off. 

This is silly, and un-needed IMO and should be backed out- WONTFIX
Not to mention if there are already status bar extension widgets on the bar, the close button only goes to the right of them.  So in my Addon bar I have two icons for 2 extensions, then the close button.  Looks odd right there, but when I started, I had Status-4-Evar widgets there and the three items where centered on my bar.  So each person might have a different experience with this.
With this landing, I can no longer align things to the right. Which was my primary space for buttons added to the Addon Bar.

I'm also unable to remove the close button, which is wholly necessary for someone such as myself which lives with the thing open and have certain things aligned to the left.
(In reply to comment #34)
> With this landing, I can no longer align things to the right.

Try restoring the default set and then adding the items on the right. If it still doesn't work, please file a new bug.
Depends on: 618277
Depends on: 618278
Depends on: 618280
(In reply to comment #35)
> (In reply to comment #34)
> > With this landing, I can no longer align things to the right.
> 
> Try restoring the default set and then adding the items on the right. If it
> still doesn't work, please file a new bug.

Restoring to default set will not restore the addon-bar, or was this changed?

The right alignment bug happens if you have a flexible space in the addon-bar. An easy way to fix it is by opening localstore.rdf and adding "addonbar-" infront of "spring" in the list of items under the addon-bar (search for browser.xul#addon-bar and look under currentset).

The close button should probably be removeable, but until then you can add the following CSS to Stylish/userchrome.css: 

#addonbar-closebutton {
	visibility: collapse !important;
}
(In reply to comment #36)
> (In reply to comment #35)
> > (In reply to comment #34)
> > > With this landing, I can no longer align things to the right.
> > 
> > Try restoring the default set and then adding the items on the right. If it
> > still doesn't work, please file a new bug.
> 
> Restoring to default set will not restore the addon-bar, or was this changed?

This has been fixed.
(In reply to comment #27)

Can I just add that of all the toolbars listed in the toolbar menu. The addon bar is the only toolbar with a close button. The decision to feature a close button on only one of the toolbars that it's grouped with surely screams inconsistency?
In complete agreement with #32 and #38.  I can't imagine anyone would want to only temporarily display the add-on bar (unlike the one-and-done usage of the find bar).
In the original mockups, there was to be a button to show the addon bar and also to rehide (I think). That's where this originates from. This makes some sense with bug 616015, but if you've got a keyboard shortcut to show it then just doing it again to hide would probably be fine. Either way, this bar was always intended to be a repository for addon stuffs that you didn't want on screen at all times, thus saving screen real-estate. Personally, I don't mind too much if there's a close button or not, so long as it doesn't introduce problems, but I understand the argument for not wanting it as well.

I'd rather have a toggle button show on hover somewhere in a lower corner, at which point that would make more sense that a close button with no open button, but the original mockups are apparently not going to be done in full here.
The main flaw with the close button is that it's very easy to click it accidentally, then addon bar disappears and user is like "OMG, where all my buttons gone!!111". Now there is no obvious way to restore addon bar as simply as it takes to kill it. Let's not give users a gun to shoot their legs again.
Depends on: 618374
Depends on: 618326
No longer depends on: 618326
>who are you to encourage or discourage behavior?

Boriss is a member of the Firefox user experience team, and her job is to quite literally encourage or discourage user behavior.  In this case, she isn't just providing her views on the interface (which tend to be consistently correct), but also the views of the entire UX team.

>displaying nonsensical logic

close buttons should be placed in a consistent position.  For instance, it would be kind of bizarre if we allowed users to place a flexible space item next to the window controls (minimize, maximize, close), allowing them to move around the screen.

>also manages to be offensive

I'm genuinely sorry that you were offended.  However, I don't think anything in comment #27 was particularly out of line, just a mostly boring discussion of the rationale of ux-consistency, and that placing flexible space to move the close button around is kind of a strange behavior.
What is the benefit of the „addonbar-spring“?

Right now it just takes lots of space and prevents icon alignment to the left.
(In reply to comment #40)
> In the original mockups, there was to be a button to show the addon bar and
> also to rehide (I think). That's where this originates from. This makes some
> sense with bug 616015, but if you've got a keyboard shortcut to show it then
> just doing it again to hide would probably be fine.

The problem is that limiting this to a close-only button makes its functionality severely limited. There are 2 use cases:

1. The user doesn't want the Add-on Bar. They see the close button and click it. It's on-screen for a very limited time, and will never be seen again, until the user intentionally shows the toolbar (which will now probably fall under #2) or installs an extension that adds something to the toolbar.

2. The user does want the Add-on Bar. Now they will forever have to stare at a close button that holds no utility to them.

The close button has limited utility and is redundant to the toolbar content menu and eventual keyboard shortcut.

> Either way, this bar was
> always intended to be a repository for addon stuffs that you didn't want on
> screen at all times, thus saving screen real-estate.

Except I doubt that's how people will actually use it. People are used to seeing their status icons on the toolbar, and now they can place more status icons on it instead of cluttering the upper toolbars.

In my case, instead of having to dedicate an extra toolbar (or sacrifice URL or bookmarks space) to my toolbar icons, I can put them at the bottom, where they're still visible but now out of the way.



(In reply to comment #42)
> Boriss is a member of the Firefox user experience team, and her job is to quite
> literally encourage or discourage user behavior.  In this case, she isn't just
> providing her views on the interface (which tend to be consistently correct),
> but also the views of the entire UX team.

That may be so, but I still don't appreciate it. I REALLY don't like it when people tell me how to use software, especially when it comes to any kind of customization. That should be up to me, the user.

Regardless of how you think or want the browser to be used, there WILL be people who are going to use it differently. And forcing things on the user will alienate and frustrate those users.

Yes, I agree that IF there is a close button on the toolbar (and I don't think there should be), then it should be in a fixed location. But there is no rhyme or reason for making the spring a permanent fixed item.
(In reply to comment #44)
> or reason for making the spring a permanent fixed item.

and also
(In reply to comment #43)
> What is the benefit of the „addonbar-spring“?
> 
> Right now it just takes lots of space and prevents icon alignment to the left.

That's removed by the patch on bug 618277
Whiteboard: [addon bar][strings] → [addon bar][strings][target-betaN]
The close icon has currently a strange behaviour:

1. In “Customize” it seems that you can pick and drag the close icon, but if you drop it nothing happens. I think you shouldn't be able to pick the icon if it isn’t (re)moveable.

2. In text-only mode there is no text for this icon. It’s invisible but if you click the bar where it used to be it still closes the addon bar. I think invisible close buttons are quite confusing.
I think it is a horribly inconsistent UI decision to have a close button on one toolbar but none of the others.  The menu bar, navigation bar and bookmarks bar each use a consistent UI to enable/disable them, and none of them have a close button.  Why is the add-on bar any different?  It's confusing for users and seems entirely unnecessary.

It makes sense for the find bar because this bar is transient by nature.  Also, if you are trying to emulate the find bar, it makes no sense to have it on the opposite side of the screen.

From a user perspective, I cannot see a reason to have a close button at all, but if you insist upon keeping it, as others have said, you MUST have an easy way to disable it.  Allowing it to be dragged when customizing toolbars is also misleading and confusing if it cannot be moved or removed.
FWIW, the Notification Bar also has a close button too, but its meant to be dismissed like the Find Bar.
Why the align="right" attribute was removed from the addon-bar element?

Status bar panels are now aligned to the left by default so, eg. Firebug icon is on the left instead on the right side as usual.

Honza
(In reply to comment #49)
> Why the align="right" attribute was removed from the addon-bar element?
> 
> Status bar panels are now aligned to the left by default so, eg. Firebug icon
> is on the left instead on the right side as usual.

No, there's a spacer to push items to the right. Use "Restore Default Set" if you don't have that spacer.
(In reply to comment #47)
> It makes sense for the find bar because this bar is transient by nature.  Also,
> if you are trying to emulate the find bar, it makes no sense to have it on the
> opposite side of the screen.

The whole point is to allow transient usage patterns for the add-ons bar. As an example, I want to be able to pull up my three extensions (e.g. Firebug) 1-2 times per day, but I don't want them always visible. There's a separate bug on making Cmd/Ctrl-/ the shortcut for this toggle.

The "opposite side of the screen" is probably a bug, it should be consistent with the Find bar and the respective platform behavior for the close button.
i would really like to have an easy option to ide the close button. maybe it can call out via an arrow box: “hi, i’m the close button of the addon bar. nobody might use her like that (opening and closing her all the time) but that’s what i’m for. if you like her so much you don’t wanna see me again, please click on this big red pulsating button!”


nah, really there are 3 use cases (ordered by estimated usage):
1. keep addonbar open
i’m sure most will do so and that they won’t like the close button.

2. close addonbar forever
this is a one-time action and doesn’t need an always-present button in the user’s face. right-click and remove the hook beneath “addon bar” will do just fine

3. only open the addon bar when you need it
the few people who do so will either use a shortcut (which they can use to close it again, too) or would like to have a toggle button like in the initial mockups


you see: only in *one half* of the *least used* usecase there is something *similar* to the close button. it is really a bad idea.
Just great, another example of UX people who-should-know-better, after applying myopic assessment criteria, not getting decent UX...

This should be seen as a usability regression and backed out. *sigh*

I wonder if blind belligerence will rule here and we'll end up with this nonsensical, on-balance unjustified aberration in the final release! :/
What about displaying the close button only when the Add-on Bar is activated by keyboard shortcut?
Why would you even need this close icon, when you can simply right click on bar and menu with enabled/disabled toolbars will appear...
The point is, some users want to show the Add-on Bar when needed and quickly dismiss it after use. There is even a userstyle to have it autohide: http://userstyles.org/styles/37319
If they want, they simply can reverse enabling method, by disabling this addon bar like others in the menu...

Now users who want addon bar will be visible all the time can missclick this button and all addon bar will close, it's illogical change

This patch should be reverted
This is yet another example of how braindead this thing has become. I see this happening all over. The decision-making process in here has become dominated by people that honestly don't have a clue. STILL, these clueless people are the ones making decisions in here!!!

Take for example, the X to close the add-on bar. All you need to do is right click the add-on bar and de-select it! Do we really need an X to do the same thing? Guess what: according to the prodigies that roam this mental institute, we do, and moreover, it can't even be hidden!

Now, IF there is anyone left in here with ANY common sense left in him, just ditch the fμcking X altogether. IT'S SUPERFLUOUS AND ANNOYING!!!
For every decision you hate about Firefox 4, there are probably ten you love made by those very same people. I'm sure you're grown up enough to edit your userstyle.css to hide the close button.
(In reply to comment #59)
> For every decision you hate about Firefox 4, there are probably ten you love
> made by those very same people. I'm sure you're grown up enough to edit your
> userstyle.css to hide the close button.

But why add sth which:
-will be rarely used, ppl using addons don't want to close addon toolbar because they use it... other ppl will don't see it because it disabled by default if you don't have addons...
-will have duplicate feature, because you can enable/disable all toolbars with menu...
-can create many miss-clicks when ppl will have some amount of addons present in addon toolbar...

Of course you can modify your CSSs but you thing not geek person will do this nasty hack without knowledge when write there or spend time searching in web to do so ? I don't think so...
As many people that have commented in this bug, the close button is a constant annoyance for people using the status / addons bar and makes no sense to anyone except for the very few who would pull up that bar only when needed. This follows in the series of lulzy decisions by the Firefox UX team like removing the rss button, moving the reload button into the address field, removing / wanting to remove View source from page context menu, disabling the option to double click empty space on the tab bar to open new tab etc etc.
This is not a forum. Please stop treating it like one.

For what it's worth, I tend to agree that the close button here isn't helpful. The keyboard shortcut is a much better route. That being said, I'm not whining about it rudely. File a new bug and leave this one alone.
A fix can be reverted in a bug tracker. This one has enough good arguments to be reverted imo.
Filed Bug 629905 against this change.
Blocks: 629905
You need to log in before you can comment on or make changes to this bug.