Closed Bug 574688 Opened 14 years ago Closed 14 years ago

replace the status bar with the addon bar

Categories

(Firefox :: Toolbars and Customization, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: dietrich, Assigned: dietrich)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-complete, Whiteboard: [strings][addon bar])

Attachments

(8 files, 21 obsolete files)

2.08 KB, application/x-xpinstall
Details
104.75 KB, image/png
Details
2.23 KB, image/png
Details
3.28 KB, image/png
Details
71.87 KB, patch
asaf
: review+
Details | Diff | Splinter Review
30.35 KB, image/jpeg
Details
1.20 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
6.24 KB, image/png
Details
      No description provided.
Attached patch wip (obsolete) — Splinter Review
hide it by default. remove it's contents. working with UX to figure out what to do with the progress meter, download monitor and security button.
Assignee: nobody → dietrich
Blocks: 568932
this is just a POC to play with the jetpack widget api. the final patch need to hide the existing status bar element, keeping it and it's id intact so that installed addons that use it don't completely break the browser. we'll need to create a new status bar for widgets from jetpack-based addons. or some alternate approach that safely handles existing addons' usage of the status bar.
* changing the dependency, since the jetpack piece has to be ready to go before this can land
* linking to the project page and spec: https://wiki.mozilla.org/Firefox/Projects/AddonUI
No longer blocks: 568932
Depends on: 568932
Priority: -- → P1
Summary: remove the status bar by default → replace the status bar with the addon bar
See bug 514475 for the security button.
As far as hiding the status bar keep in mind if you decide to unhide it by moving the pointer to the bottom of the screen you have to consider that the Windows Taskbar also unhides by moving the pointer to the bottom of the screen.
Bug 568932 is fixed in Jetpack, making the add-on bar proper toolbar and widgets proper toolbaritems.

Other items still needing resolution:

* Figure out how to get toolbars not in navigator-toolbox, into the View menu or treated as part of the nav toolbox (bug 579506). Theoretically this should integrate the add-on bar into customization so that widgets can be dragged on/off the palette onto the add-on bar.

* Persist widget properties, visibility and placement (bug 579505).

* Need to turn off script, interactivity, and maybe even content from loading, when widgets are in the palette.

* Implement the install/enable interactions: collapsed by default, enabled via addon install, toggleable via customize menu.
Attached patch wip2 (obsolete) — Splinter Review
Attachment #454046 - Attachment is obsolete: true
Drivers: UX has said this is a key part of the Fx4 facelift, so requesting blocking.
blocking2.0: --- → ?
blocking2.0: ? → beta5+
Please consider Bug 489303 in regards to the lack of a window resizer this will create.  The edge of the window frame is simply too small of a target for practical use.
Attached patch v1 (obsolete) — Splinter Review
v1 - removes code, styles and tests for everything currently in the status bar. Adds an empty add-on bar. Add-on bar visibility and population is currently managed by the Widget module in Jetpack. The visibility-toggling bits will likely have to move into Firefox in a followup bug before final.

