Closed Bug 860814 Opened 11 years ago Closed 11 years ago

[meta] Australis Customization - Milestone 3 - User Migration

Categories

(Firefox :: Toolbars and Customization, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mconley, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Screenshot of my Fx customized
46.85 KB, image/png
Details 
Things we're scheduled to focus on in this milestone:

1) Finding a migration path for users with previous customizations that do not make sense in the new customization world we're living in
  a) Custom toolbars
  b) Toolbaritems in non-customizable areas (we really need to solidify what the customizable areas will be)
  c) 
2) Dealing with nav-bar toolbarbutton overflow

For a number of reasons, we didn't clear everything on our list for M2, so there might be a little bit of lag in getting this one going while we sort that out.
I didn't include a c) because I didn't have one at the top of my head, and I forgot to remove it. I wasn't just being mysterious.
No longer blocks: 770135
Depends on: 770135
Depends on: 858660
So, here are some ideas on how to approach these problems:

1) Go through the top 20 or so add-ons from AMO, and determine if / how they add toolbar items. Make sure they still work properly with the new customization stuff.

2) From 1, determine what (if any) changes add-on authors will likely need to make to fix their toolbaritems for the new customization world. This might involve a bit of outreach into the add-on development community. The earlier we can alert add-on developers, the better.

3) Find a nice way of putting overflowed toolbar items into a panel, and figure out what to do when those items anchor panels.

4) Determine what customizations will no longer be possible, and figure out how to migrate users from those customizations.
jaws and I just met, and here's an outline of our migration plan for v1 of the new customization mode.

Disclaimer: One of the points of Australis is to make it harder for users to render their browsers un-usable with their customizations. Another goal is to make Firefox more beautiful, regardless of how it has been customized. Some users will no doubt be upset that we're changing the boundaries for customization in Firefox for this first version of Australis.

Constructive feedback should be sent to the firefox-dev list[1] for open, respectful discussion.

Unconstructive feedback is, however, unwelcome, and should be withheld.

Neither types of feedback should be posted in this bug.

1: https://mail.mozilla.org/listinfo/firefox-dev


And here...we...go.


== The Navigation Toolbar ==

1. The back, forward, URL bar, reload and stop buttons will be placed at the beginning of the nav-bar. These will no longer be move-able.
2. At the end of the nav-bar will be the WebRTC button (hidden), the nav-bar customization target, the Social API toolbar item (hidden), and the menu button
3. All items that were originally in the nav-bar but were not included in the above list will be put into the customization target.
4. By default, the bookmarks button, downloads button and search input should be in the customization target, unless the user had customized them away in a previous version.

== Custom Toolbars ==

Custom toolbars (the type created from the "Add New Toolbar" button in toolkits customization window), will be removed. The items that were in those custom toolbars will be appended to the nav-bar customization target.

== Addons Toolbar ==

The add-ons toolbar will be removed. The items in this toolbar will be placed in the customization target of the nav-bar.

== The Menu Toolbar ==

The menu toolbar (File / Edit / View) will no longer be a customization target. Items that have been placed in the menu toolbar will be placed in the nav-bar customization target.

== The Tabstrip ==

The tabstrip will have a single customization target, on the side of the tabs closest to the menu button. All toolbaritems in the tabstrip will be placed in this customization target.

== Toolbar supplied by Add-ons ==

Example, the "Ask" toolbar, "Norton", etc. These will be untouched.

== Other ==

"Small icons" mode will no longer be supported.



Did I get all that right, jaws?
Or Blair, for that matter?
Flags: needinfo?(jaws)
Flags: needinfo?(bmcbride)
LGTM, I added the dependency for bug 573329.
Depends on: 573329
Flags: needinfo?(jaws)
Flags: needinfo?(bmcbride)
AFAIK you forgot the fact that it won't possible to hide the nav bar anymore.

