Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bon Echo Alpha 2 Milestone

3 views
Skip to first unread message

christop...@gmail.com

unread,
May 13, 2006, 12:42:36 AM5/13/06
to
Bon Echo Alpha 2 is the second developer milestone on the path to
Firefox 2. This milestone is focused on testing the core functionality
provided by many of or new features and changes to the platform
scheduled for Firefox 2. Ongoing planning for Firefox 2 can be followed
at the Bon Echo Planning Center (http://wiki.mozilla.org/Firefox2), as
well as in the mozilla.dev.planning newsgroup and on irc.mozilla.org in
#bonecho.

Please note: We do not recommend that anyone other than developers and
testers download this Alpha 2 milestone release. It is intended for
testing purposes only.

Changes in this milestone that require feedback include:
* Links default to opening in new tabs, not new windows
* Close buttons now appear on every tab, and the close behaviour is
slightly different
* Inline spell checking in text boxes
* Automatic restoration of your browsing session if there is a crash
* Search suggestions now appear in the search box auto-complete for
Google and Yahoo!
* New search plugin manager for removing and re-ordering search
engines
* Improved support for previewing and subscribing to web feeds
* New Microsummaries feature
* New Add-Ons manager improves the user interface for managing
extensions and themes
* Updates to the extension system to provide enhanced security and to
allow for easier localization of extensions
* New search service that supports Sherlock and OpenSearch engines
* Support for SVG text using svg:textPath

The Bon Echo start page has also been changed to make it easier for
testers to provide feedback to the mozilla.feedback newsgroup.

Builds are available for testing here:

Windows (5.3 MB)
http://download.mozilla.org/?product=bonecho-alpha2&os=win&lang=en-US

Mac OS X (17 MB)
http://download.mozilla.org/?product=bonecho-alpha2&os=osx&lang=en-US

Linux (9 MB)
http://download.mozilla.org/?product=bonecho-alpha2&os=linux&lang=en-US

Testers should also be sure to read the Release Notes which have been
posted at:
http://www.mozilla.org/projects/bonecho/releases/2.0a2.html

Note: Please do not link directly to the download site. Instead we
strongly encourage you to link to this Bon Echo milestone announcement
so that everyone will know what this milestone is, what they should
expect, and who should be downloading to participate in testing at this
stage of development.

Enjoy!

---
Christopher Beard
Mozilla Corporation
cbe...@mozilla.com
650.903.0800 x201
650.903.0875
http://cbeard.typepad.com

Jeff Schiller

unread,
May 13, 2006, 1:19:51 AM5/13/06
to
Something is seriously screwed up with the detection at
http://www.mozilla.org/projects/bonecho/

No matter what browser I use to visit that URI, it says I've downloaded
or compiled Bon Echo Alpha 2.

Jeff

Boris Zbarsky

unread,
May 13, 2006, 1:38:59 AM5/13/06
to
Jeff Schiller wrote:
> Something is seriously screwed up with the detection at
> http://www.mozilla.org/projects/bonecho/
>
> No matter what browser I use to visit that URI, it says I've downloaded
> or compiled Bon Echo Alpha 2.

The JS in question is:

if (version == "BonEcho/2.0a1")
window.location='http://www.mozilla.org/projects/bonecho/index-2.0a1.html';
else
window.location='http://www.mozilla.org/projects/bonecho/index-2.0a2.html';

-Boris

mozilla.dev.app.firefox

unread,
May 13, 2006, 7:36:40 AM5/13/06
to
The search suggestions can't appear in the search box auto-complete
when I use a proxy server to connect with the Internet .

Doron Rosenberg

unread,
May 13, 2006, 1:09:42 PM5/13/06
to
> * Updates to the extension system to provide enhanced security and to
> allow for easier localization of extensions
>

According to bug 285848, it looks like the easier localization work
won't make 2.0. Has that changed?

kalphegor

unread,
May 14, 2006, 5:02:52 PM5/14/06
to
Is there any website that has Microsummaries feature?
How can I add this feature to my website? (create a generator?)
I read the wiki, but it isn't to useful

Mike Connor

unread,
May 13, 2006, 11:20:45 PM5/13/06
to dev-pl...@lists.mozilla.org

No. Pretty sure this was an oversight.

-- Mike

Mike Shaver

unread,
May 15, 2006, 12:10:44 AM5/15/06
to Mike Connor, dev-pl...@lists.mozilla.org
On 5/14/06, Mike Connor <mco...@mozilla.com> wrote:
>
> On 13-May-06, at 6:09 PM, Doron Rosenberg wrote:
>
> No. Pretty sure this was an oversight.

I thought we had the localization stuff except for "managed locales"
(automatic fetching of late-breaking localizations for installed
extensions in the user's selected locales, etc.)....?

Mike

Robert Strong

unread,
May 15, 2006, 1:16:20 AM5/15/06
to Mike Shaver, dev-pl...@lists.mozilla.org, Mike Connor
Mike Shaver wrote:
> On 5/14/06, Mike Connor <mco...@mozilla.com> wrote:
>>
>> On 13-May-06, at 6:09 PM, Doron Rosenberg wrote:
>>
>> No. Pretty sure this was an oversight.
>
> I thought we had the localization stuff except for "managed locales"
> (automatic fetching of late-breaking localizations for installed
> extensions in the user's selected locales, etc.)....?
Yes... we now display extension locale packs in the Languages view of
the add-ons mgr. The automatic installation of locale packs specified in
an extension's update rdf won't make it for 2.0.

Robert

Axel Hecht

unread,
May 15, 2006, 4:46:47 AM5/15/06
to

I wouldn't say "allow for easier localization of extensions". The thing
we have right now that wasn't possible before is that a localization of
an extension doesn't break if the extension gets updated and the
localization does not. *Iff* both the extension author and locale pack
author do the right thing with versions and dependencies.

That leads me to a question, I know that the extension compat for the
target application gets updated via amo, does that apply to
dependencies, too?
Which leads me to another question, for target app, do we support
distinct version ranges? I'd just try to add the target app more than
once, as multiple target apps imply an "or" for the different version
checks. For requires, I expect an "and" and thus I wouldn't know how to
depend on an extension 1.0-1.0.* and 2.0-2.0.*, but not on 1.5.

Mike, is
http://developer.mozilla.org/en/docs/Extension_Etiquette#Dependencies
still the statement we want in the extension ecosystem? Just came across
that while searching for deps docs.

Axel

Robert Strong

unread,
May 15, 2006, 6:24:36 AM5/15/06
to dev-pl...@lists.mozilla.org
Axel Hecht wrote:

> Mike Shaver wrote:
>> I thought we had the localization stuff except for "managed locales"
>> (automatic fetching of late-breaking localizations for installed
>> extensions in the user's selected locales, etc.)....?
>
> I wouldn't say "allow for easier localization of extensions". The
> thing we have right now that wasn't possible before is that a
> localization of an extension doesn't break if the extension gets
> updated and the localization does not. *Iff* both the extension author
> and locale pack author do the right thing with versions and dependencies.
And these updates will hopefully be coordinated.

> That leads me to a question, I know that the extension compat for the
> target application gets updated via amo, does that apply to
> dependencies, too?

A dependency *is* an add-on and uses the same update mechanism whether
it is with an add-on defined update rdf in the install.rdf or if one
isn't specified in the install.rdf it will use AMO... so, yes.

> Which leads me to another question, for target app, do we support
> distinct version ranges? I'd just try to add the target app more than
> once, as multiple target apps imply an "or" for the different version
> checks. For requires, I expect an "and" and thus I wouldn't know how
> to depend on an extension 1.0-1.0.* and 2.0-2.0.*, but not on 1.5.

No, version ranges are not supported yet for update. I wrote the
blocklist code to support ranges from the start but the update code will
need to be re-written which is more difficult due to it already being
used throughout the code.

> Mike, is
> http://developer.mozilla.org/en/docs/Extension_Etiquette#Dependencies
> still the statement we want in the extension ecosystem? Just came
> across that while searching for deps docs.

That sounds quite appropriate and I hope shaver agrees. I think it
should go without saying that this applies to people creating locale
packs for someone else's extension as well.

-Robert

Mike Shaver

unread,
May 15, 2006, 6:38:31 AM5/15/06
to Robert Strong, dev-pl...@lists.mozilla.org
On 5/15/06, Robert Strong <rst...@mozilla.com> wrote:
> > Mike, is
> > http://developer.mozilla.org/en/docs/Extension_Etiquette#Dependencies
> > still the statement we want in the extension ecosystem? Just came
> > across that while searching for deps docs.
> That sounds quite appropriate and I hope shaver agrees. I think it
> should go without saying that this applies to people creating locale
> packs for someone else's extension as well.

I don't think we should discourage people from having dependencies on
other extensions. I would rather have someone depend on Greasemonkey
than ship a duplicate copy of it, especially now that we have real
dependency management and updating. And I hope that we have a bunch
of "library extensions" (webdav is one candidate, calendar another, a
beefed-up RDF possibly a third) to encourage use of shared, optional
code among different extensions with similiar needs.

So I would rather have that paragraph say something about being
careful to only express dependencies on things that are really
_required_, and work to dynamically detect optional stuff that you
might know how to work with. And encourage people to build deps
primarily on either their own factored sub-extensions or ones which
are hosted on AMO, for reliability of update and such.

Mike

Robert Strong

unread,
May 15, 2006, 6:43:30 AM5/15/06
to Mike Shaver, dev-pl...@lists.mozilla.org
Mike Shaver wrote:
> On 5/15/06, Robert Strong <rst...@mozilla.com> wrote:
>> > Mike, is
>> > http://developer.mozilla.org/en/docs/Extension_Etiquette#Dependencies
>> > still the statement we want in the extension ecosystem? Just came
>> > across that while searching for deps docs.
>> That sounds quite appropriate and I hope shaver agrees. I think it
>> should go without saying that this applies to people creating locale
>> packs for someone else's extension as well.
>
> I don't think we should discourage people from having dependencies on
> other extensions. I would rather have someone depend on Greasemonkey
> than ship a duplicate copy of it, especially now that we have real
> dependency management and updating. And I hope that we have a bunch
> of "library extensions" (webdav is one candidate, calendar another, a
> beefed-up RDF possibly a third) to encourage use of shared, optional
> code among different extensions with similiar needs.
>
> So I would rather have that paragraph say something about being
> careful to only express dependencies on things that are really
> _required_, and work to dynamically detect optional stuff that you
> might know how to work with. And encourage people to build deps
> primarily on either their own factored sub-extensions or ones which
> are hosted on AMO, for reliability of update and such.
What I got from that was... well,
> Requiring a user to download another extension in order to use yours
> isn't nice. jsLib may be an exception, but always try to avoid
> dependency on other extensions - especially extensions that you don't
> develop.

I still think what you wrote is appropriate. I also think it is
appropriate for anyone creating a locale for someone else's extension to
contact the author and let them know before distributing the locale.

Robert

Mike Shaver

unread,
May 15, 2006, 7:03:32 AM5/15/06
to Robert Strong, dev-pl...@lists.mozilla.org
On 5/15/06, Robert Strong <rst...@mozilla.com> wrote:
> > I don't think we should discourage people from having dependencies on
> > other extensions. I would rather have someone depend on Greasemonkey
> > than ship a duplicate copy of it, especially now that we have real
> > dependency management and updating. And I hope that we have a bunch
> > of "library extensions" (webdav is one candidate, calendar another, a
> > beefed-up RDF possibly a third) to encourage use of shared, optional
> > code among different extensions with similiar needs.
> >
> > So I would rather have that paragraph say something about being
> > careful to only express dependencies on things that are really
> > _required_, and work to dynamically detect optional stuff that you
> > might know how to work with. And encourage people to build deps
> > primarily on either their own factored sub-extensions or ones which
> > are hosted on AMO, for reliability of update and such.
> What I got from that was... well,
> > Requiring a user to download another extension in order to use yours
> > isn't nice. jsLib may be an exception, but always try to avoid
> > dependency on other extensions - especially extensions that you don't
> > develop.

The first sentence is fine, but the second one is wrong: you shouldn't
always try to avoid dependencies on other extensions; in many cases
it'll be exactly the right thing to do. My "only express as
dependencies things that are _required_" point was aimed at people who
might add something to their extension that integrates optionally with
another extension, and that they should not add that as a <requires>
in the install.rdf.

> I still think what you wrote is appropriate. I also think it is
> appropriate for anyone creating a locale for someone else's extension to
> contact the author and let them know before distributing the locale.

There are a bunch of ways to go there, but I suspect that an extension
localizer will almost always want to be in contact with the extension
author for their own sake, and the cases that aren't caught in that
"almost always" can be handled one at a time. Hard cases make bad
law, and all that.

Mike

Robert Strong

unread,
May 15, 2006, 7:09:34 AM5/15/06
to dev-pl...@lists.mozilla.org
Axel Hecht wrote:
> Not sure if we're talking about the same thing.
> <snip>
I see what you are getting at. That is not implemented - see the wiki
for additional info on what is and what is not implemented.
http://wiki.mozilla.org/Extension_Manager:Extension_Dependencies

For that specific issue
http://wiki.mozilla.org/Extension_Manager:Extension_Dependencies#Item_Updates_.28future.29

Robert

Mike Schroepfer

unread,
May 15, 2006, 10:21:27 AM5/15/06
to Jeff Schiller
There was an issue on the server-side redirect which was fixed last
weekend. So it should be better now.

Schrep

0 new messages