Dao, can you do a first-pass review on this?
Attachment #458733 - Attachment is obsolete: true
Attachment #465223 - Flags: feedback?
Attachment #465223 - Flags: feedback? → feedback?(dao)
(In reply to comment #9)
> Please consider Bug 489303 in regards to the lack of a window resizer this will
> create.  The edge of the window frame is simply too small of a target for
> practical use.

Ok, I'll set the dependencies and get the UX team to take a look.
Depends on: 489303
Attachment #465223 - Flags: feedback?(dao) → feedback?(mano)
So this actually keeps the status bar but hides it by default, and if the user enables it he will see an empty bar? Any reason not to display what we've always displayed in that case, target URLs in particular?
No, I still need to remove the visibility toggle from the View menu. The idea is that the status bar is gone entirely.

The only reason to not remove it from the DOM is to avoid complete and total breakage when add-ons try to access the element and don't handle the case where it's not there.

A downside to that is that there could be a bunch of add-on UI hanging off the hidden element. Or add-ons could unhide the element, leading to both bars being visible. Maybe we should just remove it entirely.
Depends on: 541656, 544818
If you're 'removing' it, then say you should actually remove it. No need to encourage incorrect/broken behavior in extensions.

Plus, enough has been done to break extensions already. IMHO, adding one more thing to the pile won't hurt.
(In reply to comment #13)
> No, I still need to remove the visibility toggle from the View menu. The idea
> is that the status bar is gone entirely.

Do you mean completely remove status bar with target link location? Or it will be moved to somewhere else? This is critical for me.
I believe it will be moved to Doorhanger.
Sorry if I'm dragging this off the topic, but how does this relate to the Firefox sync status icon, which is now built-in and placed on the status bar? Is that going to go on the addon bar? Or somewhere else?
(In reply to comment #17)
> Firefox sync status icon, which is now built-in and placed on the status bar?

This shouldn't be permanently in the primary UI in the first place.
(In reply to comment #18)
> (In reply to comment #17)
> > Firefox sync status icon, which is now built-in and placed on the status bar?
> 
> This shouldn't be permanently in the primary UI in the first place.

In fairness, when it was removed, there was a lot of angry noises and rightfully so.
(In reply to comment #19)
> > > Firefox sync status icon, which is now built-in and placed on the status bar?
> > 
> > This shouldn't be permanently in the primary UI in the first place.
> 
> In fairness, when it was removed, there was a lot of angry noises and
> rightfully so.

... because there was no notification when syncing would fail. A permanent icon in the primary UI isn't the right solution to this.
(In reply to comment #20)
> (In reply to comment #19)
> > > > Firefox sync status icon, which is now built-in and placed on the status bar?
> > > 
> > > This shouldn't be permanently in the primary UI in the first place.
> > 
> > In fairness, when it was removed, there was a lot of angry noises and
> > rightfully so.
> 
> ... because there was no notification when syncing would fail. A permanent icon
> in the primary UI isn't the right solution to this.

That wasn't the only complaint. People didn't know when it was one or active and wanted to be informed of such. The text was too much but the current implementation is a lot closer to being right than removing it and only displaying faults.

That said, this clearly isn't the right place for this conversation. I'm sure the UX team has read all sides of the argument and will come up with something.
(In reply to comment #18)
> (In reply to comment #17)
> > Firefox sync status icon
> This shouldn't be permanently in the primary UI in the first place.

Well, it is already there. If that's going to change, I guess there should be some discussion between the Mozilla UX people and the sync team. Which is kind of why I mentioned it - as far as I know, it hasn't been considered yet.
When I point a mouse to some link I see it's address in the statusbar. I would like to have it after removing the status bar. Actually if it will behave chrome-like (gets hidden when the pointer is not over a link and gets shown when it is), it would be just awesome. Are there any plans about that? Or where should this toolbar move? Or they plan to cut it completely?
(In reply to comment #23)
Read the bug dependencies.
Depends on: 587908
No longer depends on: 541656
As for feedback?, this looks good overall.  Review comments and nits will come when review? is asked.

A couple of issues before this moves from feeaback+ to review?
1. Where will we show the url for an hovered link in web pages and UI?? What about status text set by web-pages? 
1.1. If the answer is "we won't", you should remove all browser/ calls to setOverLink, and make sure we remove the code that handles hovered links, not just updateStatusField.
2. What's the replacement for DownloadMonitorPanel? The code for it shouldn't be removed for now.
3. Why does your toolbar need a toolbox, and did you really mean to make it customizable. Our customization UI isn't ready for bottom toolbars.
4. What's the use of the now hidden status-bar element? I suppose you could still show it by View->Status Bar. We cannot keep it that way if no data is shown there when status data is expected.
5. I'd like to see some prototype code for the addons bar.
Attachment #465223 - Flags: feedback?(mano) → feedback+
Depends on: 579506
Depends on: 590543
(In reply to comment #12)
> So this actually keeps the status bar but hides it by default, and if the user
> enables it he will see an empty bar? 

Perhaps a better way would be to provide a target that allows the user to dismiss and reopen the add-ons bar - similar to the functionality in the following mockup but spanning the entire width of the page rather than a section:

http://jboriss.files.wordpress.com/2010/06/fourth_series.png?w=480&h=252

(In reply to comment #12)
> So this actually keeps the status bar but hides it by default, and if the user
> enables it he will see an empty bar? Any reason not to display what we've
> always displayed in that case, target URLs in particular?

I think this conflates the point of the add-ons bar (to provide prime real estate for add-ons) with old status bar functionality.  If users want the old status bar, they could reenable it in about:config.  However, the add-ons bar really isn't the place to slowly bring back old functionality as long as there is room for it.  We also want to encourage add-on authors to be creative and create widgets rather than targets if they choose.

(In reply to comment #17)
> Sorry if I'm dragging this off the topic, but how does this relate to the
> Firefox sync status icon, which is now built-in and placed on the status bar?
> Is that going to go on the addon bar? Or somewhere else?

It's moving to the top right of the UI - see bug 589981

(In reply to comment #26)
> 1. Where will we show the url for an hovered link in web pages and UI?? What
> about status text set by web-pages

This is moving to an overlay over the URL bar - see bug bug 587908

> 2. What's the replacement for DownloadMonitorPanel? The code for it shouldn't
> be removed for now.

This is currently unknown.  The Download Manager was previously redesigned in  bug 564934, but that is looking unlikely for Firefox 4.0.  There may be another good place to temporarily put DownloadMonitorPanel's functionality for 4.1 - for instance, tabs may be prime candidates as downloads are linked to tabs and we currently show a status indicator here for page content already.

> 3. Why does your toolbar need a toolbox, and did you really mean to make it
> customizable. Our customization UI isn't ready for bottom toolbars.

This behavior should be targeted at Firefox 4.1, not Firefox 4.0.  From a conversation with Dietrich in IRC: this customizability will allow elements of the addons bar to be moved to different areas of Firefox that support customization (navigation bar, toolbar, addon bar, possibly more).  Implementing this would just use the current customization sheet which would then need to support customization of stuff below it: not just in the nav toolbox area.  

> 4. What's the use of the now hidden status-bar element? I suppose you could
> still show it by View->Status Bar. We cannot keep it that way if no data is
> shown there when status data is expected.

This should probably be moved to about:config and removed from View.
Would this new add-ons bar conflict with the find/quick-find bars? If so should a bug be opened to have those redesigned or moved? The mock-ups I've seen of the new add-ons bar wouldn't work well with the current searching UI.
>Would this new add-ons bar conflict with the find/quick-find bars?

Not that much more than the find bar conflicts with the current status bar (with a lot of extensions in it). We do need to redesign the find bar, but that isn't in scope for this release since we have a lot of other stuff in flight right now.
Two ideas:
1. Use Doorhanger (probably problematic, Alex should know)
2. Attach it to the NavBar with same behaviour (probably better solution)
Attached patch v2 (obsolete) — Splinter Review
a few minor fixes. still need to fix setOverLink calls.

this is not going to make beta 5. it would be premature to remove the status bar without having all of the replacement features in place.

the bugs for those replacement features are currently inventoried in the bugs that are dependent, but that seems backward - we need to have those in place before we remove their current incarnations, so i'll switch it around.
Attachment #465223 - Attachment is obsolete: true
(In reply to comment #31)
> the bugs for those replacement features are currently inventoried in the bugs
> that are dependent, but that seems backward - we need to have those in place
> before we remove their current incarnations, so i'll switch it around.

Nm, dependencies are correct as-is.
blocking2.0: beta5+ → beta6+
Mano, what do you think about making setOverLink send a notification out? That way extensions can easily hook into this, and any new status text functionality we add can use the existing calls.
Since you hardly ever want the same status text in two places, extensions can simply override setOverLink.
Removing the dependencies on the customization parts, which we can live without in this release. Not ideal, but doesn't at all need to block landing this.
No longer depends on: 579506, 590543
(In reply to comment #34)
> Since you hardly ever want the same status text in two places, extensions can
> simply override setOverLink.

ok yeah that's probably fine for now.
No longer depends on: DownloadsPanel
Whiteboard: [strings]
I'm not seeing string changes in the current patch, is this "may change strings" or "will surely change strings" or "may very well remove strings"? Or just none of the above?
The option to hide or display the bar in the menus needs to be updated (is Extension Bar the final name?)
(In reply to comment #38)
> The option to hide or display the bar in the menus needs to be updated (is
> Extension Bar the final name?)

Everyone I've been talking to has referred to it as the Add-on Bar, which Limi confirmed.
Attached patch v3 (obsolete) — Splinter Review
A few loose ends to tie up, but ready for review to start.

to do:

* test Test Pilot changes, get review from them
* test Sync changes, get review from them
* fix default status of visibility on view menu
* test add-on presence/absence interaction w/ user's manual setting (note to self: update widget code to use the command)
* figure out genericization of link-on-hover, in places sidebar code, for example
Attachment #470010 - Attachment is obsolete: true
Attachment #471418 - Flags: review?(mano)
Is there a bug for the popup blocker stuff? xoxo, Pike.
Comment on attachment 471418 [details] [diff] [review]
v3

> function FillHistoryMenu(aParent) {
>-  // Lazily add the hover listeners on first showing and never remove them
>-  if (!aParent.hasStatusListener) {
>-    // Show history item's uri in the status bar when hovering, and clear on exit
>-    aParent.addEventListener("DOMMenuItemActive", function(aEvent) {
>-      // Only the current page should have the checked attribute, so skip it
>-      if (!aEvent.target.hasAttribute("checked"))
>-        XULBrowserWindow.setOverLink(aEvent.target.getAttribute("uri"));
>-    }, false);
>-    aParent.addEventListener("DOMMenuItemInactive", function() {
>-      XULBrowserWindow.setOverLink("");
>-    }, false);
>-
>-    aParent.hasStatusListener = true;
>-  }

Just like the other calls to setOverlink, we shouldn't remove this.
Attached patch v4 (obsolete) — Splinter Review
Attachment #471418 - Attachment is obsolete: true
Attachment #471535 - Flags: review?(mano)
Attachment #471418 - Flags: review?(mano)
Latest patch fixes Dao's comment, has a bunch of cleanup, and some more consolidation.
Limi: we group everything under the name add-on (theme, persona, plugin, language pack, extension). This bar can only show extensions (built with the Firefox Extension SDK), seems like we should either try to collapse the number of terms or change this to the extension bar.
(In reply to comment #45)
Neither themes, nor personas, nor plugins, nor language packs create any buttons on the status bar, so Add-on Bar is okay, I think. But you didn't list jetpacks - I hope Add-on Bar will also support them.
It was my impression that jetpacks would be called "extensions"
I've heard the phrase "lightweight extensions" thrown around a lot for jetpacks in the same way that personas are "lightweight themes". The "lightweight" part just seems to be dropped often for user simplicity. If we're taking opinions, I like "extension bar" as it's more specific but "add-on bar" is fine too.
I think "Extension Bar" would be good as there is currently too much confusion among users about the ambiguous term "Add-on".  The more Mozilla can do to make this distinction clear the better IMO.  As far as the difference between "extensions" and Jetpacks/"lightweight extensions" there really is not going to be any difference for the end user, just for the developers, so I see no reason to differentiate between the two.  Personas and Themes however are different things from a user point-of-view (especially when Personas are fixed to allow them on top of any theme).
It looks like this bug depends on #564934, because currently the download status is shown on the status bar. Am I wrong?
(In reply to comment #50)
> It looks like this bug depends on #564934, because currently the download
> status is shown on the status bar. Am I wrong?

Apparently not. Don't forget that a toaster pop-up is used as well, once the download is finished.

However, I personally agree with you that bug 564934 should be blocking this bug, but I'm not sure if it'll make it in time for the feature freeze in about 5 days.
--- a/browser/app/profile/extensions/testpilot@labs.mozilla.com/content/tp-browser.xul
+++ b/browser/app/profile/extensions/testpilot@labs.mozilla.com/content/tp-browser.xul

+<toolbar id="addon-bar">
+  <toolbaritem id="pilot-notifications-button"
+               class="statusbarpanel-iconic"
+               insertbefore="security-button"

There's no such button.

--- a/browser/app/profile/firefox.js
+++ b/browser/app/profile/firefox.js

-// Make the status bar reliably present and unaffected by pages
-pref("dom.disable_window_open_feature.status",    true);
...
-pref("services.sync.prefs.sync.dom.disable_window_open_feature.status", true);
-pref("services.sync.prefs.sync.dom.disable_window_status_change", true);

Shouldn't we rather make these preferences affect the new bar? What's the the story for the new bar within popup windows? How does it play with the "statusbar" feature?

--- a/browser/base/content/browser-menubar.inc
+++ b/browser/base/content/browser-menubar.inc
….
+                <menuitem id="toggle_addonbar"
+                          label="&addonBarCmd.label;"
+                          accesskey="&addonBarCmd.accesskey;"

Should it be visible when there's nothing in the addon bar.

--- a/browser/base/content/browser-places.js
+++ b/browser/base/content/browser-places.js

-      // Set the targetURI attribute so it will be shown in tooltip and statusbar.
+      // Set the targetURI attribute so it will be shown in tooltip.

Maybe "and trigger onLinkHovered"?

--- a/browser/base/content/browser-sets.inc
+++ b/browser/base/content/browser-sets.inc

-    <command id="cmd_toggleTaskbar" oncommand="goToggleToolbar('status-bar','toggle_taskbar');"/>
+    <command id="cmd_toggleAddonbar" oncommand="goToggleToolbar('addon-bar','toggle_addonbar');"/>

I prefer …Addon*B*ar

--- a/browser/base/content/browser-syncui.js
+++ b/browser/base/content/browser-syncui.js

What's the replacement for the sync button?

--- a/browser/base/content/browser.css
+++ b/browser/base/content/browser.css
 
 #navigator-toolbox ,
-#status-bar ,
+#addon-bar ,
 #mainPopupSet {
   min-width: 1px;
 }

Why is that needed?

--- a/browser/base/content/browser.js
+++ b/browser/base/content/browser.js
… 
-    if (!this._reportButton)
-      this._reportButton = document.getElementById("page-report-button");
-
     if (!gBrowser.pageReport) {
-      // Hide the popup blocker statusbar button
-      this._reportButton.hidden = true;
-
       return;
     }

nit: remove the braces.

@@ -550,18 +541,16 @@ const gPopupBlockerObserver = {
...
     if (aEvent.target.localName == "popup")
       blockedPopupDontShowMessage.setAttribute("label", gNavigatorBundle.getString("popupWarningDontShowFromMessage"));
-    else
-      blockedPopupDontShowMessage.setAttribute("label", gNavigatorBundle.getString("popupWarningDontShowFromStatusbar"));

Is |if (aEvent.target.localName == "popup")| still needed after this change?


--- a/browser/base/content/browser.xul
+++ b/browser/base/content/browser.xul

+               hidden="true" customizable="true"/>

For now, just don't make it customizable (customizibility requires overlaying the addon items into a toolbarpallet.
 
--- a/browser/components/places/content/sidebarUtils.js
+++ b/browser/components/places/content/sidebarUtils.js

For bookmarks, you can now use "Properties". For History items, there's pretty much nothing you can do (the tooltip cannot show long urls).

--- a/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_downloadmonitor.js
+++ b/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_downloadmonitor.js

 function test() {
+  // Disabled 

In the makefile.

diff --git a/browser/components/sessionstore/src/nsSessionStore.js b/browser/components/sessionstore/src/nsSessionStore.js
--- a/browser/components/sessionstore/src/nsSessionStore.js
+++ b/browser/components/sessionstore/src/nsSessionStore.js

 const WINDOW_HIDEABLE_FEATURES = [
   "menubar", "toolbar", "locationbar", 
-  "personalbar", "statusbar", "scrollbars"
+  "personalbar", "addonbar", "scrollbars"
 ];

This looks very very wrong.

--- a/browser/locales/en-US/chrome/browser/pageReportFirstTime.dtd
+++ b/browser/locales/en-US/chrome/browser/pageReportFirstTime.dtd
@@ -1,7 +1,7 @@
-<!ENTITY startDescription.label            "A web site has attempted to open a pop-up window without your permission. &brandShortName; has automatically closed the pop-up window.  Whenever &brandShortName; blocks these pop-ups, you will see an icon on the status bar.">
+<!ENTITY startDescription.label            "A web site has attempted to open a pop-up window without your permission. &brandShortName; has automatically closed the pop-up window.  Whenever &brandShortName; blocks these pop-ups, you will see an icon somewhere, not sure yet. xoxo, Dietrich">

Ugh?

--- a/browser/locales/en-US/feedback/main.dtd
+++ b/browser/locales/en-US/feedback/main.dtd
@@ -1,10 +1,10 @@
 <!ENTITY testpilot.brand.label                      "Test Pilot">
-<!-- browser window: menu and status bar -->
+<!-- browser window: menu and add-on bar -->

Just remove this comment.

--- a/browser/themes/*stripe/browser/browser.css
+++ b/browser/themes/*stripe/browser/browser.css

+#addon-bar {
+  padding: 0px;
+  margin: 0px;
 }

Isn't that the default? Either way, s/0px/0/
Comment on attachment 471535 [details] [diff] [review]
v4

I would to do a final-pass on the next version, thus minusing.
Attachment #471535 - Flags: review?(mano) → review-
Also
1) I think you should not touch the defualt here: -pref("dom.disable_window_status_change",          true);
2) As things stand, only one extension can do something useful with setOverLink (etc) because it would have to override the function. This seems wrong considering the use cases for the new bar. It shouldn't be hard to add a basic observers API.
Blocks: 593949
Depends on: 589981
No longer depends on: 589981
(In reply to comment #54)
> 2) As things stand, only one extension can do something useful with setOverLink
> (etc) because it would have to override the function. This seems wrong
> considering the use cases for the new bar. It shouldn't be hard to add a basic
> observers API.

If by observers API you mean nsIObserver, then this doesn't seem ideal, as those notifications would be global rather than bound to a window.

Please don't over-engineer. There's probably hardly a use case for the URL to be displayed in two places. So while multiple add-ons might try to override setOverlink, you probably want only one to succeed.
Attached patch v5 wip (obsolete) — Splinter Review
Attachment #471535 - Attachment is obsolete: true
No, I didn't refer to nsiobserver. All we need is a simple js pseudo-api.
>seems like we should either try to collapse the number
>of terms or change this to the extension bar.

everyone agrees that collapsing the number of terms is ideal, so you can "use the Add-on SDK to place an add-on in the add-on bar, and then manage them all with the add-on manager."
Yeah, I think the subtlety of the "extensions" vs. "add-on" is lost on most people.

We brand it as the add-ons manager, there's addons.mozilla.org, and in general it is a less geeky and more appropriate term for what it actually is. (It's something that you add on to your browser, it doesn't make your browser longer / more extended :P)

The current flow is currently very weird:
- Select "Add-ons" from the menu
- "Extensions" are selected
- You get more "Extensions" by clicking on "Get Add-ons"

Calling them all "add-ons" is the best way to unify this and make it consistent, IMO.
Muddling the terms sometimes is good for user comprehension, but we can't kill the terms outright otherwise we'd never be able to sort through the mess of different types when needed. In other words, use "add-on" a lot, but keep "extension" & etc. for the various panes in the Add-on Manager. Here though, I couldn't care less if it's called the "add-on bar" or the "extension bar". Either is fine.

Frankly, while the subject is up, we really should be using "addon" instead of "add-on" as we already dropped the hyphen in "plug-in" to "plugin" ages ago.
I'm curious as to how Downloads are planned to be handled if this goes ahead for 4.0, since apparently Bug 564934 appears to not be ready for 4.0.  I'm also curious as to why there is no blockers for Downloads indication with this bug in general.
(In reply to comment #61)
> I'm curious as to how Downloads are planned to be handled if this goes ahead
> for 4.0, since apparently Bug 564934 appears to not be ready for 4.0.  I'm also
> curious as to why there is no blockers for Downloads indication with this bug
> in general.

IIRC there are comments to this effect in the bug 564934 (and maybe this one too), but my apologies for it not being clearer. The summary is that 1) a focus of the new theme is on removing primary UI and 2) the download manager still has the UI that everyone knows via the tool menu and 3) add-ons can build put that exact functionality in the new add-on bar and 4) if that new download manager UI *is* ready in time we'll take it.
Via options/preferences -> content -> (JavaScript) Advanced button
There is the "Advanced JavaScript Settings" dialog. Its last two options involve the status bar. This will need to be dealt with in some form if the status bar is officially removed completely.

Does this patch here cover both these options, including their GUI, or will a new followup bug be needed for this?
Attached patch v5 wip (obsolete) — Splinter Review
* adds detection of items added to and removed from the add-on bar, toggles visibility appropriately

* some experimental code for auto-migration of pre-existing statusbar addon elements. this was unfeasible, due to repeated access of those nodes in the context of the status-bar element.

* fixes the customizability bits to match the jetpack widget implementation. however, not sure we want that yet, so might go away.
Attachment #472734 - Attachment is obsolete: true
(In reply to comment #63)
> Does this patch here cover both these options, including their GUI, or will a
> new followup bug be needed for this?

Yes, the patch makes it all gone.
Comment on attachment 473418 [details] [diff] [review]
v5 wip

startDescription.label will need a new id.
No longer depends on: 544818
No longer depends on: 489303
Attached patch v5 wip (obsolete) — Splinter Review
* fixes the string axel pointed out
* disables pagereportfirstpage page from loading, until bug 594294 gets fixed
* more cleanup and bugs fixed in visibility persistence code
Attachment #473418 - Attachment is obsolete: true
(In reply to comment #67)
> Created attachment 473589 [details] [diff] [review]
> v5 wip
> 
> * fixes the string axel pointed out

Still needs the id rev for startDescription.label, not just the xoxo removal.
I forgot to qrefresh.
Whiteboard: [strings] → [strings][has WIP patch]
Attached patch v5 (obsolete) — Splinter Review
some problems getting the hidden state to persist, but outside of that, ready for another review pass.
Attachment #473589 - Attachment is obsolete: true
Attachment #473679 - Flags: review?(mano)
(In reply to comment #52)
> +<toolbar id="addon-bar">
> +  <toolbaritem id="pilot-notifications-button"
> +               class="statusbarpanel-iconic"
> +               insertbefore="security-button"
> 
> There's no such button.

Filed bug 593949 for Test Pilot update, moved the changes over there and out of this patch.

> -pref("services.sync.prefs.sync.dom.disable_window_open_feature.status", true);
> -pref("services.sync.prefs.sync.dom.disable_window_status_change", true);
> 
> Shouldn't we rather make these preferences affect the new bar? What's the the
> story for the new bar within popup windows? How does it play with the
> "statusbar" feature?

There is no statusbar feature anymore, just the add-on bar, that does not do status-y things (which belong up in the navigational area). Note how all core features that involve the statusbar are being located to other places in the UI. All the code related to these prefs should be gone as of this patch.

> +                <menuitem id="toggle_addonbar"
> +                          label="&addonBarCmd.label;"
> +                          accesskey="&addonBarCmd.accesskey;"
> 
> Should it be visible when there's nothing in the addon bar.

No. Mostly fixed in this patch, but still working on the xul attribute persistence bits.

> What's the replacement for the sync button?

Available in the Tools menu, and see bug 589981 for primary UI exposure of sync.

> --- a/browser/base/content/browser.xul
> +++ b/browser/base/content/browser.xul
> 
> +               hidden="true" customizable="true"/>
> 
> For now, just don't make it customizable (customizibility requires overlaying
> the addon items into a toolbarpallet.

Jetpack widgets currently add themselves to the toolbar palette, and currently default their placement the add-on bar. I'd just forgotten to migrate the code to hook up the add-on bar's toolbox to the nav toolbox's palette.

> --- a/browser/components/places/content/sidebarUtils.js
> +++ b/browser/components/places/content/sidebarUtils.js
> 
> For bookmarks, you can now use "Properties". For History items, there's pretty
> much nothing you can do (the tooltip cannot show long urls).

What do you mean by "Properties"?

> +<!ENTITY startDescription.label            "A web site has attempted to open a
> pop-up window without your permission. &brandShortName; has automatically
> closed the pop-up window.  Whenever &brandShortName; blocks these pop-ups, you
> will see an icon somewhere, not sure yet. xoxo, Dietrich">
> 
> Ugh?

updated, and filed bug 594294 to figure out where the icon should/could go. doesn't need to block this bug though.
Comment on attachment 473679 [details] [diff] [review]
v5

>+    this.el.addEventListener("DOMNodeInserted", this, false);
>+    this.el.addEventListener("DOMNodeRemoved", this, false);

DOM mutation event listeners slow down all DOM mutations in that window, afaik. Not 100% sure if this really applies here, but at least smaug told me not to use DOMAttrModified.
Smaug, is that also the case with these mutation events?
Comment on attachment 473679 [details] [diff] [review]
v5

diff --git a/browser/base/content/browser-menubar.inc b/browser/base/content/browser-menubar.inc
--- a/browser/base/content/browser-menubar.inc
+++ b/browser/base/content/browser-menubar.inc

+                <menuitem id="menu_toggleAddonBar"

So, given that it's customizable etc., shouldn't it go to view->toolbars?

...
+                          command="cmd_toggleAddonBar"
+                          observes="cmd_toggleAddonBar"

You should never need both.

+                          persist="checked"/>

The menuitem should simply mirror the toolbar state, look at onViewToolbarsPopupShowing.


diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
--- a/browser/base/content/browser.js
+++ b/browser/base/content/browser.js

   dontShowMessage: function ()
   {
+    /* disabled until bug 594294 is fixed.
+    

Use #if, remove trailing spaces.

 
+let AddonBar = {
+  get el() document.getElementById("addon-bar"),
+  get command() document.getElementById("cmd_toggleAddonBar"),

Instead, initialize them as simple _ fields in init().

+  init: function addonbar_init() {
+    // Share browser's palette.
+    let addonToolbox = document.getElementById("bottombox-toolbox");
+    let browserToolbox = document.getElementById("navigator-toolbox");
+    addonToolbox.palette = browserToolbox.palette;
+

1. This cannot work.  When we get it, the ctor at toolbar.xml was already dispatched, meaning that it already tried to set the toolbar's currentSet.  That won't work if it couldn't get the pallete on time.
2. And really, pallete isn't a property.
3. I'd add a new optional palleteid to the toolbar binding for that.

+    // Listen for add-ons being added or removed.
+    this.el.addEventListener("DOMNodeInserted", this, false);
+    this.el.addEventListener("DOMNodeRemoved", this, false);
+    

1. These handlers are pretty expensive. It would better to handle that in the callers.
2. nit: trailing spaces

+    // This is for first-run. Need to find out if there's a way to check
+    // if something is being restored from a persisted state or not.
+    //if (!AddonBar.el.hidden && !AddonBar.el.childNodes.length)
+      //AddonBar.toggle();
…
+    <toolbox id="bottombox-toolbox">
+      <toolbar id="addon-bar" class="toolbar-primary chromeclass-toolbar"
+               customizable="true" hidden="true" persist="hidden"/>

(etc.)

General note: you should rely on the current mechanism as much as you can. This is just another toolbar :)

diff --git a/browser/base/content/test/browser_pageInfo.js b/browser/base/content/test/browser_pageInfo.js
--- a/browser/base/content/test/browser_pageInfo.js
+++ b/browser/base/content/test/browser_pageInfo.js
@@ -15,26 +15,16 @@ function test() {
     if (topic != "page-info-dialog-loaded")
       return;
 
     switch (atTest) {
       case 0:
         atTest++;
         handlePageInfo();
         break;
-      case 1:
-        atTest++;
-        pageInfo = win;
-        testLockClick();
-        break;
-      case 2:
-        atTest++;
-        Services.obs.removeObserver(observer, "page-info-dialog-loaded");
-        testLockDoubleClick();
-        break;
     }

Don't switch.
Attachment #473679 - Flags: review?(mano) → review-
Attached patch v6 wip (obsolete) — Splinter Review
most of the changes. still need to finish integrating into the current toolbar persistence/visiblity code.

i'm not really ok with leaving the hiding/showing of the toolbar up to add-ons. but we can fix that as a followup.
Attachment #473679 - Attachment is obsolete: true
(In reply to comment #75)
> Created attachment 474157 [details] [diff] [review]
> v6 wip
> 
> most of the changes. still need to finish integrating into the current toolbar
> persistence/visiblity code.
> 
> i'm not really ok with leaving the hiding/showing of the toolbar up to add-ons.
> but we can fix that as a followup.

I don't get that. If they're using some api (jetpack?) to add the items - then you don't need the handler.  However, if they use simple overlays for that matter, then the handler won't help much.
Comment on attachment 474157 [details] [diff] [review]
v6 wip

ugh, forgot to ask r? last night. will be afk for a few hours (moving) but new patch on the persistence bits later today.
Attachment #474157 - Flags: review?
(In reply to comment #76)
> > i'm not really ok with leaving the hiding/showing of the toolbar up to add-ons.
> > but we can fix that as a followup.
> 
> I don't get that. If they're using some api (jetpack?) to add the items - then
> you don't need the handler.  However, if they use simple overlays for that
> matter, then the handler won't help much.

the supported ways of getting onto the addon bar should be:

1. via the add-on sdk (aka jetpack). if the user is using the built-in widget module, then sure we can toggle from there. but they might not be. anyone can modify those libs in their add-ons, or access direct from script or whatever.

2. adding a toolbar button from script, like in the status quo. this makes migration easy for current add-ons that don't switch to the add-on sdk, and also allows us to detect install/uninstall.

we want to reduce the complexity for add-on authors as much as possible, to make it "just work", and that's eminently doable IMO. making this hide/show interaction the responsibility of every add-on dev is sure to fail.
Comment on attachment 474157 [details] [diff] [review]
v6 wip


>+                    <menuitem id="menu_toggleAddonBar"
>+                              label="&addonBarCmd.label;"
>+                              accesskey="&addonBarCmd.accesskey;"
>+                              type="checkbox"
>+                              command="cmd_toggleAddonBar"

>+                              persist="true"/>

What's that?

By the way, did you see my question about moving this to view->toolbars?

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>+  // Until Mano adds paletteId to toolbars...

It's not a followup! toolbar construction cannot work if the palette isn't set on time (i.e. the toolbar customized contents won't persist between browsers sessions).

>+  let addonBarMenu = document.getElementId("menu_toggleAddonBar");
>+  let addonBar = document.getElementId("addon-bar");
>+  addonBarMenu.setAttribute("checked", addonBar.getAttribute("hidden") != "true");

But this code has nothing to do with my suggested api... It was my reply to:

>+    // Share browser's palette.
>+    let addonToolbox = document.getElementById("bottombox-toolbox");
>+    let browserToolbox = document.getElementById("navigator-toolbox");
>+    addonToolbox.palette = browserToolbox.palette;

So, to clarify: this *might* work for the current browser session, but when the toolbar is rebuilt by toolbar.xml, it won't have access to its palette, and therefore it won't be able to restore buttons from that palette.

>diff --git a/browser/components/sessionstore/src/nsSessionStore.js b/browser/components/sessionstore/src/nsSessionStore.js

> const WINDOW_ATTRIBUTES = ["width", "height", "screenX", "screenY", "sizemode"];
> 
> /* 
> Hideable window features to (re)store
> Restored in restoreWindowFeatures()
> */
> const WINDOW_HIDEABLE_FEATURES = [
>   "menubar", "toolbar", "locationbar", 
>-  "personalbar", "statusbar", "scrollbars"
>+  "personalbar", "scrollbars"

I don't think you should do that.  The statusbar window-feature itself is still supported (affects chromehidden etc) and an extension might honor it.
Oh, sorry, you did move it to view->toolbars. However, you're still using your own "system" for that.  Please see the code in onViewToolbarsPopupShowing and make it handle the new toolbox.
Attachment #474157 - Flags: review? → review-
(In reply to comment #73)
> Smaug, is that also the case with these mutation events?

Yes. Any mutation event listener in a document slows down all the dom
changes *significantly* in that document.
Attached patch something like this (obsolete) — Splinter Review
Unfortunately the paletteid trick I suggest won't work. The palette element is removed when the first toolbox is constructed.

Instead, I've implemented here some basic support for "external toolbars" in toolbox. With this patch, you can set the "toolboxid" attribute on any toolbar to make it part of any toolbox within its document - "part of" as far as toolbar.xml and toolbar customization are concerned. I've tested this a bit.

Again, this is a requirement for customizable-items persistence on the addon-toolbar to work.
About hiding and unhiding: You could probably do so without my "normalization" work, and you could sure do so now: Please use setToolbarVisibility and onViewToolbarCommand for managing the toolbar state - The former takes care of persisting the toolbar collapsed (collapsed, not hidden) state.
About auto-show mechanism (mutation events): How do current addons add items to the toolbar not through the palette? I believe they're already required to do some manual work like persisting currentSet (we do so only after toolbar customization as far as I can tell).
(In reply to comment #79)
> >+  // Until Mano adds paletteId to toolbars...
> 
> It's not a followup! toolbar construction cannot work if the palette isn't set
> on time (i.e. the toolbar customized contents won't persist between browsers
> sessions).

fyi, jetpack widgets are dynamically added at each startup at this point. getting persistence working for them is not yet implemented. suggestions on approaches for persistence for late-added items would be great.
Attached patch v6 (obsolete) — Splinter Review
fixed existing toolbar visibility/persistence mechanisms to support both toolboxes, and other fixes to mano comments.

still working on the test.
Attachment #474157 - Attachment is obsolete: true
Attachment #474734 - Flags: review?(mano)
(In reply to comment #82)
> Created attachment 474372 [details] [diff] [review]
> something like this
> 
> Unfortunately the paletteid trick I suggest won't work. The palette element is
> removed when the first toolbox is constructed.
> 
> Instead, I've implemented here some basic support for "external toolbars" in
> toolbox. With this patch, you can set the "toolboxid" attribute on any toolbar
> to make it part of any toolbox within its document - "part of" as far as
> toolbar.xml and toolbar customization are concerned. I've tested this a bit.
> 
> Again, this is a requirement for customizable-items persistence on the
> addon-toolbar to work.

awesome, thanks for whipping that up! can you push this into a separate bug?
I can, but you'll need this for the final patch either way, imo.
Depends on: 595937
The patch is attached on bug 595937.
(In reply to comment #86)
> (In reply to comment #79)
> > >+  // Until Mano adds paletteId to toolbars...
> > 
> > It's not a followup! toolbar construction cannot work if the palette isn't set
> > on time (i.e. the toolbar customized contents won't persist between browsers
> > sessions).
> 
> fyi, jetpack widgets are dynamically added at each startup at this point.
> getting persistence working for them is not yet implemented. suggestions on
> approaches for persistence for late-added items would be great.

I would check how we persist custom user toolbars (toolbars added by "add new toolbar") and do it the same way.
pushed to the tryserver.
(In reply to comment #92)
> pushed to the tryserver.

I hope you'll post the tryserver builds here so I can try them!
Attached patch v7 (obsolete) — Splinter Review
* updates to mano's customization changes
* adds toolbar context menu to add-on bar
Attachment #474734 - Attachment is obsolete: true
Attachment #474815 - Flags: review?(mano)
Attachment #474734 - Flags: review?(mano)
Comment on attachment 474815 [details] [diff] [review]
v7

r=mano
Attachment #474815 - Flags: review?(mano) → review+
Attached patch v7.1 (obsolete) — Splinter Review
minor changes, and finished the test, carrying review over. will check-in once i get try results back for this latest patch.
Attachment #474815 - Attachment is obsolete: true
Attachment #475037 - Flags: review+
(In reply to comment #96)
> will check-in once i get try results back for this latest patch.

correction - need to get the bugs that block this landed first.

also, the new test failed on try, even though it passes locally. not my favorite game.
Whiteboard: [strings][has WIP patch] → [strings][has review][failing test on try]
for those asking, tryserver builds show up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/?C=M;O=D
Attached patch v7.2 (obsolete) — Splinter Review
* fixes addon bar test to work on tinderbox machines (slooooowwww)
* fixes private browsing popup blocker test
Attachment #475037 - Attachment is obsolete: true
latest patch looks ok on try, a couple of unrelated known oranges (neither of which fail locally).
Whiteboard: [strings][has review][failing test on try] → [strings][has review][waiting on dependencies to land]
It is time to ask for r+ ?
Perhaps this bug could be marked for documentation since it will break a great many add-ons when it lands?
> Perhaps this bug could be marked for documentation since it will break a great
> many add-ons when it lands?
John, you know you can do this yourself right?
Keywords: dev-doc-needed
(In reply to comment #103)
> John, you know you can do this yourself right?

Can != should; I dislike being slammed for guessing the wrong funky flag.
Attached patch v7.2 updated to tip (obsolete) — Splinter Review
Attachment #475113 - Attachment is obsolete: true
Attachment #475492 - Flags: review+
Here's a restartless add-on that exposes itself in the new bar. See bootstrap.js for the relevant code and documentation.

If you use the widget API in the Add-on SDK you wouldn't need to know of the existence of XPCOM, nor do a lot of the stuff that's manually done here.

The bug for updating the widget module to work with this final add-on bar implementation is bug 596202, which should ship in the 0.8 release of the SDK.

I'll put together a blog post that details the migration options for current status add-ons before we ship this beta.
And what about old non-jetpack addons? Will they show up on addons-bar?
(In reply to comment #107)
> And what about old non-jetpack addons? Will they show up on addons-bar?

No. There's not a reasonable way to do that. I tried experimenting with migrating them automatically, but the statusbar addons I tested with from AMO each referred directly to the status-bar element repeatedly.

The migration is really easy for current statusbar add-ons... which all have to release new versions *anyway*, if only to update their install.rdf file for the new Firefox version.
(In reply to comment #108)
> (In reply to comment #107)
> > And what about old non-jetpack addons? Will they show up on addons-bar?
> 
> The migration is really easy for current statusbar add-ons... which all have to
> release new versions *anyway*, if only to update their install.rdf file for the
> new Firefox version.

Most addons support multiple versions of Firefox. And we have no idea what is involved in 'really easy'.

jjb
(In reply to comment #109)
> Most addons support multiple versions of Firefox. And we have no idea what is
> involved in 'really easy'.

this patch replaces a <statusbar> with a <toolbar>. toolbar programming in Firefox is pretty well-trodden ground.

but there are definitely some differences from status bars, where you just use the DOM alone.

take a look at the add-on i just uploaded. it's got two files, install.rdf and bootstrap.js, so you should be able to find the code pretty easily. the summary of what most statusbar addon authors will need to do is in there  in one function. if the main code of an add-on is in a javascript file loaded via overlay (like most currently do), then the scenario is slightly different, and  is less complicated.

i'll detail the various migration approaches in a blog post, as i already said.
(In reply to comment #106)
> Created attachment 475545 [details]
> example add-on (non-jetpack)

I installed your build from tryserver. I installed you example addon. Nothing showed up on the addons bar. BTW, on the Options... were two Add-on bar menu... :S I checked both of em, nothing showed up. I tried every combination, nothing.
That was a bug in an earlier version of the patch. I'll kick off a build with the latest version.
Thanks! This addons bar always will present on the whole width of the window? If yes, there is no reason to replace status bar with it. I guess not, but how will it work? Like Boriss's mockups? 

http://jboriss.files.wordpress.com/2010/06/third_growing_statubar.png
(In reply to comment #113)
> Thanks! This addons bar always will present on the whole width of the window?
> If yes, there is no reason to replace status bar with it. I guess not, but how
> will it work? Like Boriss's mockups? 
> 
> http://jboriss.files.wordpress.com/2010/06/third_growing_statubar.png

That's unlikely, see <http://jboriss.wordpress.com/2010/06/16/removing-firefox%E2%80%99s-status-bar-and-rehousing-add-on-icons-part-3-of-2-wut/#comment-1951>.
Indeed, i remember, thx.

Then what about the addons bar? If it is like the new statusbar, the whole rehousing has no point. (the content area's height didnt increased)
(In reply to comment #115)
> Then what about the addons bar? If it is like the new statusbar, the whole
> rehousing has no point. (the content area's height didnt increased)

It's a toolbar, which means it can be customized by users. The statusbar doesn't allow any customization. We might not get full integration into the customization palette and navigator-toolbox in this release, but this lays the basic foundation for it. We'd rather make this breaking change now, when releasing a major version and making lots of other breaking changes.
landed: http://hg.mozilla.org/mozilla-central/rev/bb2db707bfcb

keeping this open while i watch the tree.
Whiteboard: [strings][has review][waiting on dependencies to land] → [strings][landed, baking]
test is failing (popupshown listener isn't being called), but passes locally. will try to figure it out, and backout otherwise.
Depends on: 596913
Do you really want to force all addon devs who placed an icon in the status bar to make an update to have their icons placed in the addon bar instead? So late in the process when many addons have been updated to be compatible for 4.0 already?

And where will the icons be in the meantime, until addon devs updated them? Gone? Minefield will become quite unusable because of this change, if it is really planned like this.

Isn't it possible to get all icons that would be placed in the status bar to be available in the addon bar automatically?

(Personally I don't get it why status bars - same applies to the menu bar BTW - have become a bad thing all of the sudden ... only because other browsers made stupid changes, Firefox has to make them too?)
(In reply to comment #121)
> Do you really want to force all addon devs who placed an icon in the status bar
> to make an update to have their icons placed in the addon bar instead? So late
> in the process when many addons have been updated to be compatible for 4.0
> already?
> 
> And where will the icons be in the meantime, until addon devs updated them?
> Gone? Minefield will become quite unusable because of this change, if it is
> really planned like this.
> 
> Isn't it possible to get all icons that would be placed in the status bar to be
> available in the addon bar automatically?
> 
> (Personally I don't get it why status bars - same applies to the menu bar BTW -
> have become a bad thing all of the sudden ... only because other browsers made
> stupid changes, Firefox has to make them too?)

This is what bleeding edge technology is about. To cite that things break isn't an adequte argument. Addon developers have been warned in advance about this change coming. Many other addon devs didn't get that opportunity for some changes that broke their addon usability completely. There are resources to assist addon developers in place.

Regarding getting addons converted from status bar to addon bar automatically see comment 108
This breaks even addons that have the option to place it elsewhere.  I placed the latest dev version of Forecastfox in the Navigation bar, and when I updated to an hourly with this still in, it (ForecastFox) disappeared even from the Nav-bar.
(In reply to comment #120)
> http://forums.mozillazine.org/viewtopic.php?p=9897029#p9897029

Thanks, that's definitely broken.
(In reply to comment #123)
> This breaks even addons that have the option to place it elsewhere.  I placed
> the latest dev version of Forecastfox in the Navigation bar, and when I updated
> to an hourly with this still in, it (ForecastFox) disappeared even from the
> Nav-bar.

Thanks for reporting this! I'll figure out what's going on there before relanding.
Can we just put a non-removable <statusbar id="status-bar"/> on the add-on bar to ease the transition for add-ons?
(In reply to comment #125)
> Can we just put a non-removable <statusbar id="status-bar"/> on the add-on bar
> to ease the transition for add-ons?

When would we remove it? Why would add-ons ever stop using it? It doesn't help users at all - they're still stuck with add-ons in the bar that they can't move or disable.

The XUL changes are not difficult. And we're at the breakingest place we've been, or are going to be, for years. There's never a good time to make breaking changes, but this is about the best it's going to get.
(In reply to comment #121)
> (Personally I don't get it why status bars ... have become a bad thing
> all of the sudden ... only because other browsers made
> stupid changes, Firefox has to make them too?

If anyone thought the status bar was a bad place for add-ons, I certainly wouldn't staying up nights to make it's replacement.

The statusbar is being replaced with a toolbar in the same place, that allows add-ons to be more customizable by the user.
(In reply to comment #126)
> > Can we just put a non-removable <statusbar id="status-bar"/> on the add-on bar
> > to ease the transition for add-ons?
> 
> When would we remove it? Why would add-ons ever stop using it?

When enough add-ons migrated -- which may be never, but I don't necessarily see this as a problem.

> It doesn't help
> users at all - they're still stuck with add-ons in the bar that they can't move
> or disable.

Annoying add-on authors enough to drop their add-ons doesn't help users either.

> The XUL changes are not difficult.

Customizable elements necessarily add complexity to code that currently assumes that the elements are always there. It's very often not going to be just a trivial XUL change. In fact, a XUL change will never enough if you want the customizable element to be in the UI as soon as the user installs the add-on.

> And we're at the breakingest place we've
> been, or are going to be, for years. There's never a good time to make breaking
> changes, but this is about the best it's going to get.

I don't see a compelling reason to break things here at all. If an add-on doesn't want customizable elements, so be it. If users care enough about being able to move things around they'll complain to the authors or move to an add-on that offers this. We don't need to enforce this, just provide the tools.
Let's keep this bug about the technical issues, not whether you care about customizability, or think this change is worth the cost or not. I posted and answered Dao's message on DAF, where the debate belongs:

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9f91bd1618339b6a#
Whiteboard: [strings][landed, baking] → [strings][re-opened, test failures]
This is NOT a Normal bug:  "some loss of functionality under specific circumstances".  This is clearly an RFE:  "Request for enhancement".  

One "feature" of this RFE is the elimination of the lock icon that indicates whether a page is begin viewed in secure mode.  Thus, all those Web pages that tell us to look for the icon being locked (not open) will have to be rewritten.  What steps will be taken to inform Web developers that they must rewrite such advice?
this is a major version change. if a addon dev thinks he/she should address an id not longer available, it is his/her fault that the browser breaks. only hiding the bar is a step in the wrong direction, since there sure will be zombie effects of it crawling out of its grave.

that said i don’t want two places for my addon buttons anymore. it should be completely the user’s choice where and in which order the buttons appear. it was a major WTF for me to learn that these little icons down there could not be dragged and dropped like their bigger counterparts elsewhere.

in short: let the old bar die and movable addon buttons. they can be in the addon bar per default, but i want to drag them elsewhere if i want to like every other ui element.
(In reply to comment #112)
> That was a bug in an earlier version of the patch. I'll kick off a build with
> the latest version.

Have you done the new build with the latest version yet? If not, will you do it soon and post it here so we can try it please? I would really appreciate it!
Depends on: 597155
For anyone who actually reads this comment, now doomed to be lost in the noise:

The new addon bar is basically just a super status bar, but new and not old.

Addons will need to be updated by their developers to handle this just like the oh so many other things which have broken stuff on the road to Firefox 4.0 final. Trust me, I'm the developer of Flagfox and I'll need to update to handle this too, just like the many other things that broke addons, including another one just recently (big time; full breakage from extractionless XPI installation). It has to be done; please don't whine about it.


(In reply to Dão Gottwald in comment #125)
> Can we just put a non-removable <statusbar id="status-bar"/> on the add-on bar
> to ease the transition for add-ons?

Please, no compatibility hacks. The status bar is getting a nice overhaul here, and while the transition will take effort on the part of extension developers like myself, I'd much rather have a clean break here. The "status-bar" ID really needs to be completely gone forever or it'll just make the transition harder and messier. Extensions will need updates. It's best to make them crystal clear.

For what it's worth, part of the heightened sense of fear coming from people about changes came from a naming issue for the Firefox 4.0 development cycle. Generally speaking, the word "alpha" refers to development releases with more big changes to come and the word "beta" refers to development versions that are feature complete. Firefox 4.0 had some alphas before the version bump from 3.7, but all betas up until the 7th (unless there's another delay) are really alphas, technically speaking. If we get precise, Firefox 4.0 hasn't had its real first beta yet. That's why it ~feels~ like the rug is being pulled out from under some people, though it really isn't. All of this was planed and stated in advance. The naming and number of beta testers is just confusing the situation. (though this is off-topic)
That means we can put the addons icon to everywhere with the new addons bar compatible addons?

I'm sad that the flying-in addons bar is dropped. :(
Dave, Dietrich started a newsgroup discussion to keep this bug useful, so as much as I'd like to respond to some of your arguments, I can't.
Sorry for the spam, I can imagine the CC list on this bug is getting big.

When this code lands, will there still be the ability to develop an addon that replaces the core browser functionality of the status bar? That is, does the patch for this bug remove just the statusbar chrome or all its supporting code as well?

I'd like to think that it would be easy, using an addon, to regain a status bar that shows me page load progress, link URLs, and maybe download progress. But I imagine that some of that stuff like the page load progress is pretty low-level. If this isn't the case, can anything be done in that regard? I'm not a C programmer so I wouldn't know where to look in the code, or what sort of enhancement bug to file.
(In reply to comment #135)
> Dave, Dietrich started a newsgroup discussion to keep this bug useful, so as
> much as I'd like to respond to some of your arguments, I can't.

I've braved the group discussion just for you to reply to me.
> When this code lands, will there still be the ability to develop an addon that
> replaces the core browser functionality of the status bar? That is, does the
> patch for this bug remove just the statusbar chrome or all its supporting code
> as well?

Looking at attachment 475492 [details] [diff] [review], it is all front end stuff (js/xul/xml/css) so it should be doable as an extension. Just look at the patch and look for lines that have a "-" in the first column. These are removed lines. An extension could theoretically add back the functionality removed in this patch.
When this is going to land again? I want to test it and start adjusting my extensions for the next beta release.
Maybe you can try in a tryserver build if Dietrich makes one. He mentioned that, but there is still only the buggy build.
(In reply to comment #140)
> Maybe you can try in a tryserver build if Dietrich makes one. He mentioned
> that, but there is still only the buggy build.

Thanks. I got it from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dietrich@mozilla.com-7f8d49960c4a/
According to the date, there are the new bug-free builds there. I dunno, i wont try them just in trunk.
The Addons bar is huge! Anyone knows if this will be the final design?
Ah, yes!(In reply to comment #143)
> The Addons bar is huge! Anyone knows if this will be the final design?

Ah, yes! But I can't find my add-ons icons in it! Can you?
(In reply to comment #144)
> Ah, yes!(In reply to comment #143)
> > The Addons bar is huge! Anyone knows if this will be the final design?
> 
> Ah, yes! But I can't find my add-ons icons in it! Can you?

Just to make a troll ? => https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Thanks to keep constructive ;-)
Haven't seen this mentioned here:

What will happen to the status messages currently displayed in the status bar (Wsiting/Transfering/Reading/etc from somesite.com)? Will this stuff be removed or relocated elsewhere? 

The information is quite useful when visiting pages containing a lot of AJAX stuff as it is the only way to tell if you are actually loading any new stuff from the server.
(In reply to comment #146)
> Haven't seen this mentioned here:
> 
> What will happen to the status messages currently displayed in the status bar
> (Wsiting/Transfering/Reading/etc from somesite.com)? Will this stuff be removed
> or relocated elsewhere? 
> 
> The information is quite useful when visiting pages containing a lot of AJAX
> stuff as it is the only way to tell if you are actually loading any new stuff
> from the server.

It is useful also for that users (like me :-() that use HSDPA connection. My connection is not stable and often drops without any notification. So I check continuosly the status bar to see if the page is loading or the browser is waiting for connection etc...
I'm totally in favour of removing the status bar, but I hope that this kind of information can remain in some part of primary UI, maybe in the same way of Chrome.
I suggest adding a 16x16px colored dot, which will indicate the current state with it's color (yellow orange red green blue), and if you hover it - a tooltip should be shown, where the current state should be written in plain text.
Can someone who is using the tryserver build please post a screenshot of what
this looks like.
It looks like just like the old statusbar, but little bit higher, and it's a customizable toolbar. hhttp://tinyurl.com/3xxs63m

Dietrich: Why is it higher? The whole Fx 4 UI's one of most important goals is to reduce chrome and get more space for content.
Sorry, my first image get totally screwed up...

http://i55.tinypic.com/1znllpy.png
This is how it looks in Linux, with small icons:

http://tinyurl.com/2ayd7tw

This is how it looks with large icons:

http://tinyurl.com/2f2mzfk
For future reference, to prevent pics from getting lost, could you guys attach the graphics (preferably in the form of PNGS) directly to this bug via the "Add an Attachment" link near the top of this page?
> This is how it looks in Linux, with small icons:
You can turn off the text, you know. In fact that should be the default.
Thanks folks, nice to finally see the thing. Is the styling set? I'm thinking it should be right aligned? Will users be able to set the height? I don't necessarily feel that icons need to be larger than 16px high but understand it differs from user to user? Also is there a chance that we could get a glass effect on there? Perhaps the colour of inactive tabs?
(In reply to comment #154)
> > This is how it looks in Linux, with small icons:
> You can turn off the text, you know. In fact that should be the default.

There is bug. It was already set as icon without text, but the text was still being displayed. When I selected an option with text and went back to icons only, then the text disappeared.
(In reply to comment #145)
> (In reply to comment #144)
> > Ah, yes!(In reply to comment #143)
> > > The Addons bar is huge! Anyone knows if this will be the final design?
> > 
> > Ah, yes! But I can't find my add-ons icons in it! Can you?
> 
> Just to make a troll ? =>
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> Thanks to keep constructive ;-)

I'm very sorry, I didn't mean any disrespect nor any pointless comment. I've found how to make the icons appear now! Thanks! :)
Wait, I don't get it. Status bar is removed, replaced by an even bigger bar, and there is still not enough place to display target URL in that bar? Why not display target URL in add-on bar? That would solve all the problems.
(In reply to comment #160)
> Why not display target URL in add-on bar? That would solve all the problems.

Right for some people there. It could be implemented by an addon ;-)
Depends on: 597949
(In reply to comment #156)
> Thanks folks, nice to finally see the thing. Is the styling set?
> is there a chance that we could get a glass effect on there? Perhaps the
> colour of inactive tabs?

That's bug 597949 ;-)
(In reply to comment #161)
> (In reply to comment #160)
> > Why not display target URL in add-on bar? That would solve all the problems.
> 
> Right for some people there. It could be implemented by an addon ;-)

Ummm, you can't really expect a security hole to be fixed by add-on. This is something that should be enabled by default. People who don't care what happens when they click the link could disable it if they want this extra security risk.
(In reply to comment #160)
> Wait, I don't get it. Status bar is removed, replaced by an even bigger bar,
> and there is still not enough place to display target URL in that bar? Why not
> display target URL in add-on bar? That would solve all the problems.
The target URL is already displayed in the location bar : #587908
(In reply to comment #164)
> The target URL is already displayed in the location bar : #587908

There is not enough space in the location bar to display most URLs (especially on small screens). It is possible to make malicious url look like a normal url so that they look the same in the shortened form. There should be a dedicated space to display target URLs, and location bar should not be this place.
Please read the dependencies of that bug, and take the hover target URL display conservation to those bugs. Thanks.
(In reply to comment #165)
> (In reply to comment #164)
> > The target URL is already displayed in the location bar : #587908
> 
> There is not enough space in the location bar to display most URLs (especially
> on small screens). It is possible to make malicious url look like a normal url
> so that they look the same in the shortened form. There should be a dedicated
> space to display target URLs, and location bar should not be this place.

Which is why I'm so against having the link space fixed, which bug 597930 proposes. I don't have the search bar displayed and only have Test Pilot, Download and Sync (temporarily until this addon bar lands) to the right of the location bar and in some cases the hover url still touches/overlaps the current url. However I'm not able to be eloquent enough to put forward a good enough case against the proposal.

That said, the argument for small screens isn't one that people can keep banding around. They do not make up the vast majority of monitors and the case for disposing of the status bar was to accommodate said small monitor/netbook people who felt that they weren't adequately catered for. Or so was my perception of the driving of this change, which I feel is a good one.
This idea was dropped because many pages uses the bottom-right area.

http://jboriss.files.wordpress.com/2010/06/fourth_series.png

But what about if we place that into the bottom-left corner?

It's familiar to the users, at least who uses Windows. The Windows Start menu is located in the bottom-left corner, too.
Blocks: 597949
No longer depends on: 597949
Attached patch v8 wip (obsolete) — Splinter Review
v8: contains windows fix (comment #120), test fixes and the statusbar compatibility shim. i pushed to the tryserver.

todo:

* remove elusive border-top styling in embedded statusbar

* default size: right now it's tied to whatever the current toolbar mode is. however, we probably want icons only in small mode as the default.
Attachment #474372 - Attachment is obsolete: true
Attachment #474373 - Attachment is obsolete: true
Attachment #475492 - Attachment is obsolete: true
Whiteboard: [strings][re-opened, test failures] → [strings][patch in progress, waiting on try results]
(In reply to comment #169)
> * default size: right now it's tied to whatever the current toolbar mode is.
> however, we probably want icons only in small mode as the default.

Yes please, could we limit the height of the Addon Bar to 18px as per the previous status bar?
(In reply to comment #169)> * default size: right now it's tied to whatever the current toolbar mode is.> however, we probably want icons only in small mode as the default.Not only as the default, it should be locked like it is for the bookmarks toolbar. Most users will want to toggle large/small icons for the navigation toolbar, which shouldn't affect the add-on bar.
Err can't the size/mode for each toolbar be set individually, independent of the nav-bar? I thought someone backported this functionality from SeaMonkey for use in the bookmarks toolbar.
(In reply to comment #172)
> Err can't the size/mode for each toolbar be set individually, independent of
> the nav-bar?

Depends on what you're asking really. We don't have UI for that.
> Depends on what you're asking really. We don't have UI for that.
Oh um, you could backport that bit from SeaMonkey as well :D .
(In reply to comment #171)> (In reply to comment #169)> * default size: right now it's tied to whatever the> current toolbar mode is.> however, we probably want icons only in small mode as> the default.Not only as the default, it should be locked like it is for the> bookmarks toolbar. Most users will want to toggle large/small icons for the> navigation toolbar, which shouldn't affect the add-on bar.Ok, I'll lock it for now. We want to be able to enable big/small size for the Add-on bar, but it doesn't need to block this bug.
Attached patch v8 (obsolete) — Splinter Review
* lock height, set mode defaults (none of those attributes documented, wtf?!)
* fix styling of statusbarpanel children of the embedded statusbar

the bar is still subject to changes to the nav toolbar mode, so i still need to figure that bit out, but can do it in a followup.

tryserver results ok for mac and linux, waiting on windows still.
Attachment #477105 - Attachment is obsolete: true
Attachment #477139 - Flags: review?
Attachment #477139 - Flags: review? → review?(mano)
I tried the newest tryserver win32 build:

If I move a button from the palette to the addons bar, it'll be displayed with label. But i have the setting to show just the icons. If i set the palette to show labels, and then set to show the icons only, addons bar will display it with only icon, correctly.

Other problem: if i install your example addon, it doesnt show up on the addons bar, ever.

And addons bar default height is still too high, i guess.

I tried with fresh profile.


Any reactions to comment 168?
Attached image screenshot
here's a screenshot on linux, with Dao's dictionary add-on, and the sync toolbar button that i dragged there from the palette.
Attached image screenshot on Windows
Screenshot on Windows, with Dao's dictionary addon and Sync toolbar button dragged from palette.
Attachment #476642 - Attachment is obsolete: true
Comment on attachment 477155 [details]
screenshot on Windows

eewww. ok, clearly my css changes did not work across platforms!
What changes? What we should see?

Any reactions to comment 177? I met some problems with addons bar on Win.
(In reply to comment #181)
> What changes? What we should see?

depends. what build did you test?
 
> Any reactions to comment 177? I met some problems with addons bar on Win.

i'm looking into this now.
(In reply to comment #182)
>
> depends. what build did you test?

Your latest win32 tryserver builds.
Whiteboard: [strings][patch in progress, waiting on try results] → [strings][patch in progress, waiting on try results][ETA: 9/22]
(In reply to comment #168)> This idea was dropped because many pages uses the bottom-right area.> > http://jboriss.files.wordpress.com/2010/06/fourth_series.png> > But what about if we place that into the bottom-left corner?> > It's familiar to the users, at least who uses Windows. The Windows Start menu> is located in the bottom-left corner, too.Taking up a portion of the bottom-left of the screen was floated around as an idea, but it is not something I (or the rest of UX) would endorse in an actual product.  Sure, this would technically take up less of the content area, but what you're left with is an asymmetrical browsing area.  This creates huge problems for web developers and designer because the corners of many websites are prime real estate, often used for menus, preferences, extra information, login information, etc.  With the main body of web sites usually devoted to content, it's the edges and corners that often supply extra information.  Masking a portion of a corner or edge would disrupt the functionality in any site using this area.  Temporarily using this area, as Chome does with the user mouses over a link, would be less of a problem.  But permanently taking this area in Firefox would cause too much of a disruption.
(In reply to comment #185)
> (In reply to comment #168)> This idea was dropped because many pages uses the
> bottom-right area.> >
> http://jboriss.files.wordpress.com/2010/06/fourth_series.png> > But what about
> if we place that into the bottom-left corner?> > It's familiar to the users, at
> least who uses Windows.

I'm Windows users and I don't care where it is. The fuction is important, not placement.
(In reply to comment #186)
> (In reply to comment #185)
> > (In reply to comment #168)> This idea was dropped because many pages uses the
> > bottom-right area.> >
> > http://jboriss.files.wordpress.com/2010/06/fourth_series.png> > But what about
> > if we place that into the bottom-left corner?> > It's familiar to the users, at
> > least who uses Windows.
> 
> I'm Windows users and I don't care where it is. The fuction is important, not
> placement.

What are you petitioning for? The ability to show/hide with a single click?
What makes you think I'm petitioning for anything?
(In reply to comment #185)

Thanks for your detailed answer, Boriss!
Anyway, we should add the ability to hide and unhide the addons bar easily, so the user can get more vertical space when he/she needs it. I think setting a keyboard shortcut for hiding/unhiding the addons bar is a good idea.
(In reply to comment #189)
> (In reply to comment #185)
> 
> Thanks for your detailed answer, Boriss!
> Anyway, we should add the ability to hide and unhide the addons bar easily, so
> the user can get more vertical space when he/she needs it. I think setting a
> keyboard shortcut for hiding/unhiding the addons bar is a good idea.

Why not almost just like the dead-notification bar, but on the bottom.
It could be bottom wide and 2-3 pixels hight (just like a border for being discoverable by the user). Then on mouse hover or activity (of an addon) it could animate to get a normal hight.

Maybe we should separate mouse hover/activity :
On mouse hover : make the addon bar overflow the content.
On acitvity : To avoid taking place over the content at un unpredictable time and for un unknow time, the bar could resize-less the content area (when it is in full hight).
Maybe a timer or something will be needed to avoid seing the addon bar flashing (bumping in EN ?).

Jennifer is that something that the UI and UX teams had thought ?
It was occurred to me, too, but these hover and flying-in things are always has disadvantages. Anyway, if the UX team can figure out a proper way to do it, it would be great.

BTW, ETA is tomorrow, i dunno if it is related to other polishing or not, but there are not much time left.
(In reply to comment #191)
> BTW, ETA is tomorrow, i dunno if it is related to other polishing or not, but
> there are not much time left.

Does that means it will be included in the Beta 7 release?
It will be, it's a beta7 blocker.
(In reply to comment #190)
> Why not almost just like the dead-notification bar, but on the bottom.
> It could be bottom wide and 2-3 pixels hight (just like a border for being
> discoverable by the user). Then on mouse hover or activity (of an addon) it
> could animate to get a normal hight.

Hover doesn't work, especially on the bottom edge, since that's where the default position of the task switcher on Windows is. There's no real edge there in the Fitts' Law sense.

In general, having things appear when you move your mouse over them is something we're trying to avoid.
And what about the keyboard shortcut, what i already mentioned? That doesnt conflict with anything.
Update: wrestling with CSS on Windows, where I'm unable to override the border styles on embedded statusbarpanel elements for some reason.
It had occurred to me that Ctrl-Space would have been the perfect shortcut for this if it hadn't already been taken by Panorama!  I definitely feel it should be near the bottom of the keyboard to mirror it's location on the browser.  Ctrl-/ might be good... as it's the "last" key in a standard keyboard.
(In reply to comment #197)
> It had occurred to me that Ctrl-Space would have been the perfect shortcut for
> this if it hadn't already been taken by Panorama!  I definitely feel it should
> be near the bottom of the keyboard to mirror it's location on the browser. 
> Ctrl-/ might be good... as it's the "last" key in a standard keyboard.

Only in your US-centric world. ;)
(I don't think there was a sign to begin discussing keyboard shortcuts, so no-one should spam this bug.)
I have an idea: make the add-on bar semi-transparent (with the webpage content behind it). Then it would seem to take less space visually. The only problem I see is when you scroll to the bottom, and add-on bar still obscures some webpage element that you need to click. Also it would block these annoying "toolbars" that some sites use (which might be good or bad, depending on your preference). Maybe an option?
I think it would be very annoying. With the many colorful addon icons on it, and under the web content... It would look ugly, and would be useless.
(In reply to comment #196)
> Update: wrestling with CSS on Windows, where I'm unable to override the border
> styles on embedded statusbarpanel elements for some reason.

You could leave that to a follow-up bug.
fixes styling of embedded statusbar (and children) on mac and windows. mac is still not vertically centered correctly, but i'll deal with that in a followup.
Attachment #477139 - Attachment is obsolete: true
Attachment #477590 - Flags: review?(mano)
Attachment #477139 - Flags: review?(mano)
forgot to update whiteboard: mochitest other on tryserver looked fine.
Whiteboard: [strings][patch in progress, waiting on try results][ETA: 9/22] → [strings][needs review mano][ETA: 9/22]
I recently had Internet connectivity problems that afflicted not only my browser but all my other Internet applications.  To help diagnose the problems, my ISP asked me to provide the information that I saw in the status bar as I attempted (unsuccessfully) to view a particular Web page.  The ISP was especially interested in how long it took to lookup a domain and at what point the browser stopped (which was "Waiting").  

When the status bar is replaced, where would I find such information?
the web console is the best point for looking up such information.
*after you open it*, it starts showing all http traffic (afaik, maybe it dos more). you open it by pressing ctrl+shift+k

furthermore, i’m reading about a “embedded statusbar” does that mean there is still a <statusbar>-zombie floating around?
Comment on attachment 477590 [details] [diff] [review]
v8.1
[Checked in: See comment 209+234]

r=mano. I'll file any follow ups as needed.
Attachment #477590 - Flags: review?(mano) → review+
Comment on attachment 477590 [details] [diff] [review]
v8.1
[Checked in: See comment 209+234]

>+/* Remove the resizer from the statusbar compatibility shim */
>+#addon-bar .statusbar-resizerpanel {
>+  display: none;
>+}

This looks like it should be #status-bar > .statusbar-resizerpanel
http://hg.mozilla.org/mozilla-central/rev/eec9a82ad740

fixed Dao's comment before checkin.
Whiteboard: [strings][needs review mano][ETA: 9/22] → [strings][landed, baking]
some followups:

* bar is collapsed by default. need to show it if there are child elements of statusbar. maybe do this on window load for now, instead of the mutation event approach i had before?

* statusbar positioning on mac is off
The test timed out on win debug, even though it's passing on Windows locally.

However, I found that the Toolbar submenu doesn't populate on every *second* time, so going to fix that, and see if it fixes the test on the windows tinderbox.
Click it again. It's wrong in every second Options arrow click. Interesting.
> > http://forums.mozillazine.org/viewtopic.php?p=9897029#p9897029
> 
> still happens.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1285234271/

pal-moz, does it happen on first access? or just alternating like is said above.
followup to fix windows. landing to see if it fixes the test bustage. will get post-facto review from mano.
Attachment #477886 - Flags: review?(mano)
(In reply to comment #214)
> > > http://forums.mozillazine.org/viewtopic.php?p=9897029#p9897029
> > 
> > still happens.
> > 
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1285234271/
> 
> pal-moz, does it happen on first access? or just alternating like is said
> above.

OK : "G" (Good)
NG : "B" (Bad)

1st access, 2nd access,3rd ,......
G,B,G,B,G,B,G,B,G,B....

fine on odd number time,
bad on even number time.
Attached image Linux borders
On Linux, the top border of the addons bar is light colored and the bottom border is dark. This seems to be exactly the opposite of what we need (see screenshot to compare to top toolbars)
in adittin to comment #217

Error in error console:

Error: uncaught exception: [Exception... "Node was not found"  code: "8" nsresult: "0x80530008 (NS_ERROR_DOM_NOT_FOUND_ERR)"  location: "chrome://browser/content/browser.js Line: 9574"]


        if (popup.id != "appmenu_customizeMenu")
            menuItem.setAttribute("accesskey", toolbar.getAttribute("accesskey"));
>>    popup.insertBefore(menuItem, firstMenuItem);

        menuItem.addEventListener("command", onViewToolbarCommand, false);
(In reply to comment #219)
> in adittin to comment #217

the followup fixed this.
This also partially breaks FireGestures 1.6b11.  Advanced features in FG no longer work.  If the trigger button for a mouse gesture is the right mouse button the right-click context menu very often will appear when performing a gesture.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre - Build ID: 20100923023111
Depends on: 598918
Blocks: 514475
I've got old statusbar icons showing up.

Also, an Addon (Adblock Plus) didn't have an icon, I dragged it into the Addon
bar and now I've completely lost it.
Depends on: 598920
Depends on: 598921
Depends on: 598922
Blocks: 598927
Depends on: 598923
Depends on: 598929
Depends on: 598931
The test only fails on windows debug builds. Works fine on optimized builds.

I'm going to file a followup for that, disable the test for that scenario, and close this bug.

Please file followup bugs for any problems or enhancements from here on out.
Adblock Plus dev version shows up the icon in addons bar.
https://adblockplus.org/devbuilds/adblockplus/

BTW, if i interpret correctly, the addons bar is fine, the extension devs have to update their addons.
Depends on: 598934
(In reply to comment #224)
> Adblock Plus dev version shows up the icon in addons bar.
> https://adblockplus.org/devbuilds/adblockplus/
> 
> BTW, if i interpret correctly, the addons bar is fine, the extension devs have
> to update their addons.

See bug 598929, as to why. I currently have the QAC, ABP and Tumblr Post all
utilising the old method to append themselves to the Addon Bar vis the Status
Bar.
Depends on: 598938
I put a toolbar button to addons bar. Done. Open Customize... again, then hit the "Restore Default Set". But that button on addons bar wont disappear.

Is this intended?
Depends on: 598946
is dao trying to become mozilla’s ulrich drepper?

alex und dietrich both posted links to the google groups discussion, which was supposed to host the discussion about this topic, but dao decided at one point that “he has won” and started to act as if his opinion coincidentally reflects the “official decision”.

the cake’s not baked.
(In reply to comment #227)
> is dao trying to become mozilla’s ulrich drepper?
> 
> alex und dietrich both posted links to the google groups discussion, which was
> supposed to host the discussion about this topic, but dao decided at one point
> that “he has won” and started to act as if his opinion coincidentally reflects
> the “official decision”.
> 
> the cake’s not baked.

Please show a little respect. Dao has done a lot for Firefox and his contributions shouldn't be taken for granted. It's natural that people disagree and we have discussions as to decisions and things get worked out amicably. No matter what happens, in the case of bug 598929 for example. Both sides will have their arguments heard and the decision will be left up to the Product Manager. If you feel that Dao hasn't heard your concerns in here, please file a separate bug or find a specific bug and make a reasoned argument there. At this point, any posts here are likely to be lost in the noise.
Depends on: 598973
All old statubar icons are showing in the add-ons bar. Is this normal behavior and will be kept?

For some reason, I still see an empty statusbar below the addons bar and I can't hide it through the View Menu.
Depends on: 598991
(In reply to comment #222)
> I've got old statusbar icons showing up.
> 
> Also, an Addon (Adblock Plus) didn't have an icon, I dragged it into the Addon
> bar and now I've completely lost it.

There was a pref within ABP which disabled the toolbar button. Turning it back on meant the button appeared.
(In reply to comment #228)
> Please show a little respect. Dao has done a lot for Firefox and his
> contributions shouldn't be taken for granted. It's natural that people disagree
> and we have discussions as to decisions and things get worked out amicably. No
> matter what happens, in the case of bug 598929 for example. Both sides will
> have their arguments heard and the decision will be left up to the Product
> Manager. If you feel that Dao hasn't heard your concerns in here, please file a
> separate bug or find a specific bug and make a reasoned argument there. At this
> point, any posts here are likely to be lost in the noise.

i dislike the concept of “respect”. everybody can be a dick sometimes and i don’t want anybody to be nice to me out of “respect” if i don’t deserve it this moment. ulrich drepper, a great developer which contributed greatly to the open source community, *is*, quite contrary to dao, a real dick. (e.g. http://sourceware.org/bugzilla/show_bug.cgi?id=4980 )

dao, however, ignored that the discussion has not come to an end, completely ignored my proposed compromise, but instead apperantly concluded that his favourite solution would be best for everyone and now behaves like that, e.g. closing bug 598929 for no reason at all.

that said, thanks for the “link target display”, dao, it is a great addon for pre-addon-bar-builds.
I would prefer reading news on progress on the long overdue beta 7 (feature freeze was supposed to be a week ago) rather than who is a dick and who is not.
(In reply to comment #232)
> I would prefer reading news on progress on the long overdue beta 7 (feature
> freeze was supposed to be a week ago) rather than who is a dick and who is not.

And neither is germane to this bug. Take it elsewhere, please, this bug has 84 people cc'd.
Depends on: 599014
http://hg.mozilla.org/mozilla-central/rev/074d9422b4ae

disabled the test for now. the behavior that the test covers has been manually tested on windows, linux and mac, and the automated test passes everywhere but windows debug builds, so we should be ok without it for now. work on fixing the test will be in bug 596913.

with regard to the statusbar compatibility shim: as we discussed in the newsgroups, there are technical issues with the migration of statusbar addons to the add-on bar that need to be addressed before we can fully remove the statusbar shim. the decision as to whether that happens in Firefox 4 or not will have to happen in the next beta cycle, once the migration picture is clearer. getting the add-on bar into developer's hands will really help determine the answer to that question.

again, this bug is closed. move conversation to the mailing list, or file new bugs.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
No longer blocks: 599029
Depends on: 599029
I've been able to set the link target to show up in the new addon-bar as before. I'm now looking for a way to display the Waiting/Loading/etc from xyz.com, has that function been removed completely or only the display of it?
No need for add-on, PL will cover that.
Nope. Progress lines dont show what the browser is downloading currently.

BTW, this feature wont be a big miss for average users.
Yes, it will be a big miss. Not everybody has a perfect Internet connection. Those of us living in the third world have to know which exact part of the loading process is causing the slowdown, and 100% of users pay attention to these messages. Replacing this useful information with blinkenlights is a very poor decision by Mozilla.
I found that part, now it works as before.

BTW has any bug been filed for how to handle mixed-content SSL pages now when the padlock is gone? It was the only easy way to tell if the encrypted page you were on was fully encrypted or not.
(In reply to comment #242)
> BTW has any bug been filed for how to handle mixed-content SSL pages now when
> the padlock is gone? It was the only easy way to tell if the encrypted page you
> were on was fully encrypted or not.

There's bug 515562, but it's about doing something *specifically* for mixed-content SSL, when I really just need *something* that will tell me when a page is mixed-content.
I've filed bug 599102--"Restore Default Set" does not remove Firefox items from Add-ons Toolbar--as a followup bug from this landing.  I _think_ it's not intended behavior but I'm not 100% sure.
Depends on: 599102
Since people would still like to have the loading status, maybe we should create a new toolbar item for it? Has this been considered?
Comment on attachment 477886 [details] [diff] [review]
followup
[Checked in: Comment 216]

We should probably just give this separator an ID instead... would be less fragile that way.
Attachment #477886 - Flags: review?(mano) → review+
Blocks: 599212
Depends on: 599215
Blocks: 599218
Depends on: 599225
No longer depends on: 599102
Flags: in-litmus?
Target Milestone: --- → Firefox 4.0b7
Depends on: 599325
Depends on: 599329
Reference comment #205:  

I am using SeaMonkey 2.0.8:   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8

What is the "web console"?  When I select Ctrl-shift-k, nothing happens.  

I can go to [Tools > Web Development] on the menu bar.  I see "Error Console", "Java Console", "DOM Inspector", and "Live HTTP Headers" (the latter provided by an extension).  I do not see "Web Console".
David,

This is a Firefox bug. The Web Console is Firefox 4.0b7 only.
Depends on: 599654
Depends on: 600196
Depends on: 600647
Depends on: 601304
Depends on: 601917
Depends on: 602195
Depends on: 603187
No longer depends on: 603187
Whiteboard: [strings][landed, baking] → [strings]
Depends on: 604091
Could someone help clarify a question about the status bar?

Will it be impossible to show the mouseover-link and load status in a status bar at the bottom Firefox?


I tried to give the new Firefox 4  (non-status bar feature) a try, but it simply causes too much pain for me, literally.  It's too much eye strain for the way I often sit to have to move visually across such a large screen to the top to view every link instead of the bottom.  I don't know why this is the case, but it is.

Thus, I am curious whether the features of the status bar will be possible again in the future or not?  Should I file a usability issue on this?
https://addons.mozilla.org/en-US/firefox/addon/235283/

Status bar is dead. Now we have addons bar. BTW, questions like this belong to somewhere else, but not to Bugzilla.
(In reply to comment #253)
> https://addons.mozilla.org/en-US/firefox/addon/235283/
> 
> Status bar is dead. Now we have addons bar. BTW, questions like this belong to
> somewhere else, but not to Bugzilla.

I also recommend that extension. It is awesome.
Component: General → Toolbars
QA Contact: general → toolbars
Depends on: 489303
No longer depends on: 608260
Can anyone clarify to me how this is different from the status bar, other than not by default having the old browser-specific content (progress information etc)? I'm trying to write up this change, and so far all I really have is that it has a new name. :)
(In reply to comment #256)

since they refused from the idea to have it be as narrow as sum of it's sub-elements' widths - it is just an old status bar, but with more free space, as link alert text has moved from it to url bar.
The only thing they did is that it is now a regular toolbar, so you can put any elements to it.
Except of course we need to go through scads of old documentation and clean it up for this. Ugh.
Visual and behavioral changes from Firefox 3.6:

* The bar is empty by default.

* The bar is hidden by default.

* The bar is a toolbar XUL element, not a statusbar XUL element.

* Items can be dragged to and dragged off of the bar by opening the customization palette.

* Some add-ons will install to the add-on bar directly, and if not already visible, it will become so when this happens (not landed yet).

* On add-on uninstall, if the bar is visible and the number of items on the bar reaches zero, the bar will be hidden.

* There is a statusbar shim embedded in the add-on bar, for backwards compatibility with older add-ons that expect the status bar element to be present.
correction: the “statusbar shim” is a compatibility hack waiting to be removed, so it should be tagged “obsolete”, if it is included in the documentation at all. see bug 598929
(In reply to comment #260)
> * On add-on uninstall, if the bar is visible and the number of items on the bar
> reaches zero, the bar will be hidden.

Should there be an exception to this rule were separators, springs and spacers won't count towards keeping the Addons bar visible?
(In reply to comment #262)
> (In reply to comment #260)
> > * On add-on uninstall, if the bar is visible and the number of items on the bar
> > reaches zero, the bar will be hidden.
> 
> Should there be an exception to this rule were separators, springs and spacers
> won't count towards keeping the Addons bar visible?

See bug 598923. It only happens on add-on install/uninstall events.
Blocks: 608955
Depends on: 609559
Depends on: 610343
Blocks: 610349
Blocks: 610736
Depends on: 610975
Depends on: 611321
No longer blocks: 610349
Depends on: 610349
Whiteboard: [strings] → [strings][addon bar]
No longer depends on: 600647
No longer blocks: 599229
Depends on: 616363
Depends on: 618277
Depends on: 618278
Depends on: 618280
Depends on: 618437
Attachment #477886 - Attachment description: followup → followup [Checked in: Comment 216]
Attachment #477590 - Attachment description: v8.1 → v8.1 [Checked in: See comment 209+234]
Depends on: 603594
BROKEN! Undo EVERYTHING and make this an extension! Everything done here has been a total disaster!

1.) The status bar is gone.

2.) The "new" "status bar" is inside of the address bar, both the address bar and status bar are information rich and should NOT have been merged.

3.) The "new" "status bar" is slower than a frozen slug climbing a mountain in a winter blizzard, it completely defeats the purpose of looking at the status.

4.) In English status belongs BELOW the object it is the status for, picture/name, icon/text, etc. It is counter-intuitive to move the status bar to the top.

5.) Minimalism is not more with less, it's less with less.

6.)Just because Microsoft is having a mid-life crisis doesn't mean Firefox needs to have a midlife crisis, if they're going to destroy the Windows GUI why should Firefox destroy it's GUI?

7.) No one should have to install an extension for NORMAL FUNCTIONALITY. In fact this is CORE functionality.

8.) What was the primary point of Firefox? Customization. Clearly with the tons of related bugs it's clear that a lot of work was needed to handle all the issues that would arise from butchering the GUI. The time spent doing all of this could have been focused on bugs that are actually important and relevant.

This bug is totally not fixed and all the changes should be completely removed and moved to an extension.
(In reply to comment #264)

I believe you want bug 599212.
Re comment #264:  Use SeaMonkey.  Apparently, the next major version -- SeaMonkey 2.1 -- will NOT implement this change.  This is a Fire-fox only change.  

Alternatively, try the Status-4-Evar extension at <https://addons.mozilla.org/en-US/firefox/addon/235283/>.  Although Firefox 4.0 has not yet been released as a completed end-user application, that extension has been downloaded 24,434 times, an indication of what users really think of this change.  I suggest the developers carefully read the reviews of Status-4-Evar.
(In reply to comment #266)
> Re comment #264:  Use SeaMonkey.  Apparently, the next major version --
> SeaMonkey 2.1 -- will NOT implement this change.  This is a Fire-fox only
> change.  
> 
> Alternatively, try the Status-4-Evar extension at
> <https://addons.mozilla.org/en-US/firefox/addon/235283/>.  Although Firefox 4.0
> has not yet been released as a completed end-user application, that extension
> has been downloaded 24,434 times, an indication of what users really think of
> this change.  I suggest the developers carefully read the reviews of
> Status-4-Evar.

Unacceptable, extensions are not for restoring core functionality, they are for EXTENDING functionality.

All these changes should ONLY be implemented as an extension for those by by in to the minimalism hype. What was wrong with the status bar to begin with? It fulfilled it's role just fine. Some one somewhere decided that they needed an extra 20 pixels of vertical viewing space? Instead of implementing an option to hide the status bar here we have numerous bugs for destroying core functionality and making it as unusable as could possibly be imagined! How about you force-merge the tab bar next to the address bar so people can only see 12 tabs at any given time like Microsoft! Firefox is slowly becoming less customizable than Opera.

Name even a single positive thing that came out of all these changes and getting 20 pixels of vertical viewing space doesn't count. Developers need to start understanding design and understand how the consequences of their actions will effect people. You don't change something for the sake of change and you especially don't even think about messing with core functionality unless something is very very wrong, and now many things are.
89% issues and 11% praise...

http://input.stage.mozilla.com/en-US/search/?q=status+bar&product=firefox&version=&date_start=11%2F10%2F2010&date_end=12%2F21%2F2010

This is bug # 574,688...over half a million bugs but I still have to create and hack chrome.css to restore my go button. There doesn't seem to be a quote operator on stage.mozilla.com though regardless when I search for "go button" I see 90% issues and 10% praise.

Extensions allow everyone to have their cake and eat it to however it's clear there are people in charge who apparently completely forgot that extensions exist or decided to dictate these clearly bad decisions would be implemented even though they're clearly in few if anyone's best interests. So what I'd like to know is who is responsible for allowing these kind of clearly bad decisions to happen?
(In reply to comment #268)
> 89% issues and 11% praise...
> 
> http://input.stage.mozilla.com/en-US/search/?q=status+bar&product=firefox&version=&date_start=11%2F10%2F2010&date_end=12%2F21%2F2010
> 
> This is bug # 574,688...over half a million bugs but I still have to create and
> hack chrome.css to restore my go button. There doesn't seem to be a quote
> operator on stage.mozilla.com though regardless when I search for "go button" I
> see 90% issues and 10% praise.
> 

They guys sent an issue because they were so stupid and can't find how to turn addons bar on...


(In reply to comment #264)
> BROKEN! Undo EVERYTHING and make this an extension! Everything done here has
> been a total disaster!
> 

Oh man, not again! The new addons bar is much more advanced than the old status bar. The addons bar is a simple toolbar, that means you can *put any toolbar item* to it, this brings if the ext devs update their extensions the *ext icons can be placed anywhere on the browser UI*.

Yep, maybe Firefox provide the old status bar elements as a widget on customization palette, but now we have a cool addon, who cares?

This discussion does not belong here. Please move this to newsgroups and/or forums!
(In reply to comment #264)
> BROKEN!

Since your main issue is the status indicator, see (Feature Request) Bug 610429
Also, there is a discussion on the mailing list: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/61de2b33106843d7#
If you can, try to be positive in each one; they are meant to be positive. :)

Point:
Yes, there are some reasons for adding a status indicator and keeping non-minimal features in default Firefox.  However, it is not a good idea to blame the developers (as that will probably not result in a good outcome).  When posting about something I feel strongly about, I always recommend reviewing the post to remove any negative parts and, instead, try to reword it positively.  This method usually works pretty well.
right. you gain nothing by screaming around. it’s amusing, though ;)

there have been bugs about the reimplementation of every feature which has become missing after the removal of the statusbar. the target urls of links are for example at the right side of the address bar now. feel free to post a bug if we overlooked any feature.

if your only point is that you want to have everything like you’re accustomed to, without doing anything about it yourself, i guess you’re out of luck. you’ll have to install status-4-evar and drag the widgets to where they were. and major version changes have to be big to keep up with the pulse of the time (i’m sure once upon a time there were guys who thought that tabs were a bad idea)

also keep in mind that the addonbar has the advantage of being a standard toolbar where you can add, reorder and remove widgets as you like, something that wasn’t possible with the statusbar. that means that with status4evar, the addonbar essentially superseeds the statusbar.
Right, except addon bar is no longer a standard toolbar. It's a toolbar with a huge close button, unlike any other toolbar. And afaik it's impossible to remove that button through customize. So basically instead of one toolbar with hardcoded functionality we got another with the same flaw and none of the features of the previous one.
(In reply to comment #272)
> And afaik it's impossible to remove that button through customize.

If you're that mad at the thing just find a way to hide it via userChrome.css.
But why even put there a close button... it's stupid... in all programs toolbars are enabled somewhere in config menus, so why especially add close button here... ?!
(In reply to comment #274)
> But why even put there a close button... it's stupid... in all programs
> toolbars are enabled somewhere in config menus, so why especially add close
> button here... ?!

yeah, i feel the same way. where is the rationale for this one?
(In reply to comment #275)
> (In reply to comment #274)
> > But why even put there a close button... it's stupid... in all programs
> > toolbars are enabled somewhere in config menus, so why especially add close
> > button here... ?!
> 
> yeah, i feel the same way. where is the rationale for this one?

Maybe it has to do with the OS you're using? I'm on Windows 7 and I can only see a small close button similar to the tab's close button!
(In reply to comment #276)
> (In reply to comment #275)
> > (In reply to comment #274)
> > > But why even put there a close button... it's stupid... in all programs
> > > toolbars are enabled somewhere in config menus, so why especially add close
> > > button here... ?!
> > 
> > yeah, i feel the same way. where is the rationale for this one?
> 
> Maybe it has to do with the OS you're using? I'm on Windows 7 and I can only
> see a small close button similar to the tab's close button!

Please check bug 616014 on the close button, there is rational and its been discussed over there if you would like to read the comments where it was implemented, but not this bug.
What is the point of all of this work? To get rid of 20 pixels but then add another bar in it's place with reduced functionality that appeals to only a handful of people?

So EVERY non-technical user is going to have to install an extension to restore CORE FUNCTIONALITY?

The "new status bar" is a MAJOR SECURITY VULNERABILITY! It's deathly slow so users are going to learn to ignore it and then blindly click on links making them likely to download viruses...unless the counter-"argument" here is that all websites on the internet are trustworthy?

Also my responses in the form of outrage is in response to an outrageous act, e.g. if you guys said something funny then I'd probably laugh.

Most importantly no one has answered my question about ***WHO*** dictated the continued destruction of the GUI?

An option was added to hide the file menu (acceptable) and then it was hidden by default (unacceptable).

"Grandma, just click on the tools menu."

"I don't see a tools menu."

[insert ten minutes of wasted time explaining either keyboard shortcuts or the concept of context menus]

Clearly if core functionality and 20 pixels that is critical to the VAST MAJORITY OF USERS is so offensive I would recommend those users to use Lynx as it has no toolbars and therefor nothing non-minimalistic to complain about!

The DEFAULT settings should have the widest appeal which would be to NON-TECHNICAL USERS. If you don't like the settings then as a TECHNICAL user with TECHNICAL understanding it takes you a fraction of a fraction of the non-technical user's time to adjust things as you prefer.

I really don't think it's sinking in here that minimalism is not the answer.
The reality is that the top browsers appear to either hiding or dropping this information from main UI elements.  Its recognized its useful, but only if you care about it, which most people don't and won't and never knew what it was to begin with, and if you have a internet phone, i bet you don't even notice it doesn't exist.  

Developers don't just decide we need to change something this drastic without some direction, this has been planned for 4.0 by UX teams (see comment 3 for a link to the project plan).  There was plenty of blog posts about the subject and decision about how to work around it.  

While people agree with your comments about status bar text should stay around, again that's for bug 599212 to implement if its re-added.  Your issues belong in a newsgroup to discuss, not in this bug. 

So with that, the only other thing your doing is spamming almost 100 cc'd on this bug.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Please stop spamming this bug with the same tired arguments brought up 6 months ago.  It doesn't take long to get used to the new way and the point is not minimalism, it's moving link location to the Navigation bar where they will be easier to notice for novice users, moving page loading indications to the tabs themselves so you can see tab loading status for more than one tab at a time, and finally to allow TOTAL customization of the Firefox interface for the first time in it's history; something that has been wanted for a long long long time.
I noticed that the work on this bug includes other things such as the load status on tabs which is actually a great idea so I apologize for the generalized statements earlier as my criticisms of removing the status bar while still stand were not intended to include unrelated work.
No longer depends on: 618437
Depends on: 618437
(In reply to comment #280)
> Please stop spamming this bug with the same tired arguments brought up 6 months
> ago.  It doesn't take long to get used to the new way and the point is not
> minimalism, it's moving link location to the Navigation bar where they will be
> easier to notice for novice users, moving page loading indications to the tabs
> themselves so you can see tab loading status for more than one tab at a time,
> and finally to allow TOTAL customization of the Firefox interface for the first
> time in it's history; something that has been wanted for a long long long time.

Please stop spamming this bug with the same tired phrases "stop spamming this bug".
We don't give a **** that you might be bothered or something. If you don't like our messages - don't read them. If you don't like that you get notified - un-****-subscribe.
(In reply to comment #282)
> We don't give a **** that you might be bothered or something.

Speak for yourself.

> If you don't like our messages - don't read them. If you don't like that you get notified -
> un-****-subscribe.

If we don't like you (and we certainly don't), we will wipe you out of bugzilla's face.

Have a nice day.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Why do you bring discredit on Mozilla with this attitude and language in the bugtracker? :S
Good for us, bad for him. :)
(In reply to comment #284)
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 
> Why do you bring discredit on Mozilla with this attitude and language in the
> bugtracker? :S

It's simple: just because mozilla has discredited itself with it's attitude and language.
(In reply to comment #287)
> (In reply to comment #284)
> > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> > 
> > Why do you bring discredit on Mozilla with this attitude and language in the
> > bugtracker? :S
> 
> It's simple: just because mozilla has discredited itself with it's attitude and
> language.

What are you talkin about? Language? You are the first who used that kind of language in this bug... Also note that you are spamming 90 accounts with this nonsense...

To some admin: Please kickbanforever this troll.
You should create new bug for your suggestions and missing or bugged features.
If you want to whine at devs go to Mozilla Google Group.

P.S. Removing status bar and replacing it with addonbar was a good choice, because of better managment etc. A bad choice was only removing useful info in this bar...
Consulted with reed on this, and since this bug is resolved, I'm removing people from the CC list to avoid the unnecessary and unacceptable spam that is happening here. 

File new bugs for other requests or follow-up fixes.
Anyone can remove themselves (In reply to comment #293)
> I'm removing people from the CC list to avoid the unnecessary and
> unacceptable spam 

Considering that everyone can remove themselves if the want, how can you justify screwing with others' subscriptions?
Two things...

1.) While destroying the status bar is officially the worst thing Mozilla has done it does no warrant outright trolling though that doesn't mean the person trolling isn't open to having their opinions.

2.) It's clear that the person or people responsible for destroying the GUI aren't in any way seriously interested that it is an massive negative set of changes with a very minimal set number of positive changes. In short there is no justification to tell anyone to file a new bug report because developers need to know that while someone "above" them is dictating outright stupidity that the vast majority of people actually using Firefox are completely against these changes.

Also it should be noted that mailing lists, IRC channels and the like are not friendly to people in production environments or who actually want to get stuff done. People need to be able to voice their concerns and opinions directly with the developers and the pressure needs to be put on the person or people enforcing this disaster to either relinquish their crusade against the browser or to be removed from their position where they will continue to make massive negative changes to Firefox. This has been especially though not fully true with the IE blog as it showed public pressure on Microsoft for people to easily, directly and openly criticize Microsoft. While trolling isn't desired the trolling on the IE blog these days is nothing compared to what it used to be. It's the internet and it's going to happen. The only thing Microsoft and Mozilla can do is actually listen to people instead of letting key people destroy the software that we've long loved.
please, guys: if you miss a feature, don’t talk about firefox being “destroyed” or some other claim which is as ridiculous as it is uninformative.

instead, tell us exactly what you are missing. we can’t read your minds! lengthy posts about “mozilla” needing to “listen to people” are worthless if you could instead tell us something we could actually listen to, like, an actual problem, missing feature, bug, breakage, blah.

TLDR; tell us *what* is wrong. en detail. if you don’t, nobody can fix anything.
(In reply to comment #296)

We have already said that many times. You just don't listen.
But OK, I will repeat once again:
Get old status-bar back and just add the ability to sort items inside of it and let user put the items to/from it in the "customize toolbars" mode.
That's what you have already done, but you also removed status text, page load progress-bar and moved links' alerts to the address-bar.
No one asked you to do this. People were against it.

So, just give it us back: 1. we need status text in the add-on bar.
2. we need page load progress-bar in the add-on bar.
3. we want you to make moving links' alerts to the address bar AS AN OPTION, so users that don't like that position could switch to the old outlook.

Do that and you'll be blessed.
Oh, and I would also recommend (as a recommendation, not as a demand, like the previous message was) you to re-consider the idea of Jane Boriss' suggested design changes about add-on bar.

It was planned to implement that design, until someone said that it will hide some part of the content area, which could get hidden behind that toolbar and that's a fair argument, but not a reason enough not to implement the new design. Why?
Because we can handle that problem quite easily.
How?
Make that toolbar autohide. And there is an extension that in our context may serve as a proof of concept. The extension is called Barlesque and can be found here: https://github.com/AllSeeingEye/Barlesque or on AMO, or can be directly downloaded from that link: http://dl.dropbox.com/u/11652751/barlesque-1.15b-fx.xpi - this is a little bit modified version (I fixed the issue with personas, now they get applied correctly).
Most CSS part in that extension is written by me, but I know nothing in Javascript, so I couldn't write the functional part, but by chance - I've found that Dmitriy Khudorozhkov already coded that part.

I've also requested him to move that button lower, so it would look like on the Jane Boriss' Fx4 interface concept screenshots, but he is not online for some time, either he lacks the skills to do that, or he is just busy celebrating the holidays, but I'm pretty sure it is possible. Pretty possible with JS, or 100% possible if you'd move addon-bar element in the browser's DOM tree to a little bit higher levels, so it will be a "brother" element to the content-area.
And if we (or you) would do so - there won't even be the problems (that this extension currently experiences sometimes) with positioning the addon-bar depending on the presence of scrollbars on the page (so we could cut down some part of the code and extension would work better, faster and will weight less).


To sum it up:
If you would help us to finalize that extension (help us moving the collapser-button below the content-area, just as it was on Boriss' screenshots) - the extension would be worth getting implemented to the Firefox as a patch.
Oh, and if you would actually fix this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=608411
we could add a glass background to the addon-bar.
i will now make all of you happy:
1. who misses any of the old statusbar widgets can install status4evar (as it was said several times in this report):
   https://addons.mozilla.org/en-US/firefox/addon/235283/
2. who wants a tiny addonbar in the lower right corner can use stylish with this userstyle:
   http://userstyles.org/styles/39555
   or can use barlesque, as suggested above (it is too fat for me, though)
3. who instead wants a glassy addonbar can install this userstyle:
   http://userstyles.org/styles/40188

yes, i made both styles, am i not nice? and i don’t even use windows most of the time.

and now, everyone of you is content, and can stop posting here, because i just told you how to get every single feature you miss. if somebody wants one of these features in firefox by default, please report a different bug for this.

thanks for the attention, and bye.
We want to have it without any extensions/styles/fixes/patches/scripts/whatever. This should be built-in by default.
And no need to report a different bug for this, as it will get ignored. Or just get a "wontfix" pretty fast.
Do you really think we wouldn't create new bugs if it would help anyhow?
if you want (1) by default, i think you are right: there isn’t a good chance, because the change away from the statusbar was intentional from “official” side. and if you want to revert intentional changes, you’ll have to give very good reasons why the new way is a regression compared to the old. and since every feature except the status text is still there, the chances are low. i’d like to see an option for showing the status text in the address bar, however (when the current tab is being loaded and no link is hovered, it could be at the link target position)

if you want (2) by default, there is a chance, if you provide a good solution for the “hides page content” problem. with my style (in the non-autohiding mode), you’ll have to aim quite good to open facebook’s chat, and you won’t be able to see gmail notifications about what’s below the current scrolling position. no problem in the autohiding mode, however.

(3) should be no problem whatsoever, because the proposed change is really just better styling. should be implemented (approximately) like my userstyle did it.
(1) it cut the functions many peoples got used to and liked. Those functions were comfortable, now Fx is uncomfortable, until you use 100500 addons to restore old functionality
+ the bugs like bug 603594 won't appear if you revert some changes back
(2) please, read comment 298 where I describe a way how to do this - autohide (by the timer and by a button) the toolbar is the way out. The button to hide/unhide could be moved to the lower border of the window, just like Jane Boriss represented it on her Fx4 interface concept
(3) creating a new bug is not a problem. The problem is that there is 0 chance it won't get ignored.
Also why they put close button in addon bar, when you can enable/disable toolbar in menu...
It's just simply stupid and illogical, I can see ppl with many icons in addonbar missclicking this and theirs faces next...
1.) John the Revelator nailed the hammer right on the nail in regards to starting a new bug post as it will get ignored

2.) Just like the fact that the overwhelming majority of user input AGAINST removing the status bar was ignored.

3.) Just like calling out who was responsible for enforcing these unwanted changes was intentionally avoided.

The problem is that whoever is responsible is 100% absolute in enforcing these changes because it makes Firefox more difficult for the average person to use, it's purely a political move and it's entirely intentional.

In my view there are only a few ways to have this fixed...

1.) Get in contact with the people above the agent enforcer to have the agent enforcer removed and the status bar restored.

2.) Continue to spread the word that Firefox is intentionally being destroyed in order to make it increasingly difficult for the average user to use.

3.) Move users to whatever browser we deem to be most easily used based upon it's default changes.

Not all the changes made in this bug were negative, having a status line for each tab is actually a good idea however the manner in which all the changes were implemented was purely political. In example if one political party wants to make their opponents look like they are against for what they traditionally stand for they will bundle exactly what they want with exactly what they don't want in a different regards all in the same bill to make people think they are hypocrites. I do think we should determine what changes in this bug should be kept and which changes should be banished to the land of extensions.
(In reply to comment #305)
> 2.) Continue to spread the word that Firefox is intentionally being destroyed
> in order to make it increasingly difficult for the average user to use.

most of the time i have been calm, but now: i don’t know what you’ve smoked, but i want some.

who the **** thinks firefox is more complicated to use now that information was removed which the majority of the people never cared about?

all the changes you are criticising were made to make the firefox ui less cluttered and better to understand for new users. that was the whole POINT of the changes.

e.g.: the user moves his cursor over a link a new address appears lightly colored in the address bar next to the current one. an arrow indicates “this address will change to that if you click now”.

e.g.: the tabs are on top to indicate that every ui element below it belong to and controll the current tab.
> who the **** thinks firefox is more complicated to use now that information was
> removed which the majority of the people never cared about?

The vast overwhelming majority of people beta testing were against removing the status bar so for I think the third time I will post the link that destroys your attempt to confuse others...

http://input.stage.mozilla.com/en-US/search/?q=status+bar&product=firefox&version=&date_start=11%2F10%2F2010&date_end=01%2F08%2F2011

> all the changes you are criticising were made to make the firefox ui less
> cluttered and better to understand for new users. that was the whole POINT of
> the changes.

No, the removal of the status bar and merger more information in to less space makes it more confusing, it's not responsive enough to be relied on and therefore will be ignored. There are vastly better ways to have hidden the status bar like making a context menu for it like the menu bar. Your point is only intended to confuse people in to thinking that the enforced actions are desired when they area clearly desired only by the people enforcing them. The fact that you responded so quickly also is grounds that I hit the nail on the head accurately in the contexts that I discussed which is a devastatingly stereotypical response from those who enforce their actions in the overwhelming face of public disagreement.

> e.g.: the user moves his cursor over a link a new address appears lightly
> colored in the address bar next to the current one. an arrow indicates “this
> address will change to that if you click now”.

1.) It's devastatingly slow and therefore users who DO know where to look will learn to ignore the "new and improved" status bar thus making them blatantly unaware of what they are clicking on creating a massive security vulnerability.

2.) Status in a left-to-right top-to-bottom language like English is typically BELOW the item it is the status for. A picture of a person is the object that naturally exists so the status (their name) is traditionally below their picture as the name exists second to the person existing. The status exists secondly because the page in the link exists before it thus implying the need for the status.
Marking as verified fixed based on its landing a couple of months ago.
Status: RESOLVED → VERIFIED
Depends on: 629964
Depends on: 636206
Depends on: 645445
Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Blocks: 264205
(In reply to flying sheep from comment #306)
1. who misses any of the old statusbar widgets can install status4evar (as it was said several times in this report):

That's just the point. The *necessity* *having* to use an add-on to get back a functionality loved by thousands (or ten-, hundred-thousands) is an utterly unacceptable thing, and the thing that makes the users angry. Because this change was forced upon them; they didn't ask for it at all.
It's a shame that a little crowd of software developers/managers can go as far as deciding what is best for the users; and even ignoring each warning beforehand, just saying "we are management we are the pros; trust us we'll do the right thing". Yeah right, they will. And user reactions were plain to see (and even highly predictable).

(In reply to flying sheep from comment #306)
> all the changes you are criticising were made to make the firefox ui less
> cluttered and better to understand for new users. that was the whole POINT
> of the changes.

Yes, but if you read the 300+ comments on Status4Evar add-on, you will see that users are EXTREMELY ANGRY about this change (quoting: "What did they think?" / "Have they gone nuts?" ...), making that "whole POINT" turn out to be rather pointLESS.
It's actually the *minority* of users that are happy with the changes, except for a bunch of geeks that reply you in the typical "things evolve. live with it" fashion.
And if you look at the date of this bug, you will figure out that it's now 3 YEARS after, that people are still using Status4Evar because nobody still has cared for them. If they want the old-style way, then please listen to them and give them a way FFS! And that means not by installing an add-on to replace features removed just by mad thinking! I hope you didn't overlook that just this "ridiculous" change has led many to either use the "emulation" provided by Status4Evar or simply move over to Chrome!
So you DO LOSE long-time users by making such unreflected changes without asking anybody first. And I mean, asking a non-developer person. A just-user, at best with no knowledge in software engineering at all. You will be surprised how different their answer will be from yours.

(In reply to flying sheep from comment #306)
The vast overwhelming majority of people beta testing were against removing the status bar

Correct. People want the good ol' style back. No compromises or approximations, but the real thing.
umm, customization is a feature of firefox. nobody is “left alone” if they are missing the status bar, but get it back immediately after typing “status bar” in the addon search bar and install the 5th search result.

if you want a browser that is preconfigured like you want it, go search for it, firefox isn’t it anymore. if you want the perfect browser for you, check out addons until you’ve molded firefox to be it.

i’m pretty sure that the amount of people who are angry with the gone status bar is limited to those who leave angry 5-star ratings on status-4-evar. the rest is happy without the status bar. it’s gone, but not without leaving you the choice to get it back. live with it, what else could you want?
@flying sheep

You're using our argument against us! YOU people removed the status bar which everyone relied on for YOUR preferences and told everyone else to go blow!

The normal status bar is CRITICAL functionality which most users rely upon. If YOU want Firefox preconfigured for extremist-minimalism either go download the anti-GUI Chrome browser or right-click and uncheck the status bar yourself!
Depends on: 646874
I have a question regarding the replacement plug-in Status-4-Evar. I am using it since the real status bar was removed. Now I read that the Addon bar, which is used instead in the plug-in will be removed as well. Will the plug-in Status-4-Evar still work or should I forget Firefox and go look for something else?
@Joe Kucera, Mozilla has been working very hard to make Firefox's default settings as user-hostile as possible going so far as to copy Microsoft's move to put the home button on the far-right part of the toolbars however the *EXTENSION* Status-4-Evar restores the normal status bar. You can still customize the toolbars and in example move the Adblock Plus button back to the top-right where it belongs instead of the bottom-left.
@Joe Kucera, @John A. Bilicki III
NOW THEY WENT AS FAR AS REMOVING THE ADD-ON BAR ALTOGETHER!!
first: hide it by default
second: don't update the new Australis customization to support it
third: remove the sidebar buttons (how do you access the sidebars without hotkeys or menu bar? 404 not found)
fourth: REMOVE THE WHOLE DARN THING, and remove the option to get rid of navigation toolbar, and disallow the option to hide the tab bar when there is just one tab.

Firefox is getting less and less customizable, and mimicking other browsers (no bottom bar, removing Firefox button and unable to get back) more and more.
status 4-evar will need to make the entire toolbar in the add-on. THANKS A LOT MOZILLA!!! YOU REMOVED MAJOR FEATURES FOR THE FIRST TIME!! (as opposed to just making them hidden) Where will I put my add-on buttons that the navbar does not have space for NOW, MOZILLA?!?
> status 4-evar will need to make the entire toolbar in the add-on.

that’s no problem. custom toolbars are literally one line of JS/XUL.

could you please stop conjuring needless drama and shut up?
Flyrin Sheep, you should join Mozilla, you'd fit in with the Firefox-hating crowd just fine!

rexyrexy2 has completely valid points. Mozilla has intentionally been removing the ability to customize features just like MICROSOFT has over the past few years. No longer can you right-click and enable something, now you have to bog down Firefox with lots of extensions and get neck-deep in to coding which for most people is simply not an option. Firefox was ORIGINALLY designed to be a CUSTOMIZABLE browser, Mozilla has shifted towards copying the anti-GUI tactics of Google and where they HAVEN'T removed features they copied Microsoft! MOZILLA COPIED MICROSOFT! The home button doesn't belong on the right side of the screen! That's a crack-cocaine level induced decision.
John A. Bilicki III: Stop creating useless bugmail for everybody on this ticket and post your opinions in a random webforum out there, or get a blog or whatever where you can happily rant. Here you waste everybody's time (I was originally interested in this bug report, but thanks to you not anymore) and I hope that somebody will block your Bugzilla account.
Depends on: 1320154
You need to log in before you can comment on or make changes to this bug.