Having unmoveable items (especially social API) isn't very good, because consistency isn't respected.
Depends on: 863042
So apparently, I didn't make it clear that this is a v1 version of this migration plan. Folks who are reading this bug - please don't interpret this as set in stone. There's still plenty of tweaking and tuning we need to do here in order to account for lots of things.

We just wanted a starting point, and that's what comment 3 is.

I'm going to start a firefox-dev thread right now so interested folks can (respectfully and constructively) chime in with their ideas and concerns.
(In reply to Mike Conley (:mconley) from comment #7)
> So apparently, I didn't make it clear that this is a v1 version of this
> migration plan. Folks who are reading this bug - please don't interpret this
> as set in stone. There's still plenty of tweaking and tuning we need to do
> here in order to account for lots of things.
> 
> We just wanted a starting point, and that's what comment 3 is.
> 
> I'm going to start a firefox-dev thread right now so interested folks can
> (respectfully and constructively) chime in with their ideas and concerns.


respectfully and constructively
chiming in with their ideas and concerns

http://www.reddit.com/r/firefox/comments/1clf85/firefoxs_australis_theme_may_have_disastrous/
(In reply to ElevenReds from comment #8)
> (In reply to Mike Conley (:mconley) from comment #7)
> > So apparently, I didn't make it clear that this is a v1 version of this
> > migration plan. Folks who are reading this bug - please don't interpret this
> > as set in stone. There's still plenty of tweaking and tuning we need to do
> > here in order to account for lots of things.
> > 
> > We just wanted a starting point, and that's what comment 3 is.
> > 
> > I'm going to start a firefox-dev thread right now so interested folks can
> > (respectfully and constructively) chime in with their ideas and concerns.
> 
> 
> respectfully and constructively
> chiming in with their ideas and concerns
> 
> http://www.reddit.com/r/firefox/comments/1clf85/
> firefoxs_australis_theme_may_have_disastrous/

I've noticed. :) We do, however, need to move the conversation out of Reddit, and into firefox-dev where it belongs.
i agree but most common folks
don't know that much detail

& power users use reddit(more collaborative & great minds & IDEAS)
so Personally i don't think they will go there :(
see this too :)

http://www.reddit.com/r/firefox/comments/1cl352/psa_the_ux_team_is_destroying_firefoxs/

Fingers crossed (& hoping you guys change your mind , don't follow Chrome & make FF more customizable)
(In reply to Mike Conley (:mconley) from comment #9)
> (In reply to ElevenReds from comment #8)
> > (In reply to Mike Conley (:mconley) from comment #7)
> > > So apparently, I didn't make it clear that this is a v1 version of this
> > > migration plan. Folks who are reading this bug - please don't interpret this
> > > as set in stone. There's still plenty of tweaking and tuning we need to do
> > > here in order to account for lots of things.
> > > 
> > > We just wanted a starting point, and that's what comment 3 is.
> > > 
> > > I'm going to start a firefox-dev thread right now so interested folks can
> > > (respectfully and constructively) chime in with their ideas and concerns.
> > 
> > 
> > respectfully and constructively
> > chiming in with their ideas and concerns
> > 
> > http://www.reddit.com/r/firefox/comments/1clf85/
> > firefoxs_australis_theme_may_have_disastrous/
> 
> I've noticed. :) We do, however, need to move the conversation out of
> Reddit, and into firefox-dev where it belongs.

I can't respond to the Firefox-dev post via the Google Groups interface and for obvious reasons, I've set the mailing list to only mail me a digest once a day, any suggestions?
(In reply to Paul [sabret00the] from comment #11)
> 
> I can't respond to the Firefox-dev post via the Google Groups interface and
> for obvious reasons, I've set the mailing list to only mail me a digest once
> a day, any suggestions?

The firefox-dev list is mirrored to Google Groups, but it's read-only there. I think your best bet is to just send mail to firefox-dev at mozilla dot org.
(In reply to Mike Conley (:mconley) from comment #9)
> (In reply to ElevenReds from comment #8)
> > (In reply to Mike Conley (:mconley) from comment #7)
> > > So apparently, I didn't make it clear that this is a v1 version of this
> > > migration plan. Folks who are reading this bug - please don't interpret this
> > > as set in stone. There's still plenty of tweaking and tuning we need to do
> > > here in order to account for lots of things.
> > > 
> > > We just wanted a starting point, and that's what comment 3 is.
> > > 
> > > I'm going to start a firefox-dev thread right now so interested folks can
> > > (respectfully and constructively) chime in with their ideas and concerns.
> I've noticed. :) We do, however, need to move the conversation out of
> Reddit, and into firefox-dev where it belongs.


The common user does not change anything about the browser's looks; especially anything toolbar related. The only users doing anything here are Firefox's power users who, undoubtedly, would be against the restrictions in the changes that you're proposing.
I'm all for making Firefox more approachable to end users but that can be achieved without killing off the options that many of us have come to love

I stand behind Mozilla 100% more than I would behind Google because Mozilla fights for user privacy and it's a not for profit organisation as opposed to Google. But I hope you understand that the features that you would be killing are cherished by many. We may be the minority but we're the vocal minority that help spread Firefox so please don't abandon us. 

I have spent years perfecting my customization of Firefox so that it performs exactly the way I need it to & most Power user want to do so without installing addons(which can be a nuisance)
& FF should facilitate that by default. that small icons thing. WHY should those icons be so much larger than all other icons on my system?

OR
is it that you guys yes you guys who suddenly wake up & remove a most useful features(UI-minimilsm I am looking at you/image-decoder still not up-there with) 

there is a NEGATIVE feeling From all power users or users who want to use
each & very thing as they wish & not being told that it should be only done like this
IS it

"Mozilla doesn't care."
They won't let you complain on Bugzilla ("constructive comments only" - that is, agree with us or we will delete your comment), and you'll note that the above bugzilla comment redirects comments to the firefox-dev mailing list.

I sure hope not but as a cook
I would like o say this
"It's not about you or what you think might be good its the person for whom you are making the DIsh that matters & HE/She is More Diverse & creative than you can Imagine whe it comes to what she/He likes "

regards
:)
Well, i would not call the users which heavily customize Firefox a minority. The typical Everyday Computer User without much experience chooses anyway Google Chrome.

Anyway, i do not think that Australis will have that Wished Effect Mozilla Devs may have. There will be a decline of User Base, and that Decline will be NO small one.

Something which is also worth considering. Is it really be necessary to reduce Firefox market share to the amount of Safari or even Opera? Do never underestimate the number of People who use Firefox for the ability of Customization.

The numbers of Complaints in the Web show a different language!
(In reply to saphirjd from comment #14)
> Well, i would not call the users which heavily customize Firefox a minority.
> The typical Everyday Computer User without much experience chooses anyway
> Google Chrome.
> 
> Anyway, i do not think that Australis will have that Wished Effect Mozilla
> Devs may have. There will be a decline of User Base, and that Decline will
> be NO small one.
> 
> Something which is also worth considering. Is it really be necessary to
> reduce Firefox market share to the amount of Safari or even Opera? Do never
> underestimate the number of People who use Firefox for the ability of
> Customization.
> 
> The numbers of Complaints in the Web show a different language!

I agree Fully with you
I have 31 bookmarks (no text) on my toolbar as small icons, which includes the zoom in/out and fullscreen icons. They are instantly accessible, used often and I hardly ever need to go search through bookmark folders. Cramming all that into navigation bar with same speed of access? unlikely.

Firefox developers should try working on a 1024x600 resolution with touchpad.(no mouse). Yes keystrokes can get you there, but takes much longer than a simple click
This is nonsense! It just take away one of the most —if not the most— relevant reason people still uses Firefox over Chrome. If they are trying to clone Chrome just to get back the user segment that Chrome has I think they will end with none. Please, please, keep the respect for the user that makes Firefox so lovable to me and to many others. I’m sick of the “Apple way” to deal with the user’s rights, but when that attitude comes to the open source community, well, that will be a tragedy.

And, as been said here before: What are the pros for this decision? Is there anybody complaining about customization options?
I use Firefox because it is customizable and if I wanted a faster browser I would have already moved to Chrome.
Being able to customize Firefox's user interface is one (but admittedly not the only) reason I prefer Firefox to Chrome. Proposed changes 3, 4, 5, and 7 will essentially wipe out *all* of my UI customizations. If Mozilla wants to change the default interface to better appeal to new users, no problem. But why eliminate the ability to customize? Australis proponents state: "One of the points of Australis is to make it harder for users to render their browsers un-usable with their customizations. Another goal is to make Firefox more beautiful, regardless of how it has been customized." Well, *my* customizations have made Firefox *more* usable fro me, not *un*-usable ... and beauty lies in the eye of the beholder.
Just don’t do this, please, don’t.
Suicide solution :\
Hey everybody - thanks for the comments. I'll remind you all that this sort of discussion *really* should be happening in firefox-dev, and not in Bugzilla[1].

We've heard a lot of feedback about this proposal, and we're doing some course-correction. We'll post news once we have a new draft.

1: For the new folks, it's probably a good idea to read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(In reply to Mike Conley (:mconley) from comment #17)
> Hey everybody - thanks for the comments. I'll remind you all that this sort
> of discussion *really* should be happening in firefox-dev, and not in
> Bugzilla[1].

I sent a message at 9:42 and it's not been moderated. Any idea on why that is? I'm all for moderation, but six hours is ridiculous, especially when I'm seeing messages appear in the meantime.
(In reply to Paul [sabret00the] from comment #18)
> (In reply to Mike Conley (:mconley) from comment #17)
> > Hey everybody - thanks for the comments. I'll remind you all that this sort
> > of discussion *really* should be happening in firefox-dev, and not in
> > Bugzilla[1].
> 
> I sent a message at 9:42 and it's not been moderated. Any idea on why that
> is? I'm all for moderation, but six hours is ridiculous, especially when I'm
> seeing messages appear in the meantime.

I can think of a few possibilities:

1) You wrote a message that violates the moderation policy, and you need to re-write it with that policy in mind
2) You wrote a long message, and the moderators need to read / parse the whole thing before posting it

There might be technical reasons too, but assuming for the second that it's #2, I think you should wait a few more hours for the west coast to wake up and go through the queue.
My message read:
"I think the problem is that the customisable area is so much smaller in Australis than it has ever been previously. So many buttons are locked in place and unmovable and what's left is a tiny area for users to rearrange things. If we're being honest, that's not customisation.

Could I propose that rather than lock items such as Back/Forward/Awesome Bar/Reload in place. You simply lock them so they're unremovable from the navigation bar. You retain the logic whereby users can separate/have them interrupted (in terms of order/placement) and but for the menu button, users can truly customise the Navigation bar while users that need saving from themselves are prevented from being able to remove key features from the primary UI."

Clearly that neither violates moderation policy nor is it lengthy. It is counter-productive to direct community members to a mailing list and yet ask them to ask for a full working day for their messages to be moderated.
(In reply to Paul [sabret00the] from comment #20)
> My message read:
> "I think the problem is that the customisable area is so much smaller in
> Australis than it has ever been previously. So many buttons are locked in
> place and unmovable and what's left is a tiny area for users to rearrange
> things. If we're being honest, that's not customisation.
> 
> Could I propose that rather than lock items such as Back/Forward/Awesome
> Bar/Reload in place. You simply lock them so they're unremovable from the
> navigation bar. You retain the logic whereby users can separate/have them
> interrupted (in terms of order/placement) and but for the menu button, users
> can truly customise the Navigation bar while users that need saving from
> themselves are prevented from being able to remove key features from the
> primary UI."
> 
> Clearly that neither violates moderation policy nor is it lengthy. It is
> counter-productive to direct community members to a mailing list and yet ask
> them to ask for a full working day for their messages to be moderated.

IMO, you're correct - I don't find that lengthy, disruptive or nonconstructive. Not sure why that hasn't been posted (I'm not a mod). I'll see what happened.
I have posted an updated version of the proposal here: https://mail.mozilla.org/pipermail/firefox-dev/2013-April/000247.html
Depends on: 864355
Depends on: 864425
It's not entirely clear for me from the updated proposal, if it'll be possible to drop all controls (menu, navbar, tabs, etc) to the one bar/panel (see the attached screenshot).
Can you elaborate, please?
Short answer : No.

1. You won't be able to remove the forward/back buttons, URL-bar and stop/reload button from the navigation toolbar.
2. You won't be able to hide the navigation-toolbar.
Wish you best luck with Australis and that Final Draft you released, but you lost 6 more machines to a competitor today and some more upcoming in the next few days!

Was a great Experience using Firefox already before even the first stable version was released. So goodbye Firefox and Firefox Devs and thanks for the Fish ;)

Btw. Anyone can please close my account here? i do not need it anylonger, thanks!
Depends on: 865926
How much is "a ton"?  Is it a greater percentage of the userbase than
the number of users who keep 100+ tabs open?

What is the underlying cause of so many users needing to consult that
page?  That is, what exactly led people to make mistakes that made the
browser 'unusable'?  I've seen examples of what an unusable state is,
but I've never seen anything addressing what led users to reach that
state in the first place.

Things I can think of:

1) Mouse flakiness (and possibly extended to touchscreen flakiness).  My
own mouse has been a pain in the ass lately, where, when holding down
the mouse button and dragging, it will occasionally 'skip' -- that is,
signal that the mouse button was released and then re-pressed in a
nearly instantaneous fashion -- such that I don't get the proper
selected text that I was aiming for, or something I was doing a
drag-and-drop operation on ends up in the wrong place, etc.

While it's likely that at least some of the problems stem from such a
hardware issue, it seems somewhat less likely that that's the cause of a
permanent breakage in the browser since you still need to 'OK' any
changes you make (though you can also Esc out, which may be a natural
reaction when you make a mistake, and may further promote this issue).  
If something was dropped in the wrong place due to hardware flaws, you
can just try moving it again.  However the options for Mozilla to
account for this are quite limited, so the presence of reports that were
caused by such problems is not in itself a means of justification.

2) Not understanding what all the buttons are for.  Ever since the
introduction of the magic combining buttons, customize mode shows more
buttons than actually appear in the UI.  It even took me a bit to figure
out what the hell was going on after that initial change. A user may
feel that their toolbar has reached some sort of 'corrupted' state when
they see these extra buttons show up, and try to get rid of the extras
to clean it up.

In this case, the source of the problem is the original design change,
along with the manner of interacting with this changed UI paradigm.  
Removing the ability to customize only masks the original mistake.

3) Dropping buttons on an auto-hidden toolbar. (Example provided by Mike
on Reddit)  When leaving customization mode, the toolbar disappears
along with the moved buttons.

In this case, the flaw is allowing hidden toolbars to be targets of
customization.  That appears to be getting addressed in the current
proposal.

4) 'Losing' a button.  For example, dragging a button somewhere and
accidentally putting it in the palette window, it can be somewhat
difficult to find it again in amongst all the junk in that window. This
actually seems like the most difficult to do accidentally, since there
are only a handful of places you can 'release' a button that you're
dragging, and (assuming #3 was fixed) the only way a button can
disappear completely is by putting it back in the customization window.

Preventing the user from being allowed to remove the buttons from the
toolbar does keep them from getting hit by this particular issue.  
However I question whether the primary difficulty is moving the button
off of the toolbar, or whether it's the difficulty in finding the button
again once it's been removed.

The current main difficulty in finding the button again is that
accessing the customization palette requires use of a context menu
item.  With the introduction of a primary UI element (the UI button for
invoking customization), and presumably making sure that it's not
possible to remove that button, that removes a large portion of the
difficulty in recovering a removed button.  Improvements in the general
UI display to make it easier to find the customizable elements
themselves further lowers the barrier.

As such, I must question the gain that is expected from preventing
removal of the buttons entirely vs simply having better accessibility to
the buttons, so that they're not 'lost' (as well as fixing the other
real issues).

5) Extensions that force certain changes due to a lack of a standardized
API for adding their buttons to a toolbar when installed.  Multiple
add-ons that do such things in their own hacky ways may end up creating
a bit of a mess.

To fix this, just set up a proper API.  Appears to be part of the
current proposal.

6) Anything else?  I can't think of any other means of interacting with
the UI that would lead to such a problem.


 From what I can see, addressing this issue would be:

1) Do not allow hidden toolbars to be customization targets. (done)
2) Improve the customize palette window to make finding things easier.
(done)
3) Eliminate 'magic' button combinations.  Provide 1:1 mapping between
what you put on the toolbar when customizing, and what you actually get.
3a) Make it easy to use alternate forms of buttons, whether provided as
part of the default or via add-ons.
4) Set up a simple, standard API for add-ons that wish to add toolbar
buttons on install.

Examples for 3a:
Combined back/forward/URL bar
Combined back/forward (both always visible), separate from URL bar
Separate back, forward


Essentially, the magic combining buttons were made to solve the issue of
how to allow variations in the UI without changing the number of base
elements the UI was built from.  That is, you don't want a plain URL
bar, a URL bar with combined back/forward, a URL bar with stop/reload at
the end, a URL bar with combined back/forward/stop/reload, and all those
variations with the bookmark star, etc.

The sheer number of possible combinations is problematic, such that you
don't want to create one UI element for every possible combination.  At
the same time, you don't want 'magic' combinations that confuse users
and cause extra hassle for developers.  Your original solution to the
dilemma seemed to just be "don't allow customization".

Aside: An alternate approach would seem to be to to provide only a
single UI element per type of interface element, but allow the user to
scroll though the varying 'types' that it can exist as (eg: combined
stop/reload vs separate stop and reload that are linked together).  
Would probably be a bit more complicated on the dev side, but would
avoid the 'magic' combinations; every UI element would be explicit.

So suppose we move forward, where the default UI only has some very
simple, basic elements, and you depend on add-ons to fill in the gap for
those who want to customize their interface (ignoring that this is in
direct opposition to the stated goal of wanting people to be more
comfortable customizing the interface themselves).  To what degree can
an add-on replace all elements?  In particular, can you have an add-on
that provides a simplified URL bar, divorced from the merged
back/forward buttons, that can properly mimic site security
information?  Allowing an add-on to mimic such things seems like a huge
potential security hole, but not allowing it means that the user can't
replace the hard-coded elements that Mozilla decides on.

Further, how does this affect theming?  Creating an add-on that allows
you to set any various and sundry combinations of buttons as what gets
used in the customization window would seem easy enough, but if those
buttons are (necessarily) different from the default ones, it would seem
difficult for a theme to properly handle skinning all the variations,
particularly when there may be multiple (potentially conflicting)
add-ons all attempting to compensate for the new issues that Mozilla
introduced.

Also note that the add-on bar is entirely separate from any and all of
the above issues (as evidenced by the fact that what few justifications
have been presented for its removal have had nothing to do with
customizability), and using this proposal as a means to force its
removal seems out of scope.

 >> Finally, we hope this will make add-on-installed features feel more like
 >> "first class citizens" and equal to shipped-in-the-browser features by
 >> allowing them to all live together in the same menu panel. This
 >> co-mingling will hopefully make it clear to end-users that both add-on
 >> features and built-in ones are addable and removeable by them.

I think that this actually has the potential to be counter-productive.  
This goes back to point #4, above -- it's easy for buttons to be 'lost'
in amongst the tons of options in the palette window, and possibly
similarly with the customization panel (all mockups so far have been
extremely limited; how do they look with a dozen add-on icons mixed
in?).  Trying to promote every single add-on as a "first class citizen"
in the UI does not serve the actual level of interaction value any given
add-on provides.

Some add-ons are low-profile and only used occasionally; you don't want
them cluttering up the main UI (eg: music player, color picker, proxy
adjustments, etc).  Some merely provide status information that would be
gaudy and annoying in the main toolbar (eg: weather, flags, time, etc).  
Putting everything into a single bucket, trying to force everything into
a top-level display position, increases the issue of 'losing' buttons in
a cluttered area, while also increasing the amount of 'noise' in the UI
since you propose to no longer have the add-on bar to hold lesser-used
items.


 >> The add-on bar could be re-inserted with another add-on.

No matter how many times I read this, it still boggles my mind.

 >> * Remove UI for adding custom toolbars

Will agree that that seems like something more suited to an add-on.
Depends on: 866245
I personally gonna ditch firefox soon, I hate new bookmark star button change, I don't wanna increase my addon inventory, don't want some scriptish hacks.
I am amused to see how bad Mozilla has fallen, every FF diehard fan like me know early FF4 release days when FF started competition for FF4 possible theme and people took part in it because it was crucial for FF and Mozilla wanted to make changes what people want but now in case of Australis they took mockups of one Stephen Horlander ****** and start implementing it because they think it is Chrome copy and they could be similarly successful with it. Truth is bitter. Alas! now they will loss some crucial base of users.

I am pretty sad right now and being freedom of speech I am making my opinion, you can disagree with me completely but I will stick with my comment
Depends on: 866387
saphirjd and Marilyn:

As I stated in comment 17, this bug is not the place for this kind of discussion. Firefox-dev[1] is where our development discussion takes place. I invite you to read the Bugzilla etiquette page[2] for guidelines on expected and acceptable conduct.

Thanks,

-Mike

[1]: https://mail.mozilla.org/listinfo/firefox-dev
[2]: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Depends on: 869939
Depends on: 870545
No longer depends on: 870545
Depends on: 872209
No longer depends on: 863299
No longer depends on: 872209
No longer depends on: 867368
No longer depends on: 868135
No longer depends on: 865926
No longer depends on: 866245
No longer blocks: 867653
We're moving away from using these meta bugs for tracking milestones, so I'm closing this bug (despite the old dependencies not actually being finished yet).

Folks who are interested in tracking the Australis milestones should search for:

[Australis:MX] in the whiteboard, where X is the milestone number.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Mike Conley (:mconley) from comment #29)
> Folks who are interested in tracking the Australis milestones should search
> for:
> 
> [Australis:MX] in the whiteboard, where X is the milestone number.

Just tried it. Didn't find a single bug.
(In reply to Peter Henkel [:Terepin] from comment #30)
> (In reply to Mike Conley (:mconley) from comment #29)
> > Folks who are interested in tracking the Australis milestones should search
> > for:
> > 
> > [Australis:MX] in the whiteboard, where X is the milestone number.
> 
> Just tried it. Didn't find a single bug.

Works for me: 
http://bugzil.la/sw:"[Australis:M" 
the quotes seem to be needed because of the colon.

You can also use https://people.mozilla.com/~mnoorenberghe/australis/#customization
Whoever is behind the sharklasers.com spamming. I understand you're upset because a browser isn't being tailored towards your personal desires and the changes in the desktop UI are imminent, but there are non-Mozilla employees who are also part of this community monitoring these bugs. Why are you spamming us? If you want to direct abuse at people, please find another medium.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: