Update extension GooglebarL10N



addons.mozilla.org Graveyard
Public Pages
14 years ago
2 years ago


(Reporter: Alex Pircher, Unassigned)




(1 attachment)



14 years ago
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
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:

Comment 1

14 years ago
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
Ever confirmed: true


14 years ago

Comment 2

14 years ago
Please get the latest one for firefox, as the .16 said it worked w/version 0.7 -
0.9. That version is and works much better with the changes. 

the url for Firefox 0.8+ is 

the url's for all seamonkey and pre firefox 0.8+ 

The translated versions require a parameter to be passed to the installer.
German (de-AT/de-CH/de-DE)

Italian (it-IT)

Spanish (es-ES)

Comment 3

14 years ago
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.

Comment 4

14 years ago
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).

Comment 5

14 years ago
What applications is GooglebarL10N for?  

Comment 6

14 years ago
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.

Comment 7

14 years ago
I meant, is there a separate version for Firefox?


14 years ago
Whiteboard: In queue

Comment 8

14 years ago
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.   

Comment 9

14 years ago
Created attachment 151790 [details]
Version incremented googlebar xpi causing FF 0.9 to lock up on restart

Only try this with a profile you care about if you have never installed

Comment 10

14 years ago
In the future, you'll be able to maintain your listing yourself.  Until then,
just reopen this bug.  

I was ok installing, 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.

Comment 11

14 years ago
In the future, please don't attach XPIs to bugs, but rather just include a link
for download it from.

Comment 12

14 years ago
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.

Comment 13

14 years ago
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.

Comment 14

14 years ago
What's the status here? and does this affect Googlebar or GooglebarL1ON?

Comment 15

14 years ago
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.

Comment 16

14 years ago
Reopen for Firefox whenever you get it straight.
Last Resolved: 14 years ago
Resolution: --- → FIXED
Whiteboard: In queue

Comment 17

14 years ago
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.

Comment 18

14 years ago
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.  

Comment 19

14 years ago
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.)

Comment 20

14 years ago
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.  

Comment 21

14 years ago
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. :)

Comment 22

14 years ago
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.

Comment 23

14 years ago
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!

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

Leaving those users with version for 3 months is not acceptable.

Comment 24

14 years ago
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.

Comment 25

14 years ago
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.

Comment 26

14 years ago
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.

Comment 27

14 years ago
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.

Comment 28

14 years ago
[ "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 

Comment 29

14 years ago
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 : ]

Comment 30

14 years ago
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.

Comment 31

14 years ago
I've successfully used the updater for a few of Pike's extensions.  I'm not sure
what you mean.

Comment 32

14 years ago
1. The latest Googlebar for Firefox is, 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


14 years ago
Resolution: FIXED → ---

Comment 33

14 years ago
> 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.

Comment 34

14 years ago

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

Comment 35

14 years ago
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.

Comment 36

14 years ago
Googlebar version has been added to the Mozilla Update database and is
awaiting review
Whiteboard: In queue

Comment 37

14 years ago
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

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. 

Comment 38

14 years ago
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 at:
http://mysite.verizon.net/johnrw/public/XPI-firefox.xpi which has the changes
that point the update.rdf to mozdev. 

Comment 39

14 years ago
Your site is serving it up as plain text.  Try renaming it to .zip

Comment 40

14 years ago
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.

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:

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?

Comment 41

14 years ago
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.

Comment 42

14 years ago
Making its way to the mirrors.
Last Resolved: 14 years ago14 years ago
Hardware: PC → All
Resolution: --- → FIXED

Comment 43

14 years ago
what the heck is taking this update so long?

Comment 44

14 years ago
You'll need to be more specific than that.  It is possible that you're seeing a
manifestation of bug 248919
Whiteboard: In queue

Comment 45

14 years ago
(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.

Comment 46

14 years ago
Please add this to the extensions for mozilla suite. It is version 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?


Comment 47

14 years ago
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.

Comment 48

14 years ago
ok fellas...
Xpi for the next firefox version. This XPI is for firefox version 1.0 ONLY.

When are you guys going to get the developer response area finished?


14 years ago
Resolution: FIXED → ---

Comment 49

14 years ago
Dev panel is bug 254925.  The website is supposed to be doing userAgent detection.

Comment 50

14 years ago
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 and FX now in queue
Whiteboard: In queue

Comment 51

14 years ago
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.
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED


13 years ago
Resolution: FIXED → ---

Comment 52

13 years ago
Here's the Googlebar for Firefox 1.0 location.


Comment 53

13 years ago
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.
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED


13 years ago
Resolution: FIXED → ---

Comment 54

13 years ago
This doesn't appear to have been processed, it was wrongly resolved.
Whiteboard: In queue

Comment 55

13 years ago
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 for
the firefox 1.0 version.


13 years ago
Whiteboard: tested+


13 years ago
Whiteboard: tested+ → In queue

Comment 56

13 years ago
The queue has been approved.  Please be sure to clear the status whiteboard when
you reopen a bug.  Thanks.
Last Resolved: 13 years ago13 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

Comment 58

13 years ago
The international Version of Googlebar for Firefox 1.0 has been released
(based on Googlebar for Firefox 1.0):

GooglebarL10N with at the moment (English), German, Italian and French:

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?
Resolution: FIXED → ---

Comment 59

13 years ago
Status whieboard: the box at the top of the bug form.  The thing I just cleared.
Whiteboard: In queue


13 years ago
Assignee: Bugzilla-alanjstrBugs → nobody

Comment 61

13 years ago
Mozdev should be mirroring again.
Whiteboard: needs testing

Comment 62

13 years ago
GooglebarL10N identifies itself as Googlebar instead of GooglebarL10N, so I
can't approve of it.
Last Resolved: 13 years ago13 years ago
Resolution: --- → WONTFIX
Summary: Add Extensions Googlebar for Mozilla and GooglebarL10N for Mozilla & Firefox → Update extension GooglebarL10N
Whiteboard: needs testing
Component: Listings → Web Site


2 years ago
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.