The default bug view has changed. See this FAQ.

"Firefox could not install this item because of a failure in Chrome Registration. Please contact the author about this problem."

RESOLVED FIXED

Status

()

Toolkit
Startup and Profile System
--
minor
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Hilkiah Lavinier, Assigned: bsmedberg)

Tracking

({fixed1.8.0.1, fixed1.8.1, relnote})

unspecified
x86
Linux
fixed1.8.0.1, fixed1.8.1, relnote
Points:
---
Bug Flags:
blocking1.8rc2 -
blocking1.8.0.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Have gotten the below message upon startup in both F1.5 B1 and B2:
"Firefox could not install this item because of a failure in Chrome
Registration.  Please contact the author about this problem."

The dialog box appears with OK as the only option.  Upon clicking OK, the box
reappears requiring another click on OK.  However, after this, all is well and
Firefox continues to load and run.  The UI looks ok and I do not know what the
above message affects.

Reproducible: Always

Steps to Reproduce:
1.Load firefox
2.
3.

Actual Results:  
dialog appeared
Start Firefox in safe mode and see if you can reproduce
(http://kb.mozillazine.org/Safe_mode). If you can't reproduce, it's probably due
to an installed extension.

Comment 2

12 years ago
So I assume the bug here is having to click OK twice? Because otherwise this is
just a normal error due to a extension installation failure (not Firefox's
fault). See also bug 283466 requesting that it tell you what extension is
failing to install.
I can confirm this with en-US and pl Linux builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/1.5rc2-candidates/
and pl build from the http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8-1.5rc2-l10n/

The en-US build's UA is:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

The error appears when a Firefox build installed by the root user is run by a normal user.

The more detailed steps to reproduce this are:

1. Download the build
2. Unpack it as the *root* user
3. Make sure your profile directory is empty (mv ~/.mozilla ~/whatever)
4. Run the newly unpacked Firefox as the non-root user

Actual results:
1. The "chrome registration failed" window appears twice (import profile wizard may appear before these two).

Expected results:
1. Open Firefox normally.

I suppose the reason why this appears twice is because of the two extensions bundled with Firefox (DOM Inspector and Reporter) and the normal user on Linux cannot write to root-owned directories.

This is a major problem for Linux users, so I'm requesting blocking-1.8rc2. 

CC'ing gandalf per his request on IRC; he's also able to reproduce this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8rc2?
CC'ing Pike, bsmedberg. I can confirm that, we shouldn't release with this bug...
(Assignee)

Comment 5

12 years ago
Reporter is not an extension any more, how could it possibly be giving you chrome registration errors? Perhaps you mean talkback and DOMI? But even then, both of these extension ship with chrome.manifest, I don't see how we could even be getting into this situation.
<bsmedberg> gandalf: perhaps attach the entire <installdir>/extensions directory to the bug?

It's 900 kb, bugzilla doesn't like such big attachments, so I'm putting it here:
http://others.aviary.pl/bugs/311480/extensions.tar.bz2
(Assignee)

Comment 7

12 years ago
This is a re-manifestation of bug 302072... the talkback extension is *building* the correct (empty) chrome.manifest, but I never put it in the install manifest for actual shipping. This affects windows too, but since very few people install firefox on windows in an unwritable directory it would be very hard to notice there. This will definitely affect Linux distros such as Redhat/SuSE.

Patch in hand, I'm not sure how we want to proceed though.
Assignee: nobody → benjamin
(Assignee)

Comment 8

12 years ago
Created attachment 202520 [details] [diff] [review]
Package the empty chrome.manifest
Attachment #202520 - Flags: review?(chase)
(Assignee)

Comment 9

12 years ago
Actually this is probably not a problem for Redhat/SuSE because they don't build static and therefore wouldn't be using the manifest.

Updated

12 years ago
Attachment #202520 - Flags: review?(chase) → review+
(Assignee)

Comment 10

12 years ago
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

12 years ago
Comment on attachment 202520 [details] [diff] [review]
Package the empty chrome.manifest

Definitely for 1.5.0.1, probably not worth a respin but we should relnote pretty carefully (and I'll leave that decision up to others).
Attachment #202520 - Flags: approval1.8rc2?

Updated

12 years ago
Flags: blocking1.8rc2?
Flags: blocking1.8rc2-
Flags: blocking1.8.1?

Updated

12 years ago
Keywords: relnote

Comment 12

12 years ago
Comment on attachment 202520 [details] [diff] [review]
Package the empty chrome.manifest

let's look to get this in for the point release.
Attachment #202520 - Flags: approval1.8rc2? → approval1.8rc2-
Why can't this be fixed before 1.5 final? 

This is a really annoying bug for every Linux user (and almost every Linux user installs Firefox 'globally', as root), it makes the user think that Firefox is broken, unpolished.

This patch is really low-risk (I'd even say: zero-risk) and according to this: http://www.squarefree.com/burningedge/2005/11/11/2005-11-11-branch-respin/ there's gonna be a respin/RC3 anyway. So why not check it in for 1.5.0?
(Assignee)

Comment 14

12 years ago
*** Bug 316368 has been marked as a duplicate of this bug. ***

Comment 15

12 years ago
Bug is still there in 1.5rc3. Please fix this for 1.5 final!
(Assignee)

Comment 16

12 years ago
*** Bug 316917 has been marked as a duplicate of this bug. ***

Comment 17

12 years ago
Hopefully it will be fixed (in Windows too). There was never a need to run the program first with higher privileges up until now.
(Assignee)

Updated

12 years ago
Flags: blocking1.8.0.1?
(In reply to comment #7)
> This affects windows too, but since very
> few people install firefox on windows in an unwritable directory it would be
> very hard to notice there.

It would be hard to notice only for home Windows users. 

But corporate IT departments, Internet cafes, universities etc. all install software as root, even on Windows, and users normally don't have write permissions to the "Program Files" directory.

It's sad that you can't add one empty file to 1.5.0 to fix such an annoyance.
(In reply to comment #18)
> But corporate IT departments, Internet cafes, universities etc. all install
> software as root, even on Windows, and users normally don't have write
> permissions to the "Program Files" directory.
> 
> It's sad that you can't add one empty file to 1.5.0 to fix such an annoyance.
> 

Saying things like this will not get approval1.5+ for bsmedberg's patch.

All of the people you listed above are likely to read relnotes and see the workarounds needed to avoid the problem.

*** Bug 315779 has been marked as a duplicate of this bug. ***

Comment 21

12 years ago
(In reply to comment #19)
> (In reply to comment #18)
> > But corporate IT departments, Internet cafes, universities etc. all install
> > software as root, even on Windows, and users normally don't have write
> > permissions to the "Program Files" directory.
> > 
> > It's sad that you can't add one empty file to 1.5.0 to fix such an annoyance.
> > 
> 
> Saying things like this will not get approval1.5+ for bsmedberg's patch.
> 
> All of the people you listed above are likely to read relnotes and see the
> workarounds needed to avoid the problem.
> 

Not a compelling reason to use the software. I think I'll go back to IE if such a blatant problem isn't fixed by default. I don't mind, I don't run as admin so I'll use IE without hesitation.
Please, fix this bug, even if we must wait on a final 1.5 until next christmas, why You want be so fast? 

Please, fix this bug, this is not so small thing - it is issue of the confidence also..

The workaround with reading release notes isn't solving a problem.
Why You want to undermine the confidence of users to MoFo programs?

Please, fix this before 1.5 finall release.

Comment 23

12 years ago
(In reply to comment #22)
> Please, fix this bug, even if we must wait on a final 1.5 until next christmas,
> why You want be so fast? 
> 
> Please, fix this bug, this is not so small thing - it is issue of the
> confidence also..
> 
> The workaround with reading release notes isn't solving a problem.
> Why You want to undermine the confidence of users to MoFo programs?
> 
> Please, fix this before 1.5 finall release.
> 
I hate to add another unimportant post to this bug, but I want to remind everybody that this is not a discussion forum. Asking 'Please fix this bug' is not helpful. If you actually have something to add, a post may be warranted.

Comment 24

12 years ago
Bsmedberg/Asa:  We need to get this into the release notes for 1.5.  Can someone please post the workaround for this bug and attach the relnote txt so Rafael can get it in?  Thanks!

We should really get this +'d for the next point release.
(Assignee)

Comment 25

12 years ago
The workaround is to create an empty file in the following location:
<install-directory>/extensions/talkback@mozilla.org/chrome.manifest

The following paragraph in the release notes is incorrect and should be replaced:

"If you install Firefox 1.5 on a multi-user system in an area in which there is restricted access privileges, you must run Firefox 1.5 as a user with access to that location upon installation so that all initial startup files are generated. If this is not done, when a user without write access to the install location attempts to start Firefox 1.5, they will not have sufficient privileges to allow Firefox 1.5 to generate the initial startup files it needs to."

replace with

"If Firefox 1.5 is installed on a multi-user system in a location which is not writable by users, Firefox must be run once by a privileged user. If this is not desirable, an empty file must be created in the following directory: <install-directory>/extensions/talkback@mozilla.org/chrome.manifest"
relnotes updated
(Assignee)

Updated

12 years ago
Attachment #202520 - Flags: approval1.8.0.1?
(Assignee)

Comment 27

11 years ago
*** Bug 320262 has been marked as a duplicate of this bug. ***

Comment 28

11 years ago
Comment on attachment 202520 [details] [diff] [review]
Package the empty chrome.manifest

Please land on both 1.8.1 and 1.8.0 branches.  Thanks!
Attachment #202520 - Flags: approval1.8.1+
Attachment #202520 - Flags: approval1.8.0.1?
Attachment #202520 - Flags: approval1.8.0.1+
(Assignee)

Comment 29

11 years ago
Fixed on 1.8 and 1.8.0 branches. No "fixed1.8.1" keyword?
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
Keywords: fixed1.8.0.1
(In reply to comment #9)
> Actually this is probably not a problem for Redhat/SuSE because they don't
> build static and therefore wouldn't be using the manifest.

just for completeness ;-)
We build static and would need the manifest file. BUT: This is talkback and we don't have talkback since only the Mozilla Corporation is allowed/able to use it.
Keywords: fixed1.8.1

Comment 31

11 years ago
So can we remove the note ("If Firefox 1.5 is installed on a multi-user system in a location which is not writable by users", see comment 25) from the 1.5.0.1 release notes?
http://www.mozilla.com/firefox/releases/1.5.0.1.html#issues

If we ship these files with 1.5.0.1, there's no need to run once as a privileged user to create them, is it?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.