replacing the status bar with the add-on bar

18 views
Skip to first unread message

Dietrich Ayala

unread,
Sep 16, 2010, 10:24:43 AM9/16/10
to devapps
Moving conversation from bug 574688 to DAF for broader feedback.

(In reply to comment #128)
>
> > 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.

As you say below, if users care enough, they'll ask the developers of
their add-ons to update. And we shouldn't coddle developers who care
so little about their users. That leads to an unhealthy ecosystem
where the development of Firefox slows because we don't ever want to
ask add-on developers to make any changes at all.

We're just moving to toolbar XUL/APIs, which have been around for a
very long time. We are generally very careful about not breaking
add-on code, but occasionally it's going to happen. We'll help as much
as we can, with blog posts and MDC pages and code samples, but yeah
sometimes they're going to have to do a little work. Luckily, it's
rare.

> > 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.

Sorry, my mistake - yes script changes are likely required. I said
that earlier, and didn't intend to simplify it when answering you.
Regardless, the changes are absolutely not the lunatic fringe of
add-on development. Toolbar button development is very well-trodden
ground.

> > 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.

You are not the target audience of this development, so whether you as
a user cares bears little weight here - as developers, we do not
adequately represent the majority of Firefox users. Also, your
argument works both ways: If users care, they'll prompt their add-on
developers to update to use the add-on bar.

With regard to enforcing vs providing the tools - I think it's our
responsibility to provide a development environment that encourages
add-on developers to do things in ways that are friendly to users. On
rare occasion we need to take painful steps to do this, in order to
re-orient for the next few years.

Also, the tools are still there for add-on devs to add a status bar
back for the themselves to be added to, if they really want to, and
they think it's the best thing for their users.

johnjbarton

unread,
Sep 16, 2010, 11:01:43 AM9/16/10
to
On 9/16/2010 7:24 AM, Dietrich Ayala wrote:
> Moving conversation from bug 574688 to DAF for broader feedback.
>
> (In reply to comment #128)
>>
>>> 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.
>
> As you say below, if users care enough, they'll ask the developers of
> their add-ons to update. And we shouldn't coddle developers who care
> so little about their users. That leads to an unhealthy ecosystem
> where the development of Firefox slows because we don't ever want to
> ask add-on developers to make any changes at all.

What leads to an unhealthy ecosystem is gratuitous comments about how
much addon developers care about their users. I don't think you are in
any danger of coddling add-on developers so you don't need to worry
about that.

>
> We're just moving to toolbar XUL/APIs, which have been around for a
> very long time. We are generally very careful about not breaking
> add-on code, but occasionally it's going to happen. We'll help as much
> as we can, with blog posts and MDC pages and code samples, but yeah
> sometimes they're going to have to do a little work. Luckily, it's
> rare.

As pointed out on the bug, the issue here is not breaking changes, it's
making this change way late in the beta process. It does not help that
it seems to be an improvement of almost no consequence to users, since
the new addon tool bar will be in the same place and size as the statusbar.

Badgering add-on developers to update during the beta phase but making
breaking changes at b7 is the issue here. Going on the counter attack
does not help us feel better about it.

jjb

Dao

unread,
Sep 16, 2010, 11:05:12 AM9/16/10
to
On 16.09.2010 16:24, Dietrich Ayala wrote:
> As you say below, if users care enough, they'll ask the developers of
> their add-ons to update. And we shouldn't coddle developers who care
> so little about their users.

I find this almost offending. I'm an add-on developer myself and very
much care about my users. When they'll beg me to make my status bar item
customizable I will consider this, but right now this isn't worth my time.

> That leads to an unhealthy ecosystem
> where the development of Firefox slows because we don't ever want to
> ask add-on developers to make any changes at all.

This doesn't really have much to do with the topic. An empty <statusbar
id="status-bar"/> bears close to zero maintaining cost and wouldn't slow
development of Firefox down. The fact that we can and should ask add-on
developers to make changes from time to time doesn't justify each
particular case.

> We're just moving to toolbar XUL/APIs, which have been around for a
> very long time.

Doesn't make them less painful. The XUL overlay for the status-bar is
super easy, hard to beat.

> You are not the target audience of this development, so whether you as
> a user cares bears little weight here - as developers, we do not
> adequately represent the majority of Firefox users. Also, your
> argument works both ways: If users care, they'll prompt their add-on
> developers to update to use the add-on bar.

Right, that's exactly what I said. Users will do that when they feel
strongly about it, so we don't need to.

> With regard to enforcing vs providing the tools - I think it's our
> responsibility to provide a development environment that encourages
> add-on developers to do things in ways that are friendly to users. On
> rare occasion we need to take painful steps to do this, in order to
> re-orient for the next few years.

I'm all for encouraging them. As I understand it, "encouraging" would
mean to provide the tools (better versions of them, really) rather than
enforcing them.

> Also, the tools are still there for add-on devs to add a status bar
> back for the themselves to be added to, if they really want to, and
> they think it's the best thing for their users.

This misses the point. I'm not suggesting we put the status bar as we
know it in the add-on bar, which an add-on could do of course. I'm
suggesting we keep an empty <statusbar id="status-bar"/> as an overlay
target.

Dietrich Ayala

unread,
Sep 16, 2010, 11:45:52 AM9/16/10
to
On Sep 16, 10:01 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> What leads to an unhealthy ecosystem is gratuitous comments about how
> much addon developers care about their users. I don't think you are in
> any danger of coddling add-on developers so you don't need to worry
> about that.

It wasn't gratuitous at all. I was responding to Dao's assertion that
we will all just drop development of our add-ons because of this
change. To do that seems to me to not care very much.

> As pointed out on the bug, the issue here is not breaking changes, it's
> making this change way late in the beta process. It does not help that
> it seems to be an improvement of almost no consequence to users, since
> the new addon tool bar will be in the same place and size as the statusbar.

It's also collapsed by default, if there are no add-ons installed
there. Which is a difference for a lot of users.

> Badgering add-on developers to update during the beta phase but making
> breaking changes at b7 is the issue here. Going on the counter attack  
> does not help us feel better about it.

We're all here working to make a better Firefox. No one is trying to
attack anyone. And I'm not on some personal crusade here. I'm working
on a bug that's part of the bigger plan for the Fx4 theme, that lots
of people put thought into, and Boriss blogged about a bunch of times.

al...@yahoo.com

unread,
Sep 16, 2010, 11:47:23 AM9/16/10
to
What about native Fx status bar content:

1) Navigation progress messages
2) Navigation progress bar (still needed as tab bar can be hidden)
3) Link addresses

I take it these are not meant for the add-on bar? These are very useful and
should be retained. Why must the status bar be removed?


Dietrich Ayala

unread,
Sep 16, 2010, 11:59:04 AM9/16/10
to
Hm, my reply to this got eaten by google groups somehow... Re-trying:

On Sep 16, 10:05 pm, Dao <d...@design-noir.de> wrote:
> I find this almost offending. I'm an add-on developer myself and very
> much care about my users. When they'll beg me to make my status bar item
> customizable I will consider this, but right now this isn't worth my time.

I'm an add-on developer too. You cut out the part I was responding to,
where you said add-on devs (you and me!) will drop all development of
their add-ons because of this change, which is pretty crappy to their
users. I'm glad you're not one of those people you were talking
about :)

> I'm all for encouraging them. As I understand it, "encouraging" would
> mean to provide the tools (better versions of them, really) rather than
> enforcing them.

The SDK makes it easy to build customizable add-ons. So does the
toolbar code. We're only changing the way add-ons get onto the bar.
It's not really that hard. You're acting like we making everyone
switch to Java or something.

> > Also, the tools are still there for add-on devs to add a status bar
> > back for the themselves to be added to, if they really want to, and
> > they think it's the best thing for their users.
>
> This misses the point. I'm not suggesting we put the status bar as we
> know it in the add-on bar, which an add-on could do of course. I'm
> suggesting we keep an empty <statusbar id="status-bar"/> as an overlay
> target.

I feel like we're still in the same situation, where it's a block of
things the user can't move around or change if they want to. Maybe if
we wrapped it in a toolbaritem. But then users are wondering why the
heck they can only move these unrelated add-ons as a block.

Dietrich Ayala

unread,
Sep 16, 2010, 12:01:58 PM9/16/10
to
On Sep 16, 10:47 pm, <al...@yahoo.com> wrote:
> What about native Fx status bar content:
>
> 1) Navigation progress messages
> 2) Navigation progress bar (still needed as tab bar can be hidden)
> 3) Link addresses
>
> I take it these are not meant for the add-on bar?  These are very useful and
> should be retained.

They've all been moved to the navigation area in Firefox 4, where your
eyes are already spending time in those types of activities.

>  Why must the status bar be removed?

The status bar is not being removed, it's being replaced by a toolbar
that's in the same location. There are previous threads in this list
about it.

Thomas Stache

unread,
Sep 16, 2010, 12:04:52 PM9/16/10
to dev-apps...@lists.mozilla.org
On 16.09.2010 17:47, al...@yahoo.com wrote:
> What about native Fx status bar content:
>
> 1) Navigation progress messages

I never felt these were helpful, nowadays they mostly notify about 3rd
party scripts and resources being loaded. The fraction-of-a-second
"Connecting" message is also not meaningful for most users.

> 2) Navigation progress bar (still needed as tab bar can be hidden)

Is in the Location Bar since last nightly.

> 3) Link addresses

Is in the Location Bar since last nightly.

>
> I take it these are not meant for the add-on bar? These are very useful and
> should be retained. Why must the status bar be removed?

Because the UX and visual designers and the product management decided
to have it. Firefox development is no democracy.

al...@yahoo.com

unread,
Sep 16, 2010, 1:10:28 PM9/16/10
to
"Dietrich Ayala" <auto...@gmail.com> wrote in message
news:82a3746b-e747-4037...@g21g2000prn.googlegroups.com...

On Sep 16, 10:47 pm, <al...@yahoo.com> wrote:
> What about native Fx status bar content:
>
> 1) Navigation progress messages
> 2) Navigation progress bar (still needed as tab bar can be hidden)
> 3) Link addresses
>
> I take it these are not meant for the add-on bar? These are very useful
> and
> should be retained.

They've all been moved to the navigation area in Firefox 4, where your
eyes are already spending time in those types of activities.

_________________________________________________________

I just tried the latest minefield

1) Navigation progress messages are still in the status bar, if you remove
it, where are they going to go?

To answer another comment, they are absolutely useful, especially if there
is a problem/slowdown, you can tell at what stage it is: dns, connection,
retrieval

2) The new progress bar (thin blue line along the bottom border of the
urlbar) especially when it flashes quickly, looks more like a visual
glitch/artifact. It's too thin and too long, barely recognizable as a
progress bar.


Alexander Limi

unread,
Sep 16, 2010, 1:58:32 PM9/16/10
to al...@yahoo.com, dev-apps...@lists.mozilla.org
On Thu, Sep 16, 2010 at 10:10 AM, <al...@yahoo.com> wrote:

> I just tried the latest minefield
>
> 1) Navigation progress messages are still in the status bar, if you remove
> it, where are they going to go?
>
> To answer another comment, they are absolutely useful, especially if there
> is a problem/slowdown, you can tell at what stage it is: dns, connection,
> retrieval
>

The progress bar will show these. Right now it doesn't show the DNS/server
lookup stage, but that's planned.


> 2) The new progress bar (thin blue line along the bottom border of the
> urlbar) especially when it flashes quickly, looks more like a visual
> glitch/artifact. It's too thin and too long, barely recognizable as a
> progress bar.
>

We're still experimenting with the look here, I agree that it's too subtle
and doesn't work the way we want it to, yet. This late in the betas we have
to land things gradually and add polish a bit later. There's a lot of visual
tweaks we can do to improve it significantly, and Stephen Horlander is
experimenting with some additional treatments.

--
Alexander Limi · Firefox UX Team · http://twitter.com/limi · http://limi.net

Alexander Limi

unread,
Sep 16, 2010, 2:06:08 PM9/16/10
to al...@yahoo.com, dev-apps...@lists.mozilla.org
On Thu, Sep 16, 2010 at 10:58 AM, Alexander Limi <li...@mozilla.com> wrote:

> The progress bar will show these. Right now it doesn't show the DNS/server
> lookup stage, but that's planned.
>

And here's an animation showing it:
http://www.stephenhorlander.com/pages/progress-bar-line-mockup/progress-bar-line-states.html

al...@yahoo.com

unread,
Sep 16, 2010, 2:30:36 PM9/16/10
to

I am asking about the the textual progress messages currently shown in
the status bar. looking up, connecting, transferring, done, etc...

How can the thin progress line show them? This animation shows
different modes of progress line flashing

Are you trying to say that this obfuscated light show is supposed to
take their place?

Dao

unread,
Sep 16, 2010, 3:00:36 PM9/16/10
to
On 16.09.2010 17:59, Dietrich Ayala wrote:
> On Sep 16, 10:05 pm, Dao <d...@design-noir.de> wrote:
>> I find this almost offending. I'm an add-on developer myself and very
>> much care about my users. When they'll beg me to make my status bar item
>> customizable I will consider this, but right now this isn't worth my time.
>
> I'm an add-on developer too. You cut out the part I was responding to,
> where you said add-on devs (you and me!) will drop all development of
> their add-ons because of this change, which is pretty crappy to their
> users. I'm glad you're not one of those people you were talking
> about :)

Dropping is always going to be an option. I do want to support my users,
but there's only that much time I can invest. Even if I had the time it
would better be spent on features my users have asked me for. My users
haven't asked for the UI item to be movable yet, so the cost/benefit
ratio of making my add-on support this seems pretty bad.

>> I'm all for encouraging them. As I understand it, "encouraging" would
>> mean to provide the tools (better versions of them, really) rather than
>> enforcing them.
>
> The SDK makes it easy to build customizable add-ons. So does the
> toolbar code. We're only changing the way add-ons get onto the bar.
> It's not really that hard. You're acting like we making everyone
> switch to Java or something.

It seems like you're still underestimating the pain that's involved with
customizable toolbars. I keep minusing patches because our own
developers miss things related to that.
The SDK makes it easy to add the UI item but in my case it doesn't help
me much with the underlying code, so switching to that has a
non-neglectable cost similar to dealing with the customizable toolbar.

>>> Also, the tools are still there for add-on devs to add a status bar
>>> back for the themselves to be added to, if they really want to, and
>>> they think it's the best thing for their users.
>>
>> This misses the point. I'm not suggesting we put the status bar as we
>> know it in the add-on bar, which an add-on could do of course. I'm
>> suggesting we keep an empty <statusbar id="status-bar"/> as an overlay
>> target.
>
> I feel like we're still in the same situation, where it's a block of
> things the user can't move around or change if they want to.

It's not the same situation in that we offer customizability for the
add-on bar. Add-on developers can take advantage of this when the
benefit outweighs the cost for them. Meanwhile we should lower the cost,
i.e. work on a sane API for extending customizable toolbars, ideally as
trivial as XUL overlays.

EE

unread,
Sep 16, 2010, 3:12:36 PM9/16/10
to

Are you saying that there will be no status bar? It is very useful to
be able to see where a link will go before you click it. Why destroy
that capability?

Johnathan Nightingale

unread,
Sep 16, 2010, 3:31:46 PM9/16/10
to Dao, Dietrich Ayala, dev-apps-firefox
On 16-Sep-10, at 12:00 PM, Dao wrote:

> On 16.09.2010 17:59, Dietrich Ayala wrote:
>> I'm an add-on developer too. You cut out the part I was responding
>> to,
>> where you said add-on devs (you and me!) will drop all development of
>> their add-ons because of this change, which is pretty crappy to their
>> users. I'm glad you're not one of those people you were talking
>> about :)
>
> Dropping is always going to be an option. I do want to support my
> users,
> but there's only that much time I can invest. Even if I had the time
> it
> would better be spent on features my users have asked me for. My users
> haven't asked for the UI item to be movable yet, so the cost/benefit
> ratio of making my add-on support this seems pretty bad.
>

>> The SDK makes it easy to build customizable add-ons. So does the
>> toolbar code. We're only changing the way add-ons get onto the bar.
>> It's not really that hard. You're acting like we making everyone
>> switch to Java or something.
>
> It seems like you're still underestimating the pain that's involved
> with
> customizable toolbars. I keep minusing patches because our own
> developers miss things related to that.
> The SDK makes it easy to add the UI item but in my case it doesn't
> help
> me much with the underlying code, so switching to that has a
> non-neglectable cost similar to dealing with the customizable toolbar.


I love me some technical debate, but this feels like people gainsaying
each other. I hold these truths to be self-evident:

1) There is a cost for addons to migrate - it's not free. I don't
think it's likely to be *very* expensive for most addon authors, but
it's not free either.
2) This isn't a capricious nor a malicious change - it is a deliberate
attempt to put ourselves on better design footing long term, and the
pain that it involves has been part of that calculus.

I don't think the outcome of this thread where we feel grumpy or
defensive with each other is a good one. Here are some outcomes I
would dearly like more, I wonder how people feel about working towards
them?

Outcome: A pointer to clear migration guidelines that speak to the 80%
case(s) for addon authors just looking to get the minimum done.
Outcome: Alternate, constructive suggestions for how to preserve the
intent of Truth #2 while minimizing migration pain

I know the outcome that some people are working for in this thread is
to just kill the change altogether. We're not going to get to that
outcome by just dismissing the work of the people who have gotten us
this far, though.

Anyone feel like working on the constructive outcomes? Are they
perhaps already done and I haven't seen them?

J

---
Johnathan Nightingale
Director of Firefox Development
joh...@mozilla.com


Matthew Turnbull

unread,
Sep 16, 2010, 3:32:18 PM9/16/10
to dev-apps...@lists.mozilla.org
Links targets will be shown in the location bar.
https://bugzilla.mozilla.org/show_bug.cgi?id=587908

On 09/16/2010 03:12 PM, EE wrote:
> Are you saying that there will be no status bar? It is very useful to
> be able to see where a link will go before you click it. Why destroy
> that capability?

--
Bluefang-Logic Networks:

Scaled for your pleasure.

Dietrich Ayala

unread,
Sep 16, 2010, 3:47:02 PM9/16/10
to Johnathan Nightingale, Dao, dev-apps-firefox
> Outcome: A pointer to clear migration guidelines that speak to the 80%
> case(s) for addon authors just looking to get the minimum done.

I've got this going, will try to finish it up tomorrow.

Dao

unread,
Sep 16, 2010, 3:49:47 PM9/16/10
to
I proposed putting a stub <statusbar> element on the add-on bar so
add-ons overlaying the statusbar would magically continue to work. This
was supposed to be a constructive proposal. It would kill the
sledgehammer attitude of the change but not the change itself.

al...@yahoo.com

unread,
Sep 16, 2010, 4:40:10 PM9/16/10
to
On 9/16/2010 12:01 PM, Dietrich Ayala wrote:
> On Sep 16, 10:47 pm,<al...@yahoo.com> wrote:
>> What about native Fx status bar content:
>>
>> 1) Navigation progress messages
>> 2) Navigation progress bar (still needed as tab bar can be hidden)
>> 3) Link addresses
>>
>> I take it these are not meant for the add-on bar? These are very useful and
>> should be retained.
>
> They've all been moved to the navigation area in Firefox 4, where your
> eyes are already spending time in those types of activities.
>

Can you please clarify what are the plans for the textual navigation
progress messages? The answer that has been provided "The progress bar
will show these." is not clear.

Alex Faaborg

unread,
Sep 16, 2010, 4:46:10 PM9/16/10
to dev-apps...@lists.mozilla.org
From a UX perspective we are in the process of migrating all existing
Firefox functionality from the status bar so that we can create a place that
add-on authors can call their own (and we can create an open area where
users can add a very large number of add-ons). Some of these changes have
landed already, and some are still coming, so here is a quick review just to
bring everyone up to speed:

1) progress bar: This has been moved to the location bar, so that it has a
close mapping to the controls that effect progress (stop, reload), and the
thing that the progress relates to (the URL)

2) hyperlink target on hover: This has been moved to the right side of the
location bar since so that it can visually convey to the user that they are
about to shift from location A to location B. This should also help to
reinforce to users that the location bar is the place for them to inspect
location information.

3) status text (trying to connect vs. trying and being successful): This
hasn't landed yet, but our plan is to visually convey a difference between
Firefox trying (and failing) and Firefox trying (and succeeding). An
example of this difference in another product is how the throbber in Chrome
spins backwards in grey, and then forwards in blue. There are a number of
ways for us to represent this difference visually, and we feel that in
general they make more sense than a blur of text that changes so quickly
it's impossible for a human to actually read.

4) popups blocked: Initially we will just be relying on the notification
bars to provide users with access to blocked pop-ups. We've found that
currently a lot of users don't actually realize that they also have access
to blocked popups from the status bar, so this redundant access isn't likely
to be extremely missed. Future work on our popup blocking interface can be
found in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=588317

5) lock icon: During development of Firefox 3 we decided to switch our SSL
interface away from being about "security" towards being about "identity."
The rationale was that users are interpreting the lock icon to mean "good"
when in reality it might just mean that you have an encrypted connection to
criminals. We switched to having the site identity block, and using
stronger but still neutral colors for SSL (blue). Having the lock icon
persist in the status bar was a somewhat strange compromise that didn't
really mesh with our overall strategy of wanting users to focus on who they
were actually communicating with, instead of relying on a potentially false
metaphor.

6) download status: This work is still in progress, but Limi has a good post
about our future plans for our downloading interface here:
http://limi.net/articles/improving-download-behaviors-web-browsers/
In the meantime, each OS provides an indicator of downloads being complete
(task bar item glowing, dock icon bouncing, panel notification appearing).
To monitor the progress of the download in real time, the user can view the
download progress bar in the separate downloads window. This information
does not really need to be redundant in our interface.

That should be everything, but if I missed any of the current functionality
of the status bar please let us know.

-Alex

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

gavin

unread,
Sep 16, 2010, 4:48:46 PM9/16/10
to
On Sep 16, 3:49 pm, Dao <d...@design-noir.de> wrote:
> I proposed putting a stub <statusbar> element on the add-on bar so
> add-ons overlaying the statusbar would magically continue to work.

This sounds like a good proposal to me. It would mean that some addons
will continue to work without modification, while still allowing
addons to make use of the new system to offer additional
functionality. I'm not sure I understand the opposition to it - it
would mean that we're not "forcing" addons to implement the
customizability (by breaking them if they don't), but I don't think
the benefits to customizability are important enough to clearly and
obviously outweigh the costs of extensions breaking (for both users
and developers, at this stage in the release cycle, etc.).

Gavin

Peter Lairo

unread,
Sep 16, 2010, 5:12:27 PM9/16/10
to
I've seen what the new link-in-the-URL-bar looks like, and I must say
that I don't like it, at all. Before I explain why, here's what the URL
bar looks like in the current nightly build: You (often) have the
largish site identity area (taking up space - you'll see the
significance in a second), then you have the actual URL, and then - when
you hover over a link - the URL gets *truncated* and a right-pointing
triangle (">") (whose meaning is not clear enough to novices) appears
(BTW: often with too much empty space after the URL - aha, because it's
right-aligned = confusing), and after that is the URL of the link
target, which is in a *harder to see gray* and - more importantly -
which is *also truncated*. I think that too much stuff is being crammed
into the URL bar - all in a needless crusade to eliminate the Status
Bar, which has what, a "whopping" height of 20 pixels. And which can be
turned off by vertical-space-desirees.

I also think that *many* add-on developers (incl. prominent add-ons such
as AdBlockPlus, ForecastFox, etc.) will be making the (new) "Status Bar"
*visible* again, and thus making the impact of the problematic URL Bar
even less necessary.

Removing the Status Bar and putting the kitchen sink into the URL Bar
are nice *sounding* ideas, to be sure. But the inevitable implementation
is a confusing and less usable UI-mess. What normal user is supposed to
understand all that information crammed into one place? Especially if
their Status Bar is there, and empty, except for their favorite add-on.

BTW: Why was the (otherwise cool) page-loading-progress-bar but on the
*bottom* of the URL-Bar? I almost didn't notice it there (until I *read*
about it). Have you tried putting it on the *top* of the URL Bar for a
few days in the nightly builds, to *see* if that might be better?


On Thu. 16.09.2010 21:32, Matthew Turnbull wrote:
> Links targets will be shown in the location bar.
> https://bugzilla.mozilla.org/show_bug.cgi?id=587908
>
> On 09/16/2010 03:12 PM, EE wrote:
>> Are you saying that there will be no status bar? It is very useful to
>> be able to see where a link will go before you click it. Why destroy
>> that capability?
>

--
Regards,

Peter Lairo

Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444

Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis

al...@yahoo.com

unread,
Sep 16, 2010, 5:13:39 PM9/16/10
to
"Alex Faaborg" <faa...@mozilla.com> wrote in message
news:mailman.3670.1284669980...@lists.mozilla.org...

> 3) status text (trying to connect vs. trying and being successful): This
> hasn't landed yet, but our plan is to visually convey a difference between
> Firefox trying (and failing) and Firefox trying (and succeeding). An
> example of this difference in another product is how the throbber in
> Chrome
> spins backwards in grey, and then forwards in blue. There are a number of
> ways for us to represent this difference visually, and we feel that in
> general they make more sense than a blur of text that changes so quickly
> it's impossible for a human to actually read.
>

Please do not kill this functionality. It shows precisely what stage the
connection is in (name lookup, connecting, transfer ...) which is most
useful when things are slow/timing out/failing. Then it's not a blur of
text but quite readable. A bunch of flashing lights can't come close to
this in utility and clarity. You could make the status text stream a
customization widget, draggable to the new add-on bar.

This seems to come up again and again. Simplifying/dumbing-down the
interface for default use should not necessitate killing the useful features
people had grown accustomed to.


John J Barton

unread,
Sep 16, 2010, 5:57:22 PM9/16/10
to
Johnathan Nightingale wrote:
>
> Outcome: A pointer to clear migration guidelines that speak to the 80%
> case(s) for addon authors just looking to get the minimum done.

(In the interest of maximum team work, perhaps you could just leave off
"...just looking to get the minimum done." We're talking about folks who
are just about as far from lazy as one can imagine).

In addition to migration we need to know how to deal with multiple
versions. What will happen in FF4 if we leave the statusbar XUL in place
(for FF3.6)? Maybe it's all fine? I don't know.

> Outcome: Alternate, constructive suggestions for how to preserve the
> intent of Truth #2 while minimizing migration pain

I don't know what you mean here, but here are some suggestions:
1) Ship FF with statusbar collapsed="true" and have the addon
manager remove that attribute.
2) Ship FF4.0 with statusbar collapsed="true" but copy any additions
into the addon toolbar.
3) Put the FF4.0 statusbar into the addon toolbar so simple overlays
just work.

The problem with #1 and #2 as well as Dao's suggestion: users with both
statusbar and addon toolbar addons get a bad experience, two partly
filled bars right?

>
> I know the outcome that some people are working for in this thread is to
> just kill the change altogether.

The outcomes I am looking for are 1) migration guidelines 2) process
changes to avoid breaking changes late in the beta phase. If this change
arrived with a7 I would have no issue, but it's b7.

jjb

Dao

unread,
Sep 16, 2010, 6:20:18 PM9/16/10
to
On 16.09.2010 23:57, John J Barton wrote:
> The problem with #1 and #2 as well as Dao's suggestion: users with both
> statusbar and addon toolbar addons get a bad experience, two partly
> filled bars right?

No, you got me wrong. <statusbar id="status-bar"/> would be a container
in the add-on bar, not actually distinguishable by the user.

John J Barton

unread,
Sep 16, 2010, 8:56:38 PM9/16/10
to

Excellent, seems like a win to me.

jjb

miken32

unread,
Sep 17, 2010, 12:44:03 AM9/17/10
to
I know this discussion is focused primarily on addon developers, but
can I just put in my two cents as a plain old user? (Well, a plain old
user who builds his own nightlies and posts on newsgroups about web
browsers.)

This is a 15-year old convention getting tossed out for the sake of 20
pixels. Obviously it's a decision that's been made and it's done -- as
a previous poster said, this isn't a democracy. But it seems to me
that you could implement this addon bar without affecting the status
bar for those of us that want it. Don't allow addons to use the old
status bar if you want, hide it by default even, but leave the code in
place for users that are accustomed to seeing it.
None of the 6 "average" users I asked were bothered by the status
bar's real estate usage, and all identified it as the place they look
at to see what link they are about to click on. With all the phishing
warnings going around these days, I'd imagine people are looking more
than ever at links before they click on them. I know, it's moving to
the navigation box. And I'm sure in time we'll get used to not looking
at the status bar, but in the meantime -- probably for the next year
-- I'm going to be cursing at my browser every time I look down at the
status bar and it isn't there.

I won't pull out that old internet chestnut "you better change this or
you'll lose me as a user!!" because you won't, you'll just annoy me.

John Bird

unread,
Sep 17, 2010, 2:41:42 AM9/17/10
to dev-apps...@lists.mozilla.org
For what its worth I see the new hover on link UI and I most heartily
approve. Its unobtrusively in the right of the address bar and anyone can
immediately see what it means. If the rest of the ideas work as nicely as
this its great. I always thought it odd having to look at the status bar
for some information such as progress and a hover link - as others say its
away from the address bar. And the padlock there was probably never noticed
by most.

Question - While a site is loading, what will happen to the messages like
"waiting for www.xyz" etc I see its still in the status bar for now.
Useful for me, as I like seeing for example where the delays in loading are
coming from - eg on Roger Ebert film reviews there are advertising sites
taking quite a bit of time even though there are hardly any ads on the film
reviews. I bet thats important for web site developers.

On the progress bar, that is good. I notice on Windows 7 Aero with a
transparent window showing through the actual end of the progress bar can be
real hard to spot because it fades out....I presume you will alter that, or
it deliberate because its an inexact indicator anyway?

John Bird


Ron Hunter

unread,
Sep 17, 2010, 4:33:04 AM9/17/10
to
What you mean is that this is a 'done deal', no matter WHAT Add-on
developers, or users, think about it? Why not just say that?

I might have to avoid the support groups for a while when this takes
place as I really hate reading profane messages... sigh.

Dietrich Ayala

unread,
Sep 17, 2010, 11:04:11 AM9/17/10
to gavin, dev-apps...@lists.mozilla.org

The resulting user experience is awkward and confusing:

There would be a chunk of add-ons on the bar that can't be moved around, and have a static order. Other add-ons you will install might show up to the left or right or both (depending on how we implement it - we could force it to the right).

If we wrap this stub in a <toolbaritem> then the set of statusbar add-ons can be customized as a set.. but there's no indication to the user why this block is an immutable whole.

johnjbarton

unread,
Sep 17, 2010, 11:20:05 AM9/17/10
to

I disagree: the resulting user experience is reliable and predictable. I
don't want to support users moving the icon that opens our addon. This
kind of customization helps a tiny minority of users have a little fun
at the expense of a similar number of users accidentally mis-customizing
the UI. Its not worth it.

Do you want to support FF4 with both the addon toolbar and the statusbar
as it worked in FF3.6 so the user can have a highly customizable
browser? No, and for good reasons. Similarly I just want users to know
where to open Firebug and if the Firebug button is not there then it's
not installed.

jjb

Dao

unread,
Sep 17, 2010, 11:22:23 AM9/17/10
to
On 17.09.2010 17:04, Dietrich Ayala wrote:
> ----- Original Message -----
>> On Sep 16, 3:49 pm, Dao <d...@design-noir.de> wrote:
>>> I proposed putting a stub <statusbar> element on the add-on bar so
>>> add-ons overlaying the statusbar would magically continue to work.
>>
>> This sounds like a good proposal to me. It would mean that some addons
>> will continue to work without modification, while still allowing
>> addons to make use of the new system to offer additional
>> functionality. I'm not sure I understand the opposition to it - it
>> would mean that we're not "forcing" addons to implement the
>> customizability (by breaking them if they don't), but I don't think
>> the benefits to customizability are important enough to clearly and
>> obviously outweigh the costs of extensions breaking (for both users
>> and developers, at this stage in the release cycle, etc.).
>
> The resulting user experience is awkward and confusing:
>
> There would be a chunk of add-ons on the bar that can't be moved around, and have a static order. Other add-ons you will install might show up to the left or right or both (depending on how we implement it - we could force it to the right).

Yes, we could make it so that the group of unmovable items isn't in the
middle of movable ones. While customizing, the group of unmovable items
could be faded out. This is doable with relatively little effort. Yes, I
would volunteer to do it.

> If we wrap this stub in a <toolbaritem> then the set of statusbar add-ons can be customized as a set.. but there's no indication to the user why this block is an immutable whole.

This indeed sounds awkward and likely wouldn't work for many add-ons, as
they might break when the user removes a formerly permanent item rather
than just moving it. Some would even break as you move it around thanks
to XBL.

Ben Bucksch

unread,
Sep 17, 2010, 11:36:05 AM9/17/10
to
On 16.09.2010 22:46, Alex Faaborg wrote:
> From a UX perspective we are in the process of migrating all existing
> Firefox functionality from the status bar so that we can create a place that
> add-on authors can call their own (and we can create an open area where
> users can add a very large number of add-ons).

I think you should not define the status bar to be the place, just that
there will be *a* place, and it's currently the status bar. Chrome feels
more lightweight in part because it has no status bar, so 3 of 4 window
borders around the page are just lines. It makes you feel that you see
*only* the page (not an app), with a bit of title bar stuff on the top.

> 2) hyperlink target on hover: This has been moved to the right side of the
> location bar since so that it can visually convey to the user that they are
> about to shift from location A to location B. This should also help to
> reinforce to users that the location bar is the place for them to inspect
> location information.

I like that idea a lot, it makes sense.

I don't particularly like the current implementation. trying to show
both URLs means you can't see either in full, and the background and
arrow changes result very nervous UI when I just move my mouse over the
page or click on a link. I don't think it's a good idea to desensitize
users by having flickering on every link click (even more so a mere
mouse move).

DaveG

unread,
Sep 17, 2010, 12:15:07 PM9/17/10
to
Jumping into the fray at the request of Dão so he can reply to me
here. I loathe the groups, generally speaking...

Copying from: https://bugzilla.mozilla.org/show_bug.cgi?id=574688#c133
--------------------------------------------------------------------------------------------------------------
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 bug 574688 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.
--------------------------------------------------------------------------------------------------------------

In the context of the bug the last paragraph above was off topic, but
here, I think it's the whole point.

DaveG

unread,
Sep 17, 2010, 12:17:27 PM9/17/10
to
Stupid line breaks got fubared... I hate the groups... >.<

Hasse

unread,
Sep 17, 2010, 12:57:28 PM9/17/10
to
In article <mailman.3670.1284669980.19132.dev-apps-
fir...@lists.mozilla.org>, Alex Faaborg wrote...

> 3) status text (trying to connect vs. trying and being successful): This
> hasn't landed yet, but our plan is to visually convey a difference between
> Firefox trying (and failing) and Firefox trying (and succeeding). An
> example of this difference in another product is how the throbber in Chrome
> spins backwards in grey, and then forwards in blue. There are a number of
> ways for us to represent this difference visually, and we feel that in
> general they make more sense than a blur of text that changes so quickly
> it's impossible for a human to actually read.

It's not at all impossible to read when there is a problem with loading
the page and you want to know what is going on. Seeing that the problem
is in "Looking up..." rather than "Waiting for..." is a valuable piece
of information.

One idea would be to show the status to the right in the location bar
in the same place as the link target on hover text. Or perhaps be more
specific about the status on the tab header itself, instead of just
displaying "Loading..." like we do now. But that will obviously not
work for app tabs.

--
Hasse
sv-SE l10n team

Ben Bucksch

unread,
Sep 17, 2010, 3:10:19 PM9/17/10
to
On 17.09.2010 18:57, Hasse wrote:
> In article<mailman.3670.1284669980.19132.dev-apps-
> fir...@lists.mozilla.org>, Alex Faaborg wrote...
>
>> make more sense than a blur of text that changes so quickly
>> it's impossible for a human to actually read.
> It's not at all impossible to read when there is a problem with loading
> the page and you want to know what is going on. Seeing that the problem
> is in "Looking up..." rather than "Waiting for..." is a valuable piece
> of information.

Yes, this is critical information that you can need almost every day,
both due to a broken Internet connection on your side or a broken
server, and in both cases various points where it can fail (it's not all
or nothing).
Very often, it's a page requisite like an advertising server that's
preventing the load of the page (I see no page at all), and I know that
because of these status bar messages.

I could see to replace these messages, but only when significantly
better error reporting is implemented first. I'm thinking of:

1. The timeout is reduced from 2 min currently to 20s. If we haven't
received data until then, show a message (not necessarily aborting
connection yet) prominently in the content area near chrome saying "DNS
lookup..." or "Waiting for the HTTP server's response..." "...took more
than 20s. There may be a problem with..." "... the website" or "...your
internet connection", the latter depending on whether the problem is
observed at entirely different sites, too.

2. When a page requisite (e.g. ad server) takes more than 10s and blocks
load finish, show warning and allow to abort this page requisite and
remove it from the page, and let page load finish. This will break some
pages, but with user confirmation, and it's better than not seeing the
page at all, as it's often the case for me.

3. Keeping statistics how long DNS lookups take (separating first and
cached lookups, and considering median and standard variation), and how
long HTTP connection open to first data reception takes, and warning the
user when this times are considerably higher than 1) typical for his
connection type 2) previous days.

Ben

Gavin Sharp

unread,
Sep 17, 2010, 3:15:35 PM9/17/10
to Dietrich Ayala, dev-apps...@lists.mozilla.org
On Fri, Sep 17, 2010 at 11:04 AM, Dietrich Ayala <diet...@mozilla.com> wrote:
> There would be a chunk of add-ons on the bar that can't be moved around, and have a static order. Other add-ons you will install might show up to the left or right or both (depending on how we implement it - we could force it to the right).

This doesn't sound that bad to me. Users can make the case to addon
authors to update their addons to support customization, and in the
mean time they're no worse off than they were before (current status
bar icons aren't customizable).

Gavin

Ron Hunter

unread,
Sep 17, 2010, 3:17:13 PM9/17/10
to

I have a cheap solution. Leave the status bar ALONE. That's MUCH less
confusing, requires no coding, and will not have thousands of users up
in arms about losing something they LIKE, not to mention a lot of add-on
developers complaining about having to change their add-ons.
Win-Win.

Ron Hunter

unread,
Sep 17, 2010, 3:21:15 PM9/17/10
to

I have a 20 inch 1600x900 desktop, and I have lots of room for
displaying a long URL, even when wasting a lot of space repeating the
main domain for what (info)? But then I have a 1024x597 Netbook, and
there is barley room to display an average URL in the location bar.
Adding something else there isn't helpful, at all.

Ron Hunter

unread,
Sep 17, 2010, 3:22:53 PM9/17/10
to
It can be done with colored progress bars, as long as everyone clearly
understands what the color codes are, although those who are color-blind
may be inconvenienced.

Ron Hunter

unread,
Sep 17, 2010, 3:25:19 PM9/17/10
to

All very good ideas. I know that when I see 'looking up....' I have
lost my internet connection, or my DNS server is down.
Saves grief.

Dietrich Ayala

unread,
Sep 17, 2010, 4:26:43 PM9/17/10
to Johnathan Nightingale, Dao, dev-apps-firefox
Here's a draft, with an example add-on:

https://wiki.mozilla.org/User:Dietrich/Scratchpad

Let me know on the talk page if you have suggestions/improvements.

----- Original Message -----
> > Outcome: A pointer to clear migration guidelines that speak to the
> > 80%
> > case(s) for addon authors just looking to get the minimum done.
>

> I've got this going, will try to finish it up tomorrow.

EE

unread,
Sep 17, 2010, 4:46:10 PM9/17/10
to
Why would you want to remove the information in the status bar about
what server is uploading? If there is a problem or delay with loading
then that information becomes visible, and it is useful. If it is a
third party server such as google-analytics causing a delay, one can
simply block that connection to fix the problem.

I thought that information was displayed to make troubleshooting easier.
Now you want to remove that capability?

EE

unread,
Sep 17, 2010, 5:06:24 PM9/17/10
to
Why not just replace the whole address when the cursor is over a link?
It does not make much sense to divide the address bar into two pieces.

Alex Faaborg

unread,
Sep 17, 2010, 5:15:26 PM9/17/10
to EE, dev-apps...@lists.mozilla.org
>
> Why not just replace the whole address when the cursor is over a link?


Phishing concerns, it's important that users realize that the new link is
where they are about to go to, and not where they currently are.
-Alex

John J Barton

unread,
Sep 17, 2010, 5:28:08 PM9/17/10
to
Dietrich Ayala wrote:
> Here's a draft, with an example add-on:
>
> https://wiki.mozilla.org/User:Dietrich/Scratchpad
>
> Let me know on the talk page if you have suggestions/improvements.

The example xpi file is not compatible with FF 3.6. Does this mean the
solution for FF4.0 does not work in FF 3.6? If not, how to make a
solution that works in both browsers?

I guess we can simply omit the 'firstrun' check and its corresponding
preference. Then if the user accidentally moves the button it will
return the next time they restart.


jjb

EE

unread,
Sep 17, 2010, 5:30:23 PM9/17/10
to

Message boxes popping up when a page is loading is something that I find
annoying. I think it would drive some people to distraction fairly quickly.

EE

unread,
Sep 17, 2010, 5:39:12 PM9/17/10
to
How is that going to tell you that joeblow.com is causing the delay?
That is the kind of information that I want. You would then need to
have some explanation handy to explain what all the colours meant. That
sounds like increasing the complication rather than just making it easy
to see where the problem is.

EE

unread,
Sep 17, 2010, 5:43:39 PM9/17/10
to
On 2010/09/16 13:48, gavin wrote:

> On Sep 16, 3:49 pm, Dao<d...@design-noir.de> wrote:
>> I proposed putting a stub<statusbar> element on the add-on bar so
>> add-ons overlaying the statusbar would magically continue to work.
>
> This sounds like a good proposal to me. It would mean that some addons
> will continue to work without modification, while still allowing
> addons to make use of the new system to offer additional
> functionality. I'm not sure I understand the opposition to it - it
> would mean that we're not "forcing" addons to implement the
> customizability (by breaking them if they don't), but I don't think
> the benefits to customizability are important enough to clearly and
> obviously outweigh the costs of extensions breaking (for both users
> and developers, at this stage in the release cycle, etc.).
>
> Gavin

If the text information area could be part of Firefox that could be
turned on to appear in the status bar if desired, that would be
workable. It could then function just as the status bar does now. It
is the best suggestion I have seen in this thread so far.

EE

unread,
Sep 17, 2010, 5:57:46 PM9/17/10
to
On 2010/09/16 12:32, Matthew Turnbull wrote:
> Links targets will be shown in the location bar.
> https://bugzilla.mozilla.org/show_bug.cgi?id=587908
>
> On 09/16/2010 03:12 PM, EE wrote:
>> Are you saying that there will be no status bar? It is very useful to
>> be able to see where a link will go before you click it. Why destroy
>> that capability?
>
After looking at the image, I see what was meant. I think it would be
better to make the text for the link easier to read than using light
grey. Blue or green would be easier to read and would still be
different from the URL of the page.

Ron Hunter

unread,
Sep 17, 2010, 8:09:26 PM9/17/10
to

Recall the my first suggestion is to leave the status bar alone, and
solve all these problems.

Asa Dotzler

unread,
Sep 17, 2010, 9:11:14 PM9/17/10
to
On 9/17/2010 12:10 PM, Ben Bucksch wrote:
> On 17.09.2010 18:57, Hasse wrote:
>> In article<mailman.3670.1284669980.19132.dev-apps-
>> fir...@lists.mozilla.org>, Alex Faaborg wrote...
>>
>>> make more sense than a blur of text that changes so quickly
>>> it's impossible for a human to actually read.
>> It's not at all impossible to read when there is a problem with loading
>> the page and you want to know what is going on. Seeing that the problem
>> is in "Looking up..." rather than "Waiting for..." is a valuable piece
>> of information.
>
> Yes, this is critical information that you can need almost every day,
> both due to a broken Internet connection on your side or a broken
> server, and in both cases various points where it can fail (it's not all
> or nothing).
> Very often, it's a page requisite like an advertising server that's
> preventing the load of the page (I see no page at all), and I know that
> because of these status bar messages.

You may know that because you know how to decipher the messages in the
status bar but no one I know outside of the business has any idea what
those messages really mean. For them it's all just "progress" or "no
progress".

You use it as a debugging tool. Most people don't debug their internet
experience. Even if they did understand those status messages and so
they did know where the failure was, there's no reasonable action they
can take to make things better when there's a failure so it's
un-actionable information for most people. The only actionable
information for most people in the failure case is "we haven't connected
in a long time" and "we've connected but the bits of the page we're
getting are taking a long time". That distinction is something a user
could digest and make a decision based on it (to keep waiting or not)

And, there's an even better debugging tool included in Firefox 4, the
Web Console, which has even better messages for someone like you or me
who know what to make of those messages.

> I could see to replace these messages, but only when significantly
> better error reporting is implemented first. I'm thinking of:
>
> 1. The timeout is reduced from 2 min currently to 20s. If we haven't
> received data until then, show a message (not necessarily aborting
> connection yet) prominently in the content area near chrome saying "DNS
> lookup..." or "Waiting for the HTTP server's response..." "...took more
> than 20s. There may be a problem with..." "... the website" or "...your
> internet connection", the latter depending on whether the problem is
> observed at entirely different sites, too.

None of this has any meaning to the overwhelming majority of Firefox
users and all of this should be available to those that care in the Web
Console or through some addon like live http headers.

> 2. When a page requisite (e.g. ad server) takes more than 10s and blocks
> load finish, show warning and allow to abort this page requisite and
> remove it from the page, and let page load finish. This will break some
> pages, but with user confirmation, and it's better than not seeing the
> page at all, as it's often the case for me.

That would be a nice feature. How do we tell when it's an ad server and
not the critical piece of content on a page like a video at youtube?

> 3. Keeping statistics how long DNS lookups take (separating first and
> cached lookups, and considering median and standard variation), and how
> long HTTP connection open to first data reception takes, and warning the
> user when this times are considerably higher than 1) typical for his
> connection type 2) previous days.

What would this information allow the user to do differently?

- A

Ron Hunter

unread,
Sep 18, 2010, 4:50:11 AM9/18/10
to

I think even the most novice of users understands what 'waiting for...'
means, and 'transferring data from...' is pretty obvious. Some of the
other messages, like 'looking up...' may not tell him much, but it does
tell the more informed something is amiss with DNS access, which IS
useful information.
Information on slow DNS lookup is something that would benefit the user
by telling him that his ISP is in need of cajoling to improve their
service, or perhaps he should look for another internet source.
I suppose FF could just display a message 'It didn't work.' after a
while, but I don't think that would help anyone. More information is
good, less is not good.

Dao

unread,
Sep 18, 2010, 5:21:20 AM9/18/10
to
On 17.09.2010 22:26, Dietrich Ayala wrote:
> Here's a draft, with an example add-on:
>
> https://wiki.mozilla.org/User:Dietrich/Scratchpad
>
> Let me know on the talk page if you have suggestions/improvements.

It lacks help for migrating code accessing the UI element as if it were
always there. This is very add-on specific, so you actually can't be
concrete. You should say something like: Audit your code carefully, make
sure to never expect "myBox" to exist or to remain when it exists (e.g.
don't hold a reference on it forever); where appropriate, bail out if it
doesn't exist.

There are events that will help you keep track of your item:
beforecustomization
customizationchange
aftercustomization
They are dispatched on the toolbox(!).

It should probably also be mentioned that XBL bindings are
re-constructed when the items are wrapped for customization.

Last but not least, it's good that we're going to have a guide, but let
me reiterate that we should not force add-on authors to do this.

flying sheep

unread,
Sep 18, 2010, 10:06:09 AM9/18/10
to
this discussion is about two things:
- keeping or removing the old statusbar
- breaking or retaining the old way of adding "statusbar" widgets

if there would be a way to let addon developers retain their
behaviours AND give the users customizable addon buttons/widgets, then
we should do it.

but if addons written in the old way lead to a container with
unorderable fixed-size widgets, BREAK IT!

let the old way die. it is a normal process of software evolution to
break obsolete behavior in order to enforce a new, better practice.
and it surely is a better practice to make the widgets draggable.

-----------------------

idea:
- keep & hide the statusbar _and_ rename/re-id it to break old addons.
- instead make it able to contain the new draggable widgets.

pro:
- statusbar still there for statusbar-lovers
- no inflexible fixed-height unmovable widgets possible anymore
contra:
- statusbar fans have to drag the widgets into the bar
- lazy addon devs may whine about their addons needing to be migrated

alta88[nntp]

unread,
Sep 18, 2010, 11:07:32 AM9/18/10
to


---On 2010.Sep.18 8:06 AM, flying sheep wrote:
> this discussion is about two things:
> - keeping or removing the old statusbar
> - breaking or retaining the old way of adding "statusbar" widgets
>
> if there would be a way to let addon developers retain their
> behaviours AND give the users customizable addon buttons/widgets, then
> we should do it.

this, of course, is possible. the TotalToolbar extension reuses the
exact same dnd ergonomic and customization code in Fx toolkit to achieve
this for statusbar. as dao has said, statusbar items hold references,
receive events, etc and cannot physically be removed from the DOM, but
must instead be hidden, to achieve your goal of simulating toolbar
customization.

imo, this would be a hack and should *not* be supported.


>
> but if addons written in the old way lead to a container with
> unorderable fixed-size widgets, BREAK IT!
>
> let the old way die. it is a normal process of software evolution to
> break obsolete behavior in order to enforce a new, better practice.
> and it surely is a better practice to make the widgets draggable.
>

this is exactly correct. things have moved on (statusbar as toolbar is
long overdue), and addon devs need to adapt. arguments for 'it takes
time', 'it requires work' etc are to my mind quite invalid.

it's not too hard to find all extensions using <statusbar> in amo and
notify their devs of the trivial changes required per dietrich's guide.
nothing whatsoever need change from the user's perspective, and now
they get reorder functionality.

no effort (hack) should be made to make this change backwards compatible.

(statusbar messages are a different issue and as this is still a wip, it
remains to be seen how well that is solved. they could easily be
packaged in a <toolbaritem> in the addon toolbar to retain the former look.)
> -----------------------
>
> idea:
> - keep& hide the statusbar _and_ rename/re-id it to break old addons.

Herrmann Hofer

unread,
Sep 18, 2010, 12:00:55 PM9/18/10
to
John J Barton wrote:
> The example xpi file is not compatible with FF 3.6. Does this mean the
> solution for FF4.0 does not work in FF 3.6? If not, how to make a
> solution that works in both browsers?

And this is IMHO the biggest problem: Not that we have to migrate our
code (we're used to that), but that we have to maintain two different
versions of the code or at least two different branches within a module.

This will continue for quite a while, as statics show. Asking admins to
switch to a new version of the browser on their whole network, just
because one add-on requires it, may be asking a little bit too much.

EE

unread,
Sep 18, 2010, 1:50:55 PM9/18/10
to

I had another thought. Why not make that new text in the address bar
unvisited-link-blue? That would make the connection between it and the
hovered link more obvious.

EE

unread,
Sep 18, 2010, 2:02:17 PM9/18/10
to
And all that means that the interface should be dumbed down to the level
of the least knowledgeable or least intelligent browser user? I do not
think so.
If there is a server hostname listed which is not the one serving the
page, and it is causing a serious delay, one could take steps to block
contact with that server.

Asa Dotzler

unread,
Sep 18, 2010, 2:52:52 PM9/18/10