replace the status bar with the addon bar

VERIFIED FIXED in Firefox 4.0b7

Status

()

defect
P1
normal
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: dietrich, Assigned: dietrich)

Tracking

(Depends on 1 bug, Blocks 1 bug, {dev-doc-complete})

Trunk
Firefox 4.0b7
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

(Whiteboard: [strings][addon bar], )

Attachments

(8 attachments, 21 obsolete attachments)

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
mano
: 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
Assignee

Description

9 years ago
No description provided.
Assignee

Comment 1

9 years ago
Posted 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
Assignee

Updated

9 years ago
Blocks: 568932
Assignee

Comment 2

9 years ago
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.
Assignee

Comment 3

9 years ago
* 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.
Assignee

Comment 6

9 years ago
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.
Assignee

Comment 7

9 years ago
Posted patch wip2 (obsolete) — Splinter Review
Attachment #454046 - Attachment is obsolete: true
Assignee

Comment 8

9 years ago
Drivers: UX has said this is a key part of the Fx4 facelift, so requesting blocking.
blocking2.0: --- → ?
blocking2.0: ? → beta5+

Comment 9

9 years ago
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.
Assignee

Comment 10

9 years ago
Posted 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?
Assignee

Updated

9 years ago
Attachment #465223 - Flags: feedback? → feedback?(dao)
Assignee

Comment 11

9 years ago
(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.
Assignee

Updated

9 years ago
Depends on: 489303
Assignee

Updated

9 years ago
Attachment #465223 - Flags: feedback?(dao) → feedback?(mano)
Assignee

Updated

9 years ago
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?
Assignee

Comment 13

9 years ago
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.

Updated

9 years ago
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.

Comment 17

9 years ago
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.

Comment 19

9 years ago
(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.

Comment 21

9 years ago
(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.

Comment 22

9 years ago
(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?

Comment 24

9 years ago
(In reply to comment #23)
Read the bug dependencies.
Assignee

Updated

9 years ago
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.
Assignee

Updated

9 years ago
Depends on: 579506
Assignee

Updated

9 years ago
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.

Comment 28

9 years ago
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)
Assignee

Comment 31

9 years ago
Posted 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
Assignee

Comment 32

9 years ago
(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+
Assignee

Comment 33

9 years ago
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.
Assignee

Comment 35

9 years ago
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
Assignee

Comment 36

9 years ago
(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.
Assignee

Updated

9 years ago
No longer depends on: DownloadsPanel
Assignee

Updated

9 years ago
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?)
Assignee

Comment 39

9 years ago
(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.
Assignee

Comment 40

9 years ago
Posted 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.
Assignee

Comment 43

9 years ago
Posted patch v4 (obsolete) — Splinter Review
Attachment #471418 - Attachment is obsolete: true
Attachment #471535 - Flags: review?(mano)
Attachment #471418 - Flags: review?(mano)
Assignee

Comment 44

9 years ago
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"

Comment 48

9 years ago
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.

Comment 49

9 years ago
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).

Comment 50

9 years ago
It looks like this bug depends on #564934, because currently the download status is shown on the status bar. Am I wrong?

Comment 51

9 years ago
(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.
Assignee

Updated

9 years ago
Blocks: 593949
Assignee

Updated

9 years ago
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.
Assignee

Comment 56

9 years ago
Posted 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.

Comment 60

9 years ago
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.

Comment 61

9 years 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.
Assignee

Comment 62

9 years ago
(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.

Comment 63

9 years ago
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?
Assignee

Comment 64

9 years ago
Posted 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
Assignee

Comment 65

9 years ago
(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.
Assignee

Updated

9 years ago
No longer depends on: 544818
Assignee

Updated

9 years ago
No longer depends on: 489303
Assignee

Comment 67

9 years ago
Posted 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.
Assignee

Comment 69

9 years ago
I forgot to qrefresh.
Whiteboard: [strings] → [strings][has WIP patch]
Assignee

Comment 70

9 years ago
Posted 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)
Assignee

Comment 71

9 years ago
(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.
Assignee

Comment 73

9 years ago
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-
Assignee

Comment 75

9 years ago
Posted 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.
Assignee

Comment 77

9 years ago
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?
Assignee

Comment 78

9 years ago
(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.
(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.
Posted 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).
Assignee

Comment 86

9 years ago
(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.
Assignee

Comment 87

9 years ago
Posted 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)
Assignee

Comment 88

9 years ago
(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.
(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.
Assignee

Comment 92

9 years ago
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!
Assignee

Comment 94

9 years ago
Posted 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)
Assignee

Comment 96

9 years ago
Posted 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+
Assignee

Comment 97

9 years ago
(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.
Assignee

Updated

9 years ago
Whiteboard: [strings][has WIP patch] → [strings][has review][failing test on try]
Assignee

Comment 98

9 years ago
for those asking, tryserver builds show up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/?C=M;O=D
Assignee

Comment 99

9 years ago
Posted 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
Assignee

Comment 100

9 years ago
latest patch looks ok on try, a couple of unrelated known oranges (neither of which fail locally).
Assignee

Updated

9 years ago
Whiteboard: [strings][has review][failing test on try] → [strings][has review][waiting on dependencies to land]

Comment 101

9 years ago
It is time to ask for r+ ?

Comment 102

9 years ago
Perhaps this bug could be marked for documentation since it will break a great many add-ons when it lands?

Comment 103

9 years ago
> 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

Comment 104

9 years ago
(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.
Assignee

Comment 105

9 years ago
Posted patch v7.2 updated to tip (obsolete) — Splinter Review
Attachment #475113 - Attachment is obsolete: true
Attachment #475492 - Flags: review+
Assignee

Comment 106

9 years ago
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?
Assignee

Comment 108

9 years ago
(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.

Comment 109

9 years ago
(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
Assignee

Comment 110

9 years ago
(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.
Assignee

Comment 112

9 years ago
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)
Assignee

Comment 116

9 years ago
(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.
Assignee

Comment 117

9 years ago
landed: http://hg.mozilla.org/mozilla-central/rev/bb2db707bfcb

keeping this open while i watch the tree.
Assignee

Updated

9 years ago
Whiteboard: [strings][has review][waiting on dependencies to land] → [strings][landed, baking]
Assignee

Comment 118

9 years ago
test is failing (popupshown listener isn't being called), but passes locally. will try to figure it out, and backout otherwise.
Assignee

Updated

9 years ago
Depends on: 596913

Comment 121

9 years ago
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?)

Comment 122

9 years ago
(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.
Assignee

Comment 124

9 years ago
(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?
Assignee

Comment 126

9 years ago
(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.
Assignee

Comment 127

9 years ago
(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.
Assignee

Comment 129

9 years ago
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]

Comment 130

9 years ago
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?

Comment 131

9 years ago
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!

Updated

9 years ago
Depends on: 597155

Comment 133

9 years ago
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.

Comment 136

9 years ago
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.

Comment 137

9 years ago
(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.

Comment 138

9 years ago
> 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.

Comment 139

9 years ago
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.

Comment 141

9 years ago
(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.

Comment 143

9 years ago
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 ;-)

Comment 146

9 years ago
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.

Comment 147

9 years ago
(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.

Comment 149

9 years ago
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

Comment 152

9 years ago
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

Comment 153

9 years ago
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?

Comment 154

9 years ago
> 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.

Comment 156

9 years ago
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?

Comment 157

9 years ago
(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! :)

Comment 160

9 years ago
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 ;-)

Comment 163

9 years ago
(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

Comment 165

9 years ago
(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.

Comment 167

9 years ago
(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
Assignee

Comment 169

9 years ago
Posted 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
Assignee

Updated

9 years ago
Whiteboard: [strings][re-opened, test failures] → [strings][patch in progress, waiting on try results]

Comment 170

9 years ago
(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.

Comment 172

9 years ago
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.

Comment 174

9 years ago
> 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 .
Assignee

Comment 175

9 years ago
(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.
Assignee

Comment 176

9 years ago
Posted 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?
Assignee

Updated

9 years ago
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?
Assignee

Comment 178

9 years ago
Posted 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.
Screenshot on Windows, with Dao's dictionary addon and Sync toolbar button dragged from palette.
Attachment #476642 - Attachment is obsolete: true
Assignee

Comment 180

9 years ago
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.
Assignee

Comment 182

9 years ago
(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.

Comment 187

9 years ago
(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.

Comment 192

9 years ago
(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.
Assignee

Comment 196

9 years ago
Update: wrestling with CSS on Windows, where I'm unable to override the border styles on embedded statusbarpanel elements for some reason.

Comment 197

9 years ago
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.

Comment 198

9 years ago
(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.)

Comment 199

9 years ago
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.
Assignee

Comment 202

9 years ago
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)
Assignee

Comment 203

9 years ago
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]

Comment 204

9 years ago
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?

Comment 205

9 years ago
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+
Duplicate of this bug: 598848
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
Assignee

Comment 209

9 years ago
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]
Assignee

Comment 210

9 years ago
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
Assignee

Comment 211

9 years ago
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.
Assignee

Comment 214

9 years ago
> > 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.
Assignee

Comment 215

9 years ago
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)

Comment 217

9 years ago
(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.
Posted 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)

Comment 219

9 years ago
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);
Assignee

Comment 220

9 years ago
(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

Comment 222

9 years ago
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.

Updated

9 years ago
Depends on: 598920

Updated

9 years ago
Depends on: 598921
Depends on: 598922

Updated

9 years ago
Blocks: 598927
Assignee

Updated

9 years ago
Depends on: 598923

Updated

9 years ago
Depends on: 598929
Depends on: 598931
Assignee

Comment 223

9 years ago
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.

Updated

9 years ago
Depends on: 598934

Comment 225

9 years ago
(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.

Updated

9 years ago
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

Comment 227

9 years ago
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.

Comment 228

9 years ago
(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.

Updated

9 years ago
Depends on: 598973

Comment 229

9 years ago
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.

Updated

9 years ago
Depends on: 598991

Comment 230

9 years ago
(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.

Comment 231

9 years ago
(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.

Comment 232

9 years ago
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.

Updated

9 years ago
Depends on: 599014
Assignee

Comment 234

9 years ago
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.
Assignee

Updated

9 years ago
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
No longer blocks: 599029
Depends on: 599029

Comment 236

9 years ago
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.

Comment 241

9 years ago
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.

Comment 242

9 years ago
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.

Comment 245

9 years ago
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.

Updated

9 years ago
Depends on: 599102

Comment 246

9 years ago
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

Updated

9 years ago
No longer depends on: 599102
Flags: in-litmus?
Target Milestone: --- → Firefox 4.0b7
Depends on: 599325
Depends on: 599329

Comment 248

9 years ago
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".

Comment 249

9 years ago
David,

This is a Firefox bug. The Web Console is Firefox 4.0b7 only.
Duplicate of this bug: 599644
Depends on: 599654
Depends on: 600196
Depends on: 600647
Duplicate of this bug: 599766
Depends on: 601304

Updated

9 years ago
Depends on: 601917
Depends on: 602195

Updated

9 years ago
Depends on: 603187
No longer depends on: 603187
Whiteboard: [strings][landed, baking] → [strings]
Depends on: 604091

Comment 252

9 years ago
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.

Comment 254

9 years ago
(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.

Updated

9 years ago
Duplicate of this bug: 512137
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.
Assignee

Comment 260

9 years ago
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.

Comment 261

9 years ago
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

Comment 262

9 years ago
(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?
Assignee

Comment 263

9 years ago
(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.

Updated

9 years ago
Blocks: 608955

Updated

9 years ago
Depends on: 609559

Updated

9 years ago
Depends on: 610343

Updated

9 years ago
Blocks: 610349

Updated

9 years ago
Blocks: 610736

Updated

9 years ago
Depends on: 610975

Updated

9 years ago
Depends on: 611321

Updated

9 years ago
No longer blocks: 610349
Depends on: 610349
Assignee

Updated

9 years ago
Whiteboard: [strings] → [strings][addon bar]
No longer depends on: 600647
No longer blocks: 599229

Updated

9 years ago
Depends on: 616363

Updated

9 years ago
Depends on: 618277

Updated

9 years ago
Depends on: 618278

Updated

9 years ago
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.

Comment 266

9 years ago
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!

Comment 270

9 years ago
(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.

Comment 271

9 years ago
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.

Comment 272

9 years ago
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.

Comment 273

9 years ago
(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... ?!

Comment 275

9 years ago
(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

Comment 280

9 years ago
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.

Updated

9 years ago
No longer depends on: 618437

Updated

9 years ago
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.

Comment 294

9 years ago
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.

Comment 296

9 years ago
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.

Comment 300

9 years ago
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?

Comment 302

9 years ago
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.

Comment 306

9 years ago
(In reply to