Closed Bug 248213 Opened 20 years ago Closed 20 years ago

Update extension GooglebarL10N

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

Product:
addons.mozilla.org Graveyard
Component:
Public Pages
Platform:
All
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: Alexander_Pircher, Unassigned)

Details

Attachments

(1 file)

Version incremented googlebar xpi causing FF 0.9 to lock up on restart
101.54 KB, application/x-xpinstall
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7) Gecko/20040616

Googlebar is only listed as Extension for Firefox
(http://update.mozilla.org/extensions/moreinfo.php?id=33&vid=34&category=Search%20Tools)
Also list this as a Mozilla Extension.

Also please add GooglebarL10N to Mozilla & Firefox Extensions which is
the localized version of Googlebar: http://googlebarl10n.mozdev.org/

Both should be listed in Category "Search Tools".


Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Please list the versions of Mozilla 1.x that these work with, as well as XPI
URLs so that I don't have to hunt for them.
Assignee: nobody → 9quawbieby0001
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Alan,
Please get the latest one for firefox, as the .16 said it worked w/version 0.7 -
0.9. That version is 0.9.0.20 and works much better with the changes. 

the url for Firefox 0.8+ is 
http://downloads.mozdev.org/googlebar/XPI-firefox.xpi

the url's for all seamonkey and pre firefox 0.8+ 
http://downloads.mozdev.org/googlebar/XPI-stable.xpi


The translated versions require a parameter to be passed to the installer.
German (de-AT/de-CH/de-DE)
http://googlebarl10n.mozdev.org/googlebarl10n/0.8.0.22/googlebarl10n-0_8.xpi?de-AT

Italian (it-IT)
http://googlebarl10n.mozdev.org/googlebarl10n/0.8.0.22/googlebarl10n-0_8.xpi?it-IT

Spanish (es-ES)
http://googlebarl10n.mozdev.org/googlebarl10n/0.8.0.22/googlebarl10n-0_8.xpi?es-ES
We do not handle localized extensions yet.  There's already a bug filed.  But
I'll put a link to that section of your site.
http://googlebarl10n.mozdev.org/googlebarl10n/0.8.0.22/googlebarl10n-0_8.xpi
without the parameter will work too. The Install-Dialog will be in English,
but afterwards it will run in the language set in the Browser-Preferences
(if available, currently: German, Italian, Spanish).
What applications is GooglebarL10N for?  
GooglebarL10N is for Searching within Google like Googlebar.
The only difference is that GooglebarL10N is the localized
version of Googlebar, which means that the Menues & Texts
are written in (at the moment) German, Italian or Spanish.

I meant, is there a separate version for Firefox?
Whiteboard: In queue
Ok, hold the presses. In our testing, upgrading does not work. It results in
that lovely perma-box "upgrading" and in some cases, a dead profile.

The (about to be) attached 0.9.20 xpi works fine on a clean install.  

I'm betting the problem is in FF -- and highly suggest we hold off pushing a
browser killing update to 10's of thousands of people. We'll update this bug
with results with the 9.1 branch asap. Are there known successes of upgrade
working with 0.9?

We do have a few more features/fixes scheduled to land this weekend (Google
Local fun!), so please do not use the attached file in any event.

In the googlebar tradition of not adhering to the one-idea-per-bug rule, is
there a bug somewhere detailing how extension developers are meant to interact
with u.m.o in the future? I love bugzilla, but this is RELEASE EARLY, RELEASE
OFTEN territory.   
Only try this with a profile you care about if you have never installed
googlebar.
In the future, you'll be able to maintain your listing yourself.  Until then,
just reopen this bug.  

I was ok installing 0.9.0.20, but if you're saying that it doesn't install over
the old one cleanly... have you tried just uninstalling the old one first? 
Maybe the old one doesn't uninstall cleanly.
In the future, please don't attach XPIs to bugs, but rather just include a link
for download it from.
Thanks.
They linked to the XPIs at the top of this bug; it's in the queue already, so
don't approve the Firefox one until this is straightened out.
Ok, sorry for the bad form, but I'm not convinced that Firefox 0.9 is capable of
updating an extension.  

Uninstalling does allow 0.9.20 to install, but that doesn't help us in the case
of u.m.o.

Other experience with attempted updates in a Uzilla project also resulted in a
corrupted profile.
What's the status here? and does this affect Googlebar or GooglebarL1ON?
Unless an error can be found in the attached .xpi, it's our conclusion that FF
0.9 does not have functional update.  So hold the presses on the firefox
versions until 0.9.1. We'll update the xpi's with a minimum version of 0.9.1 for
u.m.o and explain the whole sordid story at mozdev.

The international versions are Mozilla only I believe and are ready for posting.
Reopen for Firefox whenever you get it straight.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: In queue
Uh, ok. But this situation resolves from bugs in Firefox, not googlebar for the
record.  It's not us that needs straightening :)

The installer does work in Firefox 0.9.1 correctly even with a previous
googlebar install.  However, this still leaves 0.9 users in a lurch as
installing over there     existing googlebar install will kill their browser.

We tried to use the install.rdf to limit the installer to version 0.9.1 of
Firefox -- no go. The inability to recognize the .y in x.x.y version
restrictions is a serious issue.
Status: RESOLVED → VERIFIED
Internally, Firefox 0.9.1 thinks it is 0.9 for compatibility's sake.  Not that
it makes you feel any better, but that's why.

Whatever problem you guys are having with Firefox itself, file a bug against the
extension manager or whatever.  Feel free to reference this bug, etc.  I've had
other upgrades go fine, as long as the update.rdf isn't on UMO.  
Leaving a quick "first version" on mozilla's "update" facility, was hardly our
intention. Quoting Andy Ed, "RELEASE EARLY, RELEASE OFTEN", we do. 

The versioning routes taken by firefox devs have left us no choice but to wait
for firefox version 1.0, unless you can work with us to improve the situation
somewhat. That would leave much to be desired... putting it kindly.

Suggestions or requests, however you want to take it.

1. Can we include an advisory string in an rdf update notice? I suspect not. I
see nothing in Ben's api description providing for it.(If there is no way for us
to give alerts/instructions to our users... then someone needs to fix that.)

