Last Comment Bug 574688 - replace the status bar with the addon bar
: replace the status bar with the addon bar
Status: VERIFIED FIXED
[strings][addon bar]
: dev-doc-complete
Product: Firefox
Classification: Client Software
Component: Toolbars and Customization (show other bugs)
: Trunk
: All All
: P1 normal with 11 votes (vote)
: Firefox 4.0b7
Assigned To: Dietrich Ayala (:dietrich)
:
: :Gijs Kruitbosch
Mentors:
https://wiki.mozilla.org/Firefox/Proj...
: 512137 598848 599644 599766 (view as bug list)
Depends on: 598991 646874 1320154 489303 568932 578028 586718 587908 595937 596913 597155 598918 598920 598921 598922 598923 598929 598931 598934 598938 598946 598973 599014 599015 599029 599215 599225 599325 599329 599654 599848 600196 601304 601917 602195 603594 604091 604093 604316 609559 610343 610349 610975 611321 614929 616363 618277 618278 618280 618437 629964 636206 645445
Blocks: 608955 264205 514475 593949 597949 598898 598927 599212 599218 610736
  Show dependency treegraph
 
Reported: 2010-06-25 08:35 PDT by Dietrich Ayala (:dietrich)
Modified: 2016-11-24 09:42 PST (History)
21 users (show)
hskupin: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta7+


Attachments
wip (2.11 KB, patch)
2010-06-25 08:37 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
wip2 (4.91 KB, patch)
2010-07-20 11:39 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v1 (52.45 KB, patch)
2010-08-12 06:04 PDT, Dietrich Ayala (:dietrich)
asaf: feedback+
Details | Diff | Splinter Review
v2 (41.64 KB, patch)
2010-08-27 13:56 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v3 (76.90 KB, patch)
2010-09-01 23:06 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v4 (83.88 KB, patch)
2010-09-02 10:16 PDT, Dietrich Ayala (:dietrich)
asaf: review-
Details | Diff | Splinter Review
v5 wip (80.49 KB, patch)
2010-09-07 12:59 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v5 wip (83.04 KB, patch)
2010-09-09 00:01 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v5 wip (82.62 KB, patch)
2010-09-09 09:27 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v5 (84.70 KB, patch)
2010-09-09 12:40 PDT, Dietrich Ayala (:dietrich)
asaf: review-
Details | Diff | Splinter Review
v6 wip (89.39 KB, patch)
2010-09-10 12:53 PDT, Dietrich Ayala (:dietrich)
asaf: review-
Details | Diff | Splinter Review
something like this (7.00 KB, patch)
2010-09-11 08:26 PDT, Mano (::mano, needinfo? for any questions; not reading general bugmail)
no flags Details | Diff | Splinter Review
the corresponding browsr.xul change for testing (3.95 KB, patch)
2010-09-11 08:28 PDT, Mano (::mano, needinfo? for any questions; not reading general bugmail)
no flags Details | Diff | Splinter Review
v6 (89.09 KB, patch)
2010-09-13 10:39 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v7 (88.31 KB, patch)
2010-09-13 13:57 PDT, Dietrich Ayala (:dietrich)
asaf: review+
Details | Diff | Splinter Review
v7.1 (88.95 KB, patch)
2010-09-14 03:44 PDT, Dietrich Ayala (:dietrich)
dietrich: review+
Details | Diff | Splinter Review
v7.2 (89.70 KB, patch)
2010-09-14 09:50 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v7.2 updated to tip (89.65 KB, patch)
2010-09-15 06:43 PDT, Dietrich Ayala (:dietrich)
dietrich: review+
Details | Diff | Splinter Review
example add-on (non-jetpack) (2.08 KB, application/x-xpinstall)
2010-09-15 09:36 PDT, Dietrich Ayala (:dietrich)
no flags Details
screenshot of current state on Windows (330.04 KB, image/png)
2010-09-19 08:22 PDT, Csaba Kozák [:WonderCsabo]
no flags Details
screenshot of current state on Linux (104.75 KB, image/png)
2010-09-19 08:56 PDT, 3e2224c2
no flags Details
v8 wip (70.99 KB, patch)
2010-09-21 05:33 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
v8 (71.45 KB, patch)
2010-09-21 08:44 PDT, Dietrich Ayala (:dietrich)
no flags Details | Diff | Splinter Review
screenshot (2.23 KB, image/png)
2010-09-21 09:02 PDT, Dietrich Ayala (:dietrich)
no flags Details
screenshot on Windows (3.28 KB, image/png)
2010-09-21 09:16 PDT, Csaba Kozák [:WonderCsabo]
no flags Details
v8.1 [Checked in: See comment 209+234] (71.87 KB, patch)
2010-09-22 11:43 PDT, Dietrich Ayala (:dietrich)
asaf: review+
Details | Diff | Splinter Review
screenshot (30.35 KB, image/jpeg)
2010-09-23 04:16 PDT, pal-moz
no flags Details
followup [Checked in: Comment 216] (1.20 KB, patch)
2010-09-23 04:32 PDT, Dietrich Ayala (:dietrich)
gavin.sharp: review+
Details | Diff | Splinter Review
Linux borders (6.24 KB, image/png)
2010-09-23 04:54 PDT, Michael Monreal [:monreal]
no flags Details

Description Dietrich Ayala (:dietrich) 2010-06-25 08:35:03 PDT

    
Comment 1 Dietrich Ayala (:dietrich) 2010-06-25 08:37:29 PDT
Created attachment 454046 [details] [diff] [review]
wip

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.
Comment 2 Dietrich Ayala (:dietrich) 2010-06-25 08:56:28 PDT
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.
Comment 3 Dietrich Ayala (:dietrich) 2010-06-28 23:13:48 PDT
* 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
Comment 4 Dão Gottwald [:dao] 2010-07-19 05:21:34 PDT
See bug 514475 for the security button.
Comment 5 Gary [:streetwolf] 2010-07-19 05:48:18 PDT
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.
Comment 6 Dietrich Ayala (:dietrich) 2010-07-20 11:25:22 PDT
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.
Comment 7 Dietrich Ayala (:dietrich) 2010-07-20 11:39:31 PDT
Created attachment 458733 [details] [diff] [review]
wip2
Comment 8 Dietrich Ayala (:dietrich) 2010-08-09 10:43:51 PDT
Drivers: UX has said this is a key part of the Fx4 facelift, so requesting blocking.
Comment 9 patrickjdempsey 2010-08-11 16:25:53 PDT
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.
Comment 10 Dietrich Ayala (:dietrich) 2010-08-12 06:04:10 PDT
Created attachment 465223 [details] [diff] [review]
v1

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?
Comment 11 Dietrich Ayala (:dietrich) 2010-08-12 06:16:20 PDT
(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.
Comment 12 Dão Gottwald [:dao] 2010-08-12 12:08:40 PDT
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?
Comment 13 Dietrich Ayala (:dietrich) 2010-08-12 12:19:21 PDT
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.
Comment 14 Matthew Turnbull [Bluefang] 2010-08-12 15:50:39 PDT
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.
Comment 15 Please Ignore This Troll (Account Disabled) 2010-08-12 17:23:06 PDT
(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.
Comment 16 Peter Henkel [:Terepin] 2010-08-13 03:52:00 PDT
I believe it will be moved to Doorhanger.
Comment 17 Michael Lefevre 2010-08-17 08:20:10 PDT
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?
Comment 18 Dão Gottwald [:dao] 2010-08-17 08:22:02 PDT
(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 Paul [pwd] 2010-08-17 08:40:38 PDT
(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.
Comment 20 Dão Gottwald [:dao] 2010-08-17 10:02:40 PDT
(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 Paul [pwd] 2010-08-17 10:07:27 PDT
(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 Michael Lefevre 2010-08-17 14:48:47 PDT
(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.
Comment 23 Please Ignore This Troll (Account Disabled) 2010-08-17 15:27:12 PDT
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 Dave Garrett 2010-08-17 15:30:14 PDT
(In reply to comment #23)
Read the bug dependencies.
Comment 25 Alex Faaborg [:faaborg] (Firefox UX) 2010-08-24 18:49:05 PDT
Additional discussion on the change and various dependencies here: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/ad89ab1303d2dd2c#
Comment 26 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-08-25 08:20:21 PDT
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.
Comment 27 Jennifer Morrow [:Boriss] (UX) 2010-08-25 10:31:56 PDT
(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 Cam 2010-08-26 10:38:20 PDT
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.
Comment 29 Alex Faaborg [:faaborg] (Firefox UX) 2010-08-26 11:50:27 PDT
>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.
Comment 30 Peter Henkel [:Terepin] 2010-08-26 11:58:13 PDT
Two ideas:
1. Use Doorhanger (probably problematic, Alex should know)
2. Attach it to the NavBar with same behaviour (probably better solution)
Comment 31 Dietrich Ayala (:dietrich) 2010-08-27 13:56:34 PDT
Created attachment 470010 [details] [diff] [review]
v2

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.
Comment 32 Dietrich Ayala (:dietrich) 2010-08-27 14:03:47 PDT
(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.
Comment 33 Dietrich Ayala (:dietrich) 2010-08-30 08:04:24 PDT
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.
Comment 34 Dão Gottwald [:dao] 2010-08-30 08:10:00 PDT
Since you hardly ever want the same status text in two places, extensions can simply override setOverLink.
Comment 35 Dietrich Ayala (:dietrich) 2010-08-30 09:40:55 PDT
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.
Comment 36 Dietrich Ayala (:dietrich) 2010-08-30 09:55:26 PDT
(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.
Comment 37 Axel Hecht [:Pike] 2010-09-01 11:17:27 PDT
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?
Comment 38 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-01 14:28:19 PDT
The option to hide or display the bar in the menus needs to be updated (is Extension Bar the final name?)
Comment 39 Dietrich Ayala (:dietrich) 2010-09-01 22:57:41 PDT
(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.
Comment 40 Dietrich Ayala (:dietrich) 2010-09-01 23:06:38 PDT
Created attachment 471418 [details] [diff] [review]
v3

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
Comment 41 Axel Hecht [:Pike] 2010-09-02 03:31:01 PDT
Is there a bug for the popup blocker stuff? xoxo, Pike.
Comment 42 Dão Gottwald [:dao] 2010-09-02 03:40:59 PDT
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.
Comment 43 Dietrich Ayala (:dietrich) 2010-09-02 10:16:29 PDT
Created attachment 471535 [details] [diff] [review]
v4
Comment 44 Dietrich Ayala (:dietrich) 2010-09-02 10:18:41 PDT
Latest patch fixes Dao's comment, has a bunch of cleanup, and some more consolidation.
Comment 45 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-02 15:02:51 PDT
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.
Comment 46 Please Ignore This Troll (Account Disabled) 2010-09-02 15:37:47 PDT
(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.
Comment 47 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-02 16:11:01 PDT
It was my impression that jetpacks would be called "extensions"
Comment 48 Dave Garrett 2010-09-02 16:17:31 PDT
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 patrickjdempsey 2010-09-02 16:49:13 PDT
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 Ivan Stetsenko 2010-09-05 09:06:40 PDT
It looks like this bug depends on #564934, because currently the download status is shown on the status bar. Am I wrong?
Comment 51 Josh Tumath 2010-09-05 09:11:02 PDT
(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.
Comment 52 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-05 14:18:02 PDT
--- 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 53 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-05 14:19:32 PDT
Comment on attachment 471535 [details] [diff] [review]
v4

I would to do a final-pass on the next version, thus minusing.
Comment 54 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-05 14:26:03 PDT
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.
Comment 55 Dão Gottwald [:dao] 2010-09-07 09:11:58 PDT
(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.
Comment 56 Dietrich Ayala (:dietrich) 2010-09-07 12:59:07 PDT
Created attachment 472734 [details] [diff] [review]
v5 wip
Comment 57 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-07 13:02:32 PDT
No, I didn't refer to nsiobserver. All we need is a simple js pseudo-api.
Comment 58 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-07 15:54:32 PDT
>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."
Comment 59 Alex Limi (:limi) — Firefox UX Team 2010-09-07 16:31:19 PDT
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 Dave Garrett 2010-09-07 16:42:55 PDT
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 patrickjdempsey 2010-09-07 19:32:51 PDT
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.
Comment 62 Dietrich Ayala (:dietrich) 2010-09-07 22:35:14 PDT
(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 Dave Garrett 2010-09-08 23:47:27 PDT
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?
Comment 64 Dietrich Ayala (:dietrich) 2010-09-09 00:01:24 PDT
Created attachment 473418 [details] [diff] [review]
v5 wip

* 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.
Comment 65 Dietrich Ayala (:dietrich) 2010-09-09 00:02:12 PDT
(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 66 Axel Hecht [:Pike] 2010-09-09 06:34:12 PDT
Comment on attachment 473418 [details] [diff] [review]
v5 wip

startDescription.label will need a new id.
Comment 67 Dietrich Ayala (:dietrich) 2010-09-09 09:27:51 PDT
Created attachment 473589 [details] [diff] [review]
v5 wip

* 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
Comment 68 Axel Hecht [:Pike] 2010-09-09 09:48:33 PDT
(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.
Comment 69 Dietrich Ayala (:dietrich) 2010-09-09 09:54:07 PDT
I forgot to qrefresh.
Comment 70 Dietrich Ayala (:dietrich) 2010-09-09 12:40:32 PDT
Created attachment 473679 [details] [diff] [review]
v5

some problems getting the hidden state to persist, but outside of that, ready for another review pass.
Comment 71 Dietrich Ayala (:dietrich) 2010-09-09 12:46:16 PDT
(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 72 Dão Gottwald [:dao] 2010-09-10 06:36:44 PDT
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.
Comment 73 Dietrich Ayala (:dietrich) 2010-09-10 07:23:41 PDT
Smaug, is that also the case with these mutation events?
Comment 74 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-10 09:23:27 PDT
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.
Comment 75 Dietrich Ayala (:dietrich) 2010-09-10 12:53:55 PDT
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.
Comment 76 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-10 13:46:57 PDT
(In reply to comment #75)
> Created attachment 474157 [details] [diff] [review]
> v6 wip
> 
> most of the changes. still need to finish integrating into the current toolbar
> persistence/visiblity code.
> 
> i'm not really ok with leaving the hiding/showing of the toolbar up to add-ons.
> but we can fix that as a followup.

I don't get that. If they're using some api (jetpack?) to add the items - then you don't need the handler.  However, if they use simple overlays for that matter, then the handler won't help much.
Comment 77 Dietrich Ayala (:dietrich) 2010-09-10 21:45:05 PDT
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.
Comment 78 Dietrich Ayala (:dietrich) 2010-09-10 21:54:20 PDT
(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 79 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-11 01:57:45 PDT
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.
Comment 80 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-11 02:02:43 PDT
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.
Comment 81 Olli Pettay [:smaug] 2010-09-11 07:50:59 PDT
(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.
Comment 82 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-11 08:26:27 PDT
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.
Comment 83 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-11 08:28:32 PDT
Created attachment 474373 [details] [diff] [review]
the corresponding browsr.xul change for testing
Comment 84 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-11 08:34:59 PDT
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.
Comment 85 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-11 08:38:40 PDT
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).
Comment 86 Dietrich Ayala (:dietrich) 2010-09-13 10:37:56 PDT
(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.
Comment 87 Dietrich Ayala (:dietrich) 2010-09-13 10:39:48 PDT
Created attachment 474734 [details] [diff] [review]
v6

fixed existing toolbar visibility/persistence mechanisms to support both toolboxes, and other fixes to mano comments.

still working on the test.
Comment 88 Dietrich Ayala (:dietrich) 2010-09-13 10:42:07 PDT
(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?
Comment 89 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-13 11:35:36 PDT
I can, but you'll need this for the final patch either way, imo.
Comment 90 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-13 11:43:11 PDT
The patch is attached on bug 595937.
Comment 91 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-13 11:45:52 PDT
(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.
Comment 92 Dietrich Ayala (:dietrich) 2010-09-13 13:04:17 PDT
pushed to the tryserver.
Comment 93 Gabriela [:gaby2300] 2010-09-13 13:24:37 PDT
(In reply to comment #92)
> pushed to the tryserver.

I hope you'll post the tryserver builds here so I can try them!
Comment 94 Dietrich Ayala (:dietrich) 2010-09-13 13:57:03 PDT
Created attachment 474815 [details] [diff] [review]
v7

* updates to mano's customization changes
* adds toolbar context menu to add-on bar
Comment 95 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-13 14:41:40 PDT
Comment on attachment 474815 [details] [diff] [review]
v7

r=mano
Comment 96 Dietrich Ayala (:dietrich) 2010-09-14 03:44:53 PDT
Created attachment 475037 [details] [diff] [review]
v7.1

minor changes, and finished the test, carrying review over. will check-in once i get try results back for this latest patch.
Comment 97 Dietrich Ayala (:dietrich) 2010-09-14 06:29:12 PDT
(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.
Comment 98 Dietrich Ayala (:dietrich) 2010-09-14 06:32:56 PDT
for those asking, tryserver builds show up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/?C=M;O=D
Comment 99 Dietrich Ayala (:dietrich) 2010-09-14 09:50:18 PDT
Created attachment 475113 [details] [diff] [review]
v7.2

* fixes addon bar test to work on tinderbox machines (slooooowwww)
* fixes private browsing popup blocker test
Comment 100 Dietrich Ayala (:dietrich) 2010-09-14 11:51:36 PDT
latest patch looks ok on try, a couple of unrelated known oranges (neither of which fail locally).
Comment 101 Tomas 2010-09-14 19:04:33 PDT
It is time to ask for r+ ?
Comment 102 John J. Barton 2010-09-14 20:23:26 PDT
Perhaps this bug could be marked for documentation since it will break a great many add-ons when it lands?
Comment 103 Philip Chee 2010-09-14 21:20:26 PDT
> 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?
Comment 104 John J. Barton 2010-09-14 22:04:00 PDT
(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.
Comment 105 Dietrich Ayala (:dietrich) 2010-09-15 06:43:37 PDT
Created attachment 475492 [details] [diff] [review]
v7.2 updated to tip
Comment 106 Dietrich Ayala (:dietrich) 2010-09-15 09:36:19 PDT
Created attachment 475545 [details]
example add-on (non-jetpack)

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.
Comment 107 Csaba Kozák [:WonderCsabo] 2010-09-15 09:58:41 PDT
And what about old non-jetpack addons? Will they show up on addons-bar?
Comment 108 Dietrich Ayala (:dietrich) 2010-09-15 10:05:44 PDT
(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 John J. Barton 2010-09-15 10:08:37 PDT
(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
Comment 110 Dietrich Ayala (:dietrich) 2010-09-15 10:31:03 PDT
(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.
Comment 111 Csaba Kozák [:WonderCsabo] 2010-09-15 12:25:25 PDT
(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.
Comment 112 Dietrich Ayala (:dietrich) 2010-09-15 12:35:10 PDT
That was a bug in an earlier version of the patch. I'll kick off a build with the latest version.
Comment 113 Csaba Kozák [:WonderCsabo] 2010-09-15 13:08:04 PDT
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
Comment 114 Dão Gottwald [:dao] 2010-09-15 13:10:52 PDT
(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>.
Comment 115 Csaba Kozák [:WonderCsabo] 2010-09-15 13:39:41 PDT
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)
Comment 116 Dietrich Ayala (:dietrich) 2010-09-15 23:08:23 PDT
(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.
Comment 117 Dietrich Ayala (:dietrich) 2010-09-15 23:18:00 PDT
landed: http://hg.mozilla.org/mozilla-central/rev/bb2db707bfcb

keeping this open while i watch the tree.
Comment 118 Dietrich Ayala (:dietrich) 2010-09-16 00:53:47 PDT
test is failing (popupshown listener isn't being called), but passes locally. will try to figure it out, and backout otherwise.
Comment 119 Dietrich Ayala (:dietrich) 2010-09-16 01:43:39 PDT
backed out: http://hg.mozilla.org/mozilla-central/rev/f86e1746ac0d
Comment 121 Markus Popp 2010-09-16 03:25:29 PDT
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 Paul [pwd] 2010-09-16 03:31:35 PDT
(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
Comment 123 Jim Jeffery not reading bug-mail 1/2/11 2010-09-16 04:21:15 PDT
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.
Comment 124 Dietrich Ayala (:dietrich) 2010-09-16 05:30:51 PDT
(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.
Comment 125 Dão Gottwald [:dao] 2010-09-16 05:36:50 PDT
Can we just put a non-removable <statusbar id="status-bar"/> on the add-on bar to ease the transition for add-ons?
Comment 126 Dietrich Ayala (:dietrich) 2010-09-16 06:07:32 PDT
(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.
Comment 127 Dietrich Ayala (:dietrich) 2010-09-16 06:09:07 PDT
(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.
Comment 128 Dão Gottwald [:dao] 2010-09-16 06:34:09 PDT
(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.
Comment 129 Dietrich Ayala (:dietrich) 2010-09-16 07:31:01 PDT
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#
Comment 130 David E. Ross 2010-09-16 15:46:15 PDT
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 flying sheep 2010-09-16 15:53:14 PDT
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.
Comment 132 Gabriela [:gaby2300] 2010-09-16 18:50:20 PDT
(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!
Comment 133 Dave Garrett 2010-09-17 07:06:53 PDT
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)
Comment 134 Csaba Kozák [:WonderCsabo] 2010-09-17 07:34:53 PDT
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. :(
Comment 135 Dão Gottwald [:dao] 2010-09-17 08:07:39 PDT
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 Michael Newton 2010-09-17 08:53:25 PDT
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 Dave Garrett 2010-09-17 09:20:55 PDT
(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 Philip Chee 2010-09-17 10:22:34 PDT
> 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 3e2224c2 2010-09-17 20:28:03 PDT
When this is going to land again? I want to test it and start adjusting my extensions for the next beta release.
Comment 140 Csaba Kozák [:WonderCsabo] 2010-09-18 00:08:02 PDT
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 3e2224c2 2010-09-18 10:48:50 PDT
(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/
Comment 142 Csaba Kozák [:WonderCsabo] 2010-09-18 10:55:49 PDT
According to the date, there are the new bug-free builds there. I dunno, i wont try them just in trunk.
Comment 143 3e2224c2 2010-09-18 11:27:40 PDT
The Addons bar is huge! Anyone knows if this will be the final design?
Comment 144 Gabriela [:gaby2300] 2010-09-18 16:25:40 PDT
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?
Comment 145 Nicolas Mandil (:NicolasWeb) 2010-09-18 16:29:40 PDT
(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 d.a. 2010-09-19 01:55:08 PDT
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 Filippo 2010-09-19 02:08:33 PDT
(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.
Comment 148 Please Ignore This Troll (Account Disabled) 2010-09-19 02:12:24 PDT
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 Paul [pwd] 2010-09-19 04:06:37 PDT
Can someone who is using the tryserver build please post a screenshot of what
this looks like.
Comment 150 Csaba Kozák [:WonderCsabo] 2010-09-19 07:46:53 PDT
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.
Comment 151 Csaba Kozák [:WonderCsabo] 2010-09-19 07:50:55 PDT
Sorry, my first image get totally screwed up...

http://i55.tinypic.com/1znllpy.png
Comment 152 3e2224c2 2010-09-19 08:01:41 PDT
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 Philip Chee 2010-09-19 08:19:52 PDT
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 Philip Chee 2010-09-19 08:20:59 PDT
> 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 155 Csaba Kozák [:WonderCsabo] 2010-09-19 08:22:10 PDT
Created attachment 476642 [details]
screenshot of current state on Windows
Comment 156 Paul [pwd] 2010-09-19 08:32:29 PDT
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 3e2224c2 2010-09-19 08:52:28 PDT
(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.
Comment 158 3e2224c2 2010-09-19 08:56:00 PDT
Created attachment 476645 [details]
screenshot of current state on Linux
Comment 159 Gabriela [:gaby2300] 2010-09-19 16:00:45 PDT
(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 Timofei Shatrov 2010-09-19 23:06:05 PDT
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.
Comment 161 Nicolas Mandil (:NicolasWeb) 2010-09-19 23:10:31 PDT
(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 ;-)
Comment 162 Nicolas Mandil (:NicolasWeb) 2010-09-19 23:24:43 PDT
(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 Timofei Shatrov 2010-09-19 23:30:07 PDT
(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.
Comment 164 Darren Kalck [:D-Kalck] 2010-09-19 23:43:44 PDT
(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 Timofei Shatrov 2010-09-20 04:39:07 PDT
(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.
Comment 166 Csaba Kozák [:WonderCsabo] 2010-09-20 05:50:58 PDT
Please read the dependencies of that bug, and take the hover target URL display conservation to those bugs. Thanks.
Comment 167 Paul [pwd] 2010-09-20 06:11:37 PDT
(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.
Comment 168 Csaba Kozák [:WonderCsabo] 2010-09-20 08:11:40 PDT
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.
Comment 169 Dietrich Ayala (:dietrich) 2010-09-21 05:33:38 PDT
Created attachment 477105 [details] [diff] [review]
v8 wip

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.
Comment 170 Paul [pwd] 2010-09-21 05:37:29 PDT
(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?
Comment 171 Dão Gottwald [:dao] 2010-09-21 05:39:23 PDT
(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 Philip Chee 2010-09-21 05:45:18 PDT
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.
Comment 173 Dão Gottwald [:dao] 2010-09-21 05:49:21 PDT
(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 Philip Chee 2010-09-21 05:55:55 PDT
> 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 .
Comment 175 Dietrich Ayala (:dietrich) 2010-09-21 08:29:27 PDT
(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.
Comment 176 Dietrich Ayala (:dietrich) 2010-09-21 08:44:12 PDT
Created attachment 477139 [details] [diff] [review]
v8

* 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.
Comment 177 Csaba Kozák [:WonderCsabo] 2010-09-21 08:46:02 PDT
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?
Comment 178 Dietrich Ayala (:dietrich) 2010-09-21 09:02:14 PDT
Created attachment 477149 [details]
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.
Comment 179 Csaba Kozák [:WonderCsabo] 2010-09-21 09:16:21 PDT
Created attachment 477155 [details]
screenshot on Windows

Screenshot on Windows, with Dao's dictionary addon and Sync toolbar button dragged from palette.
Comment 180 Dietrich Ayala (:dietrich) 2010-09-21 09:21:10 PDT
Comment on attachment 477155 [details]
screenshot on Windows

eewww. ok, clearly my css changes did not work across platforms!
Comment 181 Csaba Kozák [:WonderCsabo] 2010-09-21 09:25:31 PDT
What changes? What we should see?

Any reactions to comment 177? I met some problems with addons bar on Win.
Comment 182 Dietrich Ayala (:dietrich) 2010-09-21 11:26:34 PDT
(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.
Comment 183 Csaba Kozák [:WonderCsabo] 2010-09-21 11:29:26 PDT
(In reply to comment #182)
>
> depends. what build did you test?

Your latest win32 tryserver builds.
Comment 184 Csaba Kozák [:WonderCsabo] 2010-09-21 11:30:57 PDT
build.
Comment 185 Jennifer Morrow [:Boriss] (UX) 2010-09-21 12:11:18 PDT
(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.
Comment 186 Peter Henkel [:Terepin] 2010-09-21 12:31:01 PDT
(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 Paul [pwd] 2010-09-21 12:33:53 PDT
(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?
Comment 188 Peter Henkel [:Terepin] 2010-09-21 12:46:52 PDT
What makes you think I'm petitioning for anything?
Comment 189 Csaba Kozák [:WonderCsabo] 2010-09-21 13:27:45 PDT
(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.
Comment 190 Nicolas Mandil (:NicolasWeb) 2010-09-21 13:46:28 PDT
(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 ?
Comment 191 Csaba Kozák [:WonderCsabo] 2010-09-21 13:51:54 PDT
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 3e2224c2 2010-09-21 14:14:33 PDT
(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?
Comment 193 Csaba Kozák [:WonderCsabo] 2010-09-21 14:17:16 PDT
It will be, it's a beta7 blocker.
Comment 194 Alex Limi (:limi) — Firefox UX Team 2010-09-21 15:23:31 PDT
(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.
Comment 195 Csaba Kozák [:WonderCsabo] 2010-09-21 15:25:52 PDT
And what about the keyboard shortcut, what i already mentioned? That doesnt conflict with anything.
Comment 196 Dietrich Ayala (:dietrich) 2010-09-22 09:24:37 PDT
Update: wrestling with CSS on Windows, where I'm unable to override the border styles on embedded statusbarpanel elements for some reason.
Comment 197 patrickjdempsey 2010-09-22 09:44:08 PDT
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 Thomas Stache 2010-09-22 09:49:35 PDT
(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 Timofei Shatrov 2010-09-22 10:35:40 PDT
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?
Comment 200 Csaba Kozák [:WonderCsabo] 2010-09-22 10:45:14 PDT
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.
Comment 201 Dão Gottwald [:dao] 2010-09-22 11:21:02 PDT
(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.
Comment 202 Dietrich Ayala (:dietrich) 2010-09-22 11:43:20 PDT
Created attachment 477590 [details] [diff] [review]
v8.1
[Checked in: See comment 209+234]

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.
Comment 203 Dietrich Ayala (:dietrich) 2010-09-22 11:45:48 PDT
forgot to update whiteboard: mochitest other on tryserver looked fine.
Comment 204 David E. Ross 2010-09-22 12:33:28 PDT
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 flying sheep 2010-09-22 16:29:54 PDT
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 206 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2010-09-22 17:21:50 PDT
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.
Comment 207 Josh Matthews [:jdm] (on vacation until Dec 5) 2010-09-22 21:47:36 PDT
*** Bug 598848 has been marked as a duplicate of this bug. ***
Comment 208 Dão Gottwald [:dao] 2010-09-23 01:31:42 PDT
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
Comment 209 Dietrich Ayala (:dietrich) 2010-09-23 02:02:50 PDT
http://hg.mozilla.org/mozilla-central/rev/eec9a82ad740

fixed Dao's comment before checkin.
Comment 210 Dietrich Ayala (:dietrich) 2010-09-23 02:49:56 PDT
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
Comment 211 Dietrich Ayala (:dietrich) 2010-09-23 03:19:30 PDT
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.
Comment 213 Csaba Kozák [:WonderCsabo] 2010-09-23 04:21:42 PDT
Click it again. It's wrong in every second Options arrow click. Interesting.
Comment 214 Dietrich Ayala (:dietrich) 2010-09-23 04:27:28 PDT
> > 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.
Comment 215 Dietrich Ayala (:dietrich) 2010-09-23 04:32:37 PDT
Created attachment 477886 [details] [diff] [review]
followup
[Checked in: Comment 216]

followup to fix windows. landing to see if it fixes the test bustage. will get post-facto review from mano.
Comment 216 Dietrich Ayala (:dietrich) 2010-09-23 04:39:08 PDT
pushed followup: http://hg.mozilla.org/mozilla-central/rev/36a9ff4549cc
Comment 217 pal-moz 2010-09-23 04:44:40 PDT
(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.
Comment 218 Michael Monreal [:monreal] 2010-09-23 04:54:26 PDT
Created attachment 477887 [details]
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 Alice0775 White 2010-09-23 05:06:36 PDT
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);
Comment 220 Dietrich Ayala (:dietrich) 2010-09-23 05:08:52 PDT
(In reply to comment #219)
> in adittin to comment #217

the followup fixed this.
Comment 221 Gary [:streetwolf] 2010-09-23 05:40:42 PDT
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
Comment 222 Paul [pwd] 2010-09-23 06:04:59 PDT
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.
Comment 223 Dietrich Ayala (:dietrich) 2010-09-23 06:31:36 PDT
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.
Comment 224 Csaba Kozák [:WonderCsabo] 2010-09-23 06:33:52 PDT
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.
Comment 225 Paul [pwd] 2010-09-23 06:41:14 PDT
(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.
Comment 226 Csaba Kozák [:WonderCsabo] 2010-09-23 07:40:42 PDT
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?
Comment 227 flying sheep 2010-09-23 08:04:53 PDT
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 Paul [pwd] 2010-09-23 08:26:30 PDT
(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.
Comment 229 3e2224c2 2010-09-23 09:42:16 PDT
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.
Comment 230 Paul [pwd] 2010-09-23 09:58:53 PDT
(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 flying sheep 2010-09-23 10:29:27 PDT
(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 Markus Popp 2010-09-23 10:45:01 PDT
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.
Comment 233 Johnathan Nightingale [:johnath] 2010-09-23 10:47:43 PDT
(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.
Comment 234 Dietrich Ayala (:dietrich) 2010-09-23 10:59:06 PDT
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.
Comment 235 Csaba Kozák [:WonderCsabo] 2010-09-23 11:11:47 PDT
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=599029 .
Comment 236 d.a. 2010-09-23 11:39:23 PDT
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?
Comment 238 Peter Henkel [:Terepin] 2010-09-23 11:49:34 PDT
No need for add-on, PL will cover that.
Comment 239 Csaba Kozák [:WonderCsabo] 2010-09-23 11:55:57 PDT
Nope. Progress lines dont show what the browser is downloading currently.

BTW, this feature wont be a big miss for average users.
Comment 241 Timofei Shatrov 2010-09-23 12:11:13 PDT
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 d.a. 2010-09-23 12:12:34 PDT
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.
Comment 243 Csaba Kozák [:WonderCsabo] 2010-09-23 12:18:06 PDT
See Bug 598973 .
Comment 244 Reed Loden [:reed] (use needinfo?) 2010-09-23 12:36:03 PDT
(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 Fritz 2010-09-23 13:46:30 PDT
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.
Comment 246 Josh Tumath 2010-09-23 13:55:35 PDT
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 247 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-09-23 14:55:39 PDT
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.
Comment 248 David E. Ross 2010-09-25 11:02:29 PDT
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 Philip Chee 2010-09-25 12:09:48 PDT
David,

This is a Firefox bug. The Web Console is Firefox 4.0b7 only.
Comment 250 Tyler Downer [:Tyler] 2010-09-25 12:35:43 PDT
*** Bug 599644 has been marked as a duplicate of this bug. ***
Comment 251 juan becerra [:juanb] 2010-09-29 16:55:24 PDT
*** Bug 599766 has been marked as a duplicate of this bug. ***
Comment 252 Kevin Ar18 2010-10-14 13:53:50 PDT
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?
Comment 253 Csaba Kozák [:WonderCsabo] 2010-10-14 13:59:57 PDT
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 3e2224c2 2010-10-15 18:51:30 PDT
(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.
Comment 255 Mardeg 2010-10-16 20:40:44 PDT
*** Bug 512137 has been marked as a duplicate of this bug. ***
Comment 256 Eric Shepherd [:sheppy] 2010-11-01 11:42:16 PDT
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. :)
Comment 257 Please Ignore This Troll (Account Disabled) 2010-11-01 11:49:41 PDT
(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.
Comment 258 Eric Shepherd [:sheppy] 2010-11-01 11:52:54 PDT
Documented, then:

https://developer.mozilla.org/en/The_add-on_bar
Comment 259 Eric Shepherd [:sheppy] 2010-11-01 11:53:26 PDT
Except of course we need to go through scads of old documentation and clean it up for this. Ugh.
Comment 260 Dietrich Ayala (:dietrich) 2010-11-01 11:55:32 PDT
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 flying sheep 2010-11-01 15:54:05 PDT
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 patrickjdempsey 2010-11-01 18:23:25 PDT
(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?
Comment 263 Dietrich Ayala (:dietrich) 2010-11-02 01:58:22 PDT
(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.
Comment 264 John A. Bilicki III 2010-12-22 15:15:08 PST
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.
Comment 265 [not reading bugmail] 2010-12-22 16:28:12 PST
(In reply to comment #264)

I believe you want bug 599212.
Comment 266 David E. Ross 2010-12-22 18:12:19 PST
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.
Comment 267 John A. Bilicki III 2010-12-22 18:29:54 PST
(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.
Comment 268 John A. Bilicki III 2010-12-22 19:06:52 PST
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?
Comment 269 Csaba Kozák [:WonderCsabo] 2010-12-23 00:15:21 PST
(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 Kevin Ar18 2010-12-23 08:42:39 PST
(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 flying sheep 2010-12-23 10:02:14 PST
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 Timofei Shatrov 2010-12-23 10:32:19 PST
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 Dave Garrett 2010-12-23 13:09:04 PST
(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.
Comment 274 Virtual_ManPL [:Virtual] - (ni? me) 2010-12-23 15:24:17 PST
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 flying sheep 2010-12-23 15:33:34 PST
(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?
Comment 276 Gabriela [:gaby2300] 2010-12-23 15:55:43 PST
(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!
Comment 277 [not reading bugmail] 2010-12-23 19:11:20 PST
(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.
Comment 278 John A. Bilicki III 2010-12-23 19:17:26 PST
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.
Comment 279 [not reading bugmail] 2010-12-23 19:41:13 PST
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 patrickjdempsey 2010-12-23 22:48:02 PST
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.
Comment 281 John A. Bilicki III 2010-12-25 00:19:18 PST
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.
Comment 282 Please Ignore This Troll (Account Disabled) 2011-01-05 01:42:31 PST
(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.
Comment 283 Peter Henkel [:Terepin] 2011-01-05 01:47:53 PST
(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.
Comment 284 Csaba Kozák [:WonderCsabo] 2011-01-05 01:49:54 PST
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
Comment 285 Peter Henkel [:Terepin] 2011-01-05 01:52:00 PST
Good for us, bad for him. :)
Comment 287 Please Ignore This Troll (Account Disabled) 2011-01-05 01:54:19 PST
(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.
Comment 288 Csaba Kozák [:WonderCsabo] 2011-01-05 01:58:48 PST
(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.
Comment 291 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-05 06:00:32 PST
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...
Comment 293 Alex Limi (:limi) — Firefox UX Team 2011-01-05 17:20:12 PST
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 al_9x 2011-01-05 18:50:40 PST
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?
Comment 295 John A. Bilicki III 2011-01-06 21:01:15 PST
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 flying sheep 2011-01-07 05:55:41 PST
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.
Comment 297 Please Ignore This Troll (Account Disabled) 2011-01-07 07:59:30 PST
(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.
Comment 298 Please Ignore This Troll (Account Disabled) 2011-01-07 08:23:18 PST
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.
Comment 299 Please Ignore This Troll (Account Disabled) 2011-01-07 08:36:49 PST
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 flying sheep 2011-01-08 15:49:58 PST
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.
Comment 301 Please Ignore This Troll (Account Disabled) 2011-01-09 06:28:35 PST
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 flying sheep 2011-01-09 06:51:43 PST
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.
Comment 303 Please Ignore This Troll (Account Disabled) 2011-01-09 07:06:32 PST
(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.
Comment 304 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-09 07:34:14 PST
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...
Comment 305 John A. Bilicki III 2011-01-09 14:00:11 PST
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 flying sheep 2011-01-09 14:33:38 PST
(In reply to comment #305)
> 2.) Continue to spread the word that Firefox is intentionally being destroyed
> in order to make it increasingly difficult for the average user to use.

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

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

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

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

e.g.: the tabs are on top to indicate that every ui element below it belong to and controll the current tab.
Comment 307 John A. Bilicki III 2011-01-09 15:30:49 PST
> who the **** thinks firefox is more complicated to use now that information was
> removed which the majority of the people never cared about?

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

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

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

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

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

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

2.) Status in a left-to-right top-to-bottom language like English is typically BELOW the item it is the status for. A picture of a person is the object that naturally exists so the status (their name) is traditionally below their picture as the name exists second to the person existing. The status exists secondly because the page in the link exists before it thus implying the need for the status.
Comment 308 Henrik Skupin (:whimboo) 2011-01-27 15:14:28 PST
Marking as verified fixed based on its landing a couple of months ago.
Comment 309 Vlad [QA] 2011-04-05 04:42:41 PDT
Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Comment 310 Andreas Eibach 2012-05-16 16:53:39 PDT
(In reply to flying sheep from comment #306)
1. who misses any of the old statusbar widgets can install status4evar (as it was said several times in this report):

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

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

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

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

Correct. People want the good ol' style back. No compromises or approximations, but the real thing.
Comment 311 flying sheep 2012-05-18 01:29:14 PDT
umm, customization is a feature of firefox. nobody is “left alone” if they are missing the status bar, but get it back immediately after typing “status bar” in the addon search bar and install the 5th search result.

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

i’m pretty sure that the amount of people who are angry with the gone status bar is limited to those who leave angry 5-star ratings on status-4-evar. the rest is happy without the status bar. it’s gone, but not without leaving you the choice to get it back. live with it, what else could you want?
Comment 312 John A. Bilicki III 2012-05-18 04:27:33 PDT
@flying sheep

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

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

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

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

could you please stop conjuring needless drama and shut up?
Comment 317 John A. Bilicki III 2013-07-04 11:34:37 PDT
Flyrin Sheep, you should join Mozilla, you'd fit in with the Firefox-hating crowd just fine!

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

Note You need to log in before you can comment on or make changes to this bug.