2. There should also be an "Uninstall then Update" tag/directive in the EM. In
the real world they call it r&r, remove and replace.

3. Is there any headway being made on developers having a way to interact with
users? (Just watching people comment is less than we are used to doing, as we
like to help them out in a pinch.)
Changes to the API need to be addressed in bugs for the Extensions component. 
If you like, we can unhide your email address so that people can mail you.  
This is more about the u.m.o, than the changes made to the next Firefox.
The main issue is... Leaving a quick "first version" on mozilla's "update"
facility, was hardly our intention. Quoting Andy Ed, "RELEASE EARLY, RELEASE
OFTEN", we do. 


Well how about item 3?
It would seem appropriate, if there is the possibility of trashing browsers in
mass, then there should be a place reserved for our responses in the blame game
that will quite naturally follow? 

I'd like to try and find some solutions here. If I have to put out a custom
version for u.m.o, fine. 

My email address? It looks visible here... but I'm not looking for any more
spam... can't stand the stuff. :)

If you have a new version, then reopen this bug.  Eventually you'll be able to
update UMO yourself.  If you have your own update.rdf, say on mozdev, then that
can point people to downloading updates from mozdev.
We have had ten new versions since u.m.o put ours out. The concern here is if we
update the u.m.o version... alot of browsers will be rendered useless. We are
currently distributing 0.9.0.26!

The file you have distributed, has hardcoded in the install.rdf, that update
information is available from your site. Those firefoxes will ask your site.
We omitted the <em:updateURL> tag, thus leaving Firefox to ask you about update
information.

Leaving those users with version 0.9.0.16 for 3 months is not acceptable.
The web service that is supposed to run on UMO is not working, afaik.  This is
why I recommend you host your own update.rdf.  Any change to the API will still
need to be done by Ben.
Folks, I don't think the problem is clear here:

Based on our testing, if we trigger an update at u.m.o to our latest version,
any FireFox 0.9 user who installs will end up with a corrupted profile.

We're trying to avoid that problem.

Clearly, we can't change 0.9.  We can change u.m.o.  A simple warning message
would solve our problems. It would read (triggered only by a 0.9.0 user agent):

"CAUTION! Please uninstall Googlebar before upgrading.  Alternatively, upgrade
to the latest Firefox".

For that matter, with the ability to load in custom HTML, we could actually hide
the update link and present the matter more forcefully.
You're really barking up the wrong bug.  But I really wonder why it is that
users of your extension booger their profiles, but not other extensions do not.
in #24
> The web service that is supposed to run on UMO is not working, afaik.
What does this mean... no extension update information is available to firefoxes
that ask for it? The server does not answer with any version information?

If the answer to that is yes... well we can just make an update ready.
[ "But I really wonder why it is that
users of your extension booger their profiles, but not other extensions do not." ]

I'm not going to take that... that's a bunch of bull.

Take a look... bug 246687 bug 246935 learn something.
and likely caused by what's briefly mentioned in bug 248971

I agree with Jason Chu's comment in bug 246687#c27 

Let's be civil; at any one time, anybody's extension is screwing up somebody's
Firefox profile.

I've had my own extensions bite me when I've tested install.rdf based install,
although my Fx builds are bleeding-edge : ]
Indeed, I can't argue that we're barking up the wrong bug.

However, can you provide an example of an extension that works in 0.9 with an
install.rdf update?  We believe there really is a bug there, likely due to
localization, but have not heard of anyone successfully updating running 0.9.  A
post to mozdev project owners yielded no reports.  Thx.
I've successfully used the updater for a few of Pike's extensions.  I'm not sure
what you mean.
1. The latest Googlebar for Firefox is 0.9.0.27, start distributing that xpi,
the url for which is http://downloads.mozdev.org/googlebar/XPI-firefox.xpi

but at the same time... 
2. NOT create an "update available" rdf file, which triggers update
notifications available to End Users, then do so.

The aim here is to update the file, and avoid BLIND end user automatic upgrading.

I might as well put them all in one spot so I can find 'em later. 
Here's another one. http://forums.mozillazine.org/viewtopic.php?t=85021
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
> but at the same time... 
> 2. NOT create an "update available" rdf file, which triggers update
> notifications available to End Users, then do so.

For the record, the Update service that Firefox checks to trigger that update
for Extensions/Themes, is not implemented yet, it's planned to be up by 1.0RC1.
Therefore, Firefox gets no automated information about Updated Extensions and
Themes unless you've specified a custom update.rdf in the extension install.rdf.
What will happen when the service is set up and 0.9/0.9.x browsers ask it? That
I don't think is known. :-/  So, updating the file on the site will not cause
any non end-user caused updating.

Putting a warning for Version Notes for this version to warn 0.9.0 users to
uninstall first is a good idea for this situation. and about the only thing that
can be done.
wolf,

["For the record, the Update service that Firefox checks to trigger that update
for Extensions/Themes, is not implemented yet, it's planned to be up by 1.0RC1."]

I had asked for this information earlier. same bug 248213#24
Thanks for clearing this up.

Browser stats reveal there are still 0.9.0 users in sufficient numbers to
prevent any automatic update possibility. If extensions could restrict
installations with subminor version numbers, this would have been easy to handle. 



So implement a bogus update.rdf URL in your install.rdf.  That will override the
web service.  People won't know you have an update available, and may file a bug
against UMO, but it would cover your situation.
Status: REOPENED → ASSIGNED
Googlebar version 0.9.0.27 has been added to the Mozilla Update database and is
awaiting review
Whiteboard: In queue
As long as it will be just the file... and not an update.rdf for the googlebar.
Just make 2 changes to the file you have, version 0.9.0.27...

1. Change the versionMax to 0.9 in the install.rdf.
2. The updateURL will be http://googlebar.mozdev.org/update.rdf

The file is there but being served as text/plain instead of text/rdf, but it is
better than no file at all.

Since there is no way for us dev's to interact with the user, and we have to go
through you... for everything... I am preparing an update to that file that will
have updates pointed to mozdev. In short, it will be best to let it break, or
stay just in the 0.9+ series.

(I am currently reading Ben's new stuff on what the EM is capable of now.)

I surely hope he has created a remove and replace tag we can use, as references
to missing overlays... Firefox's Communicator compatibility layers not ours!,
require it. 

I made the xpi with those changes... and put it on a site that will serve it
immediately, unlike mozdev, which takes 2 hours and then those secondary mirrors
take unknown amounts of time... to retrieve it. Some even stop once in a while.

So for now, you can grab 0.9.0.28 at:
http://mysite.verizon.net/johnrw/public/XPI-firefox.xpi which has the changes
that point the update.rdf to mozdev. 
Your site is serving it up as plain text.  Try renaming it to .zip
I have written Verizon's admin about this... because I can't treat the problem
using an .htaccess file with the appropriate mime setting for .xpi files.

Shift clicking will give a save as dialog.
I just let mozilla download the whole thing in the content area, and than save
as works also. The zip still checks out fine.

Okay, I'll rename it.
http://mysite.verizon.net/johnrw/public/XPI-firefox_0_9_0_28.xpi.zip

By the way... there is a theme for Mozilla, with Arvid Axelsson's Qute theme
there. I noticed you have no themes for Mozilla. I have Arvid's approval to put
that here, as he looked it over for QC concerns etc. So as long as you give the
credit to the theme as...
Artwork: Arvid Axellson
Assembly:Robert Morris and John Woods

...everything is okay. 
It works in 1.7.1 and 1.6, but may need some touching up for 1.8. It installs in
1.8 fine but I noticed some cosmetic differences.(or thought i did)

that is at:
http://mysite.verizon.net/johnrw/public/quteMoz.jar

there is also an xpi... but Arvid's one condition was that there would be no XPI
used. Do I need to do this on another bug?
Firefox version is now also in the queue.  Please file a separate bug for Qute,
since someone with Moz 1.x (ie not me) will need to verify it.
Making its way to the mirrors.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Hardware: PC → All
Resolution: --- → FIXED
what the heck is taking this update so long?
You'll need to be more specific than that.  It is possible that you're seeing a
manifestation of bug 248919
Whiteboard: In queue
(In reply to comment #43)
> what the heck is taking this update so long?

There's not any version of Googlebar or GoolebarL10N in the pending queue,
everything that's been added to it has been approved.
If it's just that you're not seeing the newest version over an older, then that
is Bug 248919.
Please add this to the extensions for mozilla suite. It is version 0.9.0.28 for
mozilla suite and (firefox below 0.8+) only. 

I also noticed people are trying to install the Firefox stuff into mozilla
1.7.2. (and giving poor reviews for it's failure.) The link "Install Now" should
read Install for Firefox if umo doesn't use the useragent in selecting the file
to use. (They seem to be hardcoded links.) Are there any plans to use the
useragent string when processing this link?

http://downloads.us-east3.mozdev.org/googlebar/XPI-rimental.xpi

Since we use 2 different installers, and maintain them... maybe the moreinfo
page should have 2 install links... where people can see there is a choice.
ok fellas...
Xpi for the next firefox version. This XPI is for firefox version 1.0 ONLY.
http://mysite.verizon.net/johnrw/public/XPI-firefox_0_9_0_29.xpi

When are you guys going to get the developer response area finished?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Dev panel is bug 254925.  The website is supposed to be doing userAgent detection.
In the future, can you include an install.rdf in the moz 1.x package, too?  Its
optional (bug 246891), but will make UMO easier to administer.

Moz 0.9.0.28 and FX 0.9.0.29 now in queue
Status: REOPENED → ASSIGNED
Whiteboard: In queue
The queue has been approved.  If you get a 404 error after 30 minutes, please
reopen bug 259282.  If the link installs the wrong version, please comment on
bug 259410.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Here's the Googlebar for Firefox 1.0 location.
thanks.

http://downloads.mozdev.org/googlebar/XPI-firefox-1_0.xpi
According to the status whiteboard, your item has been tested and added to the
queue.  The queue has now been approved.  If your update does not appear on the
site, please reopen this bug and clear the status whiteboard.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This doesn't appear to have been processed, it was wrongly resolved.
Status: REOPENED → NEW
Whiteboard: In queue
alan,
it's been days and no googlebar update... please leave this bug open until the
thing shows up for the install now link. Also the new version is 0.9.0.30 for
the firefox 1.0 version.
Status: NEW → ASSIGNED
Whiteboard: tested+
Whiteboard: tested+ → In queue
The queue has been approved.  Please be sure to clear the status whiteboard when
you reopen a bug.  Thanks.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Bulk Moving Extension/Theme listing bugs to new component.
(Filter: masslistingspam)
Component: Update → Listings
Product: mozilla.org → Update
Version: other → unspecified
The international Version of Googlebar for Firefox 1.0 has been released
(based on Googlebar 0.9.0.30 for Firefox 1.0):

GooglebarL10N with at the moment (English), German, Italian and French:
http://downloads.mozdev.org/googlebarl10n/0.9/googlebarl10n-firefox-1_0.xpi

Du to the mirror-concept of mozdev it may take still a few hours to get
the URL working.

PS.: WTF is the Status Whiteboard?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status whieboard: the box at the top of the bug form.  The thing I just cleared.
Whiteboard: In queue
Assignee: Bugzilla-alanjstrBugs → nobody
Status: REOPENED → NEW
Mozdev should be mirroring again.
Whiteboard: needs testing
GooglebarL10N identifies itself as Googlebar instead of GooglebarL10N, so I
can't approve 0.9.0.30 of it.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WONTFIX
Summary: Add Extensions Googlebar for Mozilla and GooglebarL10N for Mozilla & Firefox → Update extension GooglebarL10N
Whiteboard: needs testing
AMO BUGSPAM FOR COMPONENT MOVE AND DELETE (FILTER ME)
Component: Listings → Web Site
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: