Closed Bug 295732 Opened 18 years ago Closed 17 years ago

extensions fail to install with unexpected error -203

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: tracy, Assigned: jaas)

References

Details

(Keywords: helpwanted, regression, smoketest, Whiteboard: [cb] recent reproduction probably related to bug 298478, which might fix this)

Attachments

(1 file, 1 obsolete file)

patch
1.63 KB, patch
benjamin
: review-
Details | Diff | Splinter Review 
Seen on Mac Deer Park build 2005-05-27-07-trunk

-Use Extension manager to "Get More extensions"
-Choose an extension (tested with flashgot, adblock and a few others)
-Install Now
-Click Install Now to the permission dialog

tested results:progress begins in the Extension Manager, but then an error
message appears saying that the extension could not be downloaded. unexpected
error -203

This appears to be Mac only; Windows and Linux were able to install compatible
extensions successfully.
Probably related:
Themes can't be installed either. No Theme Manager progress, no error.  Just
doesn't install.  After theme installation fails, reattempts run into the same
problem as bug 295366, in that we then bring up a file choser.


could this (also) be related to bug 286299 comment 5?
Flags: blocking-aviary1.1?
Flags: blocking1.8b2+
I am very sure that I have seen the 203 error before when testing bug 295013. I
believe this may be related to an RDF data source being opened from a zip file
and the zip file being held open by the zip reader cache. It is possible that
the patch in bug 295013 may fix this.
-203 is completely unspecific. In the Suite this would mean a failure to run a
native executable. Unfortunately EM installs reused this code instead of adding
one, but either way it's pretty darn generic:
http://lxr.mozilla.org/mozilla/source/xpinstall/src/nsSoftwareUpdateRun.cpp#511

Any failure whatsoever in EM installation will come out with the same code. It
could be the zip cache stuff mentioned in comment 3, it could be OOM (unlikely),
inability to copy files, errors parsing install.rdf, anything.

Ignore the error message saying it failed to download. Except for an actual
download failure error code (-207) that's never the case, we've downloaded and
failed while installing. For -203 in particular there's no way to get that error
unless we've already downloaded.
Summary: extensions fail to download with unexpected error -203 → extensions fail to install with unexpected error -203
The OOM error case (-299) appears to be handled so unless I am mistaken that
isn't the case here. Also, several other cases are handled though -203 is not.
http://lxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/chrome/global/xpinstall/xpinstall.properties#102
Also, the "errors parsing install.rdf" case is handled elsewhere as well as
several other cases.
http://lxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties#57
I tried to duplicate on Mac OS X using a tinderbox build from 20050527 without
experiencing this bug. I installed adblock, flashgot, and wayback all from the
first page available to install these ext's from UMO's main page which was
reached by clicking get more extensions using the steps as outlined in comment
#0. After restarting all 3 ext's worked as expected. I also tried reinstalling
them multiple times during one session and didn't experience this bug. I was
using a new profile so this may have had something to do with it.
Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2)
Gecko/20050528 Firefox/1.0+ (PowerBook) - and also the official 0528 nightly -
extensions installed smoothly (from https://addons.mozilla.org/).

Both with a new profile and my old profile.
I can't reproduce this installing any extensions or themes. I tried switching
back and forth between profiles from FF 1.0.4 and the latest Deer Park,
installing extenions in both and then the other.

Mac OS X 10.4.1, G5
I'm pretty sure bug 295013 will fix this, but that patch is rather scary for
1.1a1: is this consistently reproducable on mac or only intermittently?
Assignee: nobody → moz_bugzilla
Depends on: 295013
Using Deer Park 2005-05-31-07-trunk

I can not reproduce this on my 10.3.9 machine.  The machine I was testing on at
MoFo was a G3 running 10.2.  I've asked Marcia to retry on that machine with
todays build.
going to minus based on seems to affect a limited number of users.  sort out for b3
Flags: blocking1.8b3+
Flags: blocking1.8b2-
Flags: blocking1.8b2+
testing with 2005060307-trunk deer park bits on Mac OS X 10.2.8 (the same G3
that Tracy had originally seen this on), this is no longer a problem! I was able
to successfully install FlashGot, Web Developer and PDF Download extensions.

marking w4m --the fix for bug 295013 prolly did the trick!
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary1.1?
Status: RESOLVED → VERIFIED
Summary: extensions fail to install with unexpected error -203 → extensions fail to install with unexpected error -203
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
I sse this error when i've trying to install tinderstatus from
http://tinderstatus.mozdev.org/index.html#install
More information is needed... I am unable to reproduce this using Mozilla/5.0
(Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050610 Firefox/1.0+
on Mac OS X 10.3.5

I installed and upgraded tinderstatus several times from the link provided into
a new profile and an existing profile.
using:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050610
Firefox/1.0+

had the 'error -203' problem when trying to install 'Flash Block' in Deerpark
Alpha 1 (the original release). Upgraded to the aforementioned release which
didn't fix this problem. Just wiped my profile which enabled me to install
'Flash Block' without incident.
There were several issues that have been fixed since the Deer Park Alpha 1
release and there may have been remnants left behind of these problems in the 
profile after upgrading to it and then to a recent nightly. If this can be
nailed down to exact steps to reproduce the error it would be very much appreciated.
Note: I'm starting to think this may have something to do with it trying to
install from one of the mirrors that appear to at times fail on all platforms
though not with this same error.
I am getting "Unexpected error -203" with a Linux trunk build from 20050611
using a fresh profile.  I tried installing adblock and compact menu from
http://www.projects1.com/firefox/exthacks/FFnightlyextensions.html.  So I don't
think this is Mac only. 
(In reply to comment #19)
> I am getting "Unexpected error -203" with a Linux trunk build from 20050611
> using a fresh profile.  I tried installing adblock and compact menu from
> http://www.projects1.com/firefox/exthacks/FFnightlyextensions.html.  So I don't
> think this is Mac only. 
This may shed a little light on this. The extensions on that page are not served
with the correct mimetype of application/x-xpinstall for them to install
directly from that page and the only way you should be able to install them is
either by downloading them and installing from the local filesystem or dragging
the link onto the EM window. I have also at times seen some of the mirrors serve
with the wrong mimetype though I have never seen the -203 error when this occurs.

When you try to install from that page does the extension manager actually open
or is a save as dialog shown? Can you procide the exact steps you performed to
install from that page?
note: bug 289335 has more info on this problem
(In reply to comment #20)
> When you try to install from that page does the extension manager actually open
> or is a save as dialog shown? Can you procide the exact steps you performed to
> install from that page?

I probably should have specified how I tried to install the extensions.  I saved
the extensions before trying to install them.  I then dragged them into the
browser window and pressed the install button when it appeared.  The extension
manager opened and appeared to install the extension but just before the point
where you are told you must restart Firefox to use the extension is where the
error message pops up.
Attached patch patch (obsolete) — — Splinter Review 
This puts the error handling on the em once the em has been handed off the
install. Though I am unable to reproduce this error I suspect that the reason
it is failing is solved by this patch as well by closing the zipreader before
handing off the xpi to the em.
Attachment #186007 - Flags: superreview?(dveditz)
Attachment #186007 - Flags: review?(benjamin)
mozfly - could you also check the js console immediately after this error occurs
and tell me if there are any messages reported? Also, sometimes the em code may
report errors as info messages.
(In reply to comment #24)
> mozfly - could you also check the js console immediately after this error occurs
> and tell me if there are any messages reported? Also, sometimes the em code may
> report errors as info messages.

The error in the js console was:

Error: [Exception... "Component returned failure code: 0x80570019
(NS_ERROR_XPC_CANT_CREATE_WN) [nsIJSCID.createInstance]"  nsresult: "0x80570019
(NS_ERROR_XPC_CANT_CREATE_WN)"  location: "JS frame ::
file:///home/jason/programs/firefox/components/nsExtensionManager.js ::
openSafeFileOutputStream :: line 440"  data: no]
Source File: file:///home/jason/programs/firefox/components/nsExtensionManager.js
Line: 440

I tried the patch from comment #23 and it suppressed the popup error message but
the extension installation still failed with the same error in the js console.

I did a recompile using gcc 3.3.6 instead of 3.4.5 and the issue no longer
happens for me.  I only in the last few days began using gcc 3.4.5 so the fault
may be with my compiler.

Thanks!

Benjamin & Daniel, I still think the patch makes sense in that the zipreader
should be closed and any errors thrown by nsExtensionManager.js should be
handled there for installs instead of in xpinstall so it no longer displays the
ambiguous -203 error. BTW: It appears that it already does this for themes. I'll
take a look at how best to handle the error with openSafeFileOutputStream.
Attachment #186007 - Attachment is obsolete: true
Attachment #186007 - Flags: superreview?(dveditz)
Attachment #186007 - Flags: review?(benjamin)
Attached patch patch — — Splinter Review 
Benjamin - since creating a safe-file-output-stream does not appear to always
be possible this wraps the creation and falls back to creating a
file-output-stream if it fails. The corresponging close function already took
this into account as follows so I suspect failures had been seen when this was
originally written:
function closeSafeFileOutputStream(stream) {
  if (stream instanceof Components.interfaces.nsISafeOutputStream)
    stream.finish();
  else
    stream.close();
}
Attachment #186075 - Flags: review?(benjamin)
Do we know *why* the safe file output stream isn't available? That's kinda scary.
(In reply to comment #28)
> Do we know *why* the safe file output stream isn't available? That's kinda scary.
I've looked into it a bit without success. Until why is sorted I think it may
just be best to stick with a file stream instead of a safe file stream. Also,
this and the update code are the only ones currently using a safe file stream
from JS.
cc'ing dwitte for insight on nsISafeFileOutputStream.

Dan, can you help out with this bug. This is the first consumer I know of for
nsISafeFileOutputStream from JS and it appears that createInstance fails on some
OS's and may be due to using a different compiler - see comment #25
It was mentioned on irc that this may be due to bug 280234
So much for that... it appears that the patch in 280234 does not fix this bug.
No longer depends on: 280234
Attachment #186075 - Flags: review?(benjamin) → review-
I am still unable to reproduce this bug. Adding keyword helpwanted
Keywords: helpwanted
Reassigning owner since I am still unable to reproduce this bug.

Josh, could you take a look at this since it appears to affect Mac OS X?
Assignee: rob_strong → nobody
Status: REOPENED → NEW
This works for me on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8b2) Gecko/20050623 Firefox/1.0+ with OS 10.4.1. I was able to install both
flashgot and adblock without any error messages or other signs of trouble. 

Tracy: were you running 10.4 or 10.3? 
see my comment #11, the only machine I ever saw this on was a G3 running 10.2
(the green machine in the area where blake kaplan is working).
I'll give this a try with that machine on Monday as I don't have a copy of 10.2
handy. 
Now I'm seeing this on Linux DP trunk build 2005-06-28-05-trunk.  But I wonder
if it has anything to do with bug 298478.
Whiteboard: [cb] reproduceable on Linux and Mac. no progress for 1.8b3.
Whiteboard: [cb] reproduceable on Linux and Mac. no progress for 1.8b3. → [cb] recent reproduction probably related to bug 298478, which might fix this
Josh, could you take a look? Or help find another owner.
Assignee: nobody → joshmoz
I could reproduce this on the first try with a late June 27th CVS debug build. I got two js errors, one of 
which Ben fixed this morning (the 28th, it was a js syntax error), and also this:

Error: Components.classes['@mozilla.org/updates/version-checker;1'] has no properties
Source File: file:///Users/josh/src/ff_debug/mozilla/ff_debug_obj/dist/DeerPark.app/Contents/MacOS/
components/nsExtensionManager.js
Line: 183

I did not see anything about file I/O as discussed above. I don't know what the error posted above 
means...
Confirming on PC with Linux as well with a trunk build a few hours old. Setting
platform and OS to All.
OS: MacOS X → All
Hardware: Macintosh → All
Please wait for a build that includes Ben's fix that Josh mentioned. A -203
error is a general failure error from xpinstall when the extension manager
throws an unhandled error. The -203 error you are seeing on Win32 - I suspect
all platforms that don't have the fix actually - is due a different issue than
this bug.
This bug was reported 2005-05-27. The syntax error that Ben fixed did not exist in revision 1.13 of 
the file, which is from 2005-06-06. So, I don't think Ben's syntax fix solved the problem.

The following link shows revisions to the file over the past month:

http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&file=mozilla/toolkit/mozapps/update/src/
nsUpdateService.js.in&date=month

There were (+3482/2329) lines changed. That is a lot. So, if error -203 is really cause by a syntax 
error, then there could have been previous syntax errors, which may account for difficulties 
reproducing.

That said, I don't think that is a reliable account of what is going on here. I didn't see anything other 
than the error I pasted in comment #40 that looked funny in either the js console or gdb when I got the 
error. However, this isn't really my area of specialty, and I think someone else should look into it. We 
should solve this ASAP and I'm out of ideas, especially since this now appears to be problematic on all 
platforms.
Sorry for the bad text formatting - Safari really sucks on bugzilla. Text submission is weird as you can see, 
and also history just gets forgotten a lot. Example: When I click on a patch, I can't go back to the bug by 
any means...
What Ben broke and then fixed in nsUpdateService.js.in caused the generic -203
xpinstall errors for ALL systems when installing an extension and I was
concerned that this bug would morph into somethting even more difficult to
narrow down. AFAIK so far it seems to mainly affect Mac OS X (possibly only
10.2) and there has been one report from a Linux user.

BTW: I file bug 299085 for the issue with the generic error message.
Also, comment #25 has a js console error where it is failing which is
var fos = Components.classes["@mozilla.org/network/safe-file-output-stream;1"]
                    .createInstance(Components.interfaces.nsIFileOutputStream);
I cannot reproduce this with 2005062907 trunk on the Blue&White G3 where Tracy
originally saw this problem (running os 10.2.8). Extensions install normally. Is
there anyone out there who can reproduce this with today's build? If not, I
sugguest that this be taken off the blockers list. 
->wfm after consultation with Tracy. Reopen if you are able to reproduce.
Status: NEW → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → WORKSFORME
verified wfm....will let bug 299085  handle the error message.
Status: RESOLVED → VERIFIED
filed bug 299168 about the safestream failure (comment 25).
Please reopen this bug.

This today Happens with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8b4) Gecko/20050723 Firefox/1.0+

Did not happen for me with yesterday's 20050722 Firefox 1.0+ build.

Tried a new Profile, still happens.  I see this has been fixed before, but it's
the first time I've happened to experience it.
My apology for posting twice, details herewith

this is the Javascript error associated with this Error -203 attempting to
install extensions today, for me.

This happens both from the extension home page and by downloading the .xip to
the desktop first -- although the behavior of the window differs,

From the web, it simply looks like it installs then that line in the Extensions
window disappears.

Window behavior is a bit more complicated when I drag the .xip from the desktop,
but the end result is the same.

For Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050723 Firefox/1.0+

attempting an extension install gets Javascript errors that look like this
(edited so they don't try to be links from this page)

Error: installLocation has no properties
Source File:
...Users/~/Applications/DeerPark.app/Contents/MacOS/components/nsExtensionManager.js
Line: 6327

and this:

Error: Components.classes['@mozilla.org/xpcom/version-comparator;1'] has no
properties
Source File:
...Users/~/Applications/DeerPark.app/Contents/MacOS/components/nsExtensionManager.js
Line: 172

Hank - the -203 error is a generic xpinstall error for ALL Extension Manager
install failures. The bug to fix the generic error is bug 299085 as can be seen
in comment #45. The bug you are experiencing is bug 301875


I was having this problem with DeerPark Alpha 1 on OS X 10.4.2.  I uninstalled a couple of extensions 
through the Extensions dialog, then extension installation started working again (the -203 error went 
away.)  Both the last time I got the error and the first time it worked, I was trying to install the same file.  
Hope this helps.  I didn't keep track of which extensions I uninstalled.
Has anyone experiencing this tried blowing away the extensions.rdf file and extensions directory in their 
profile?
Jason, the original bug was for a specific issue with nsISafeFileOutputStream
that is no longer an issue. If you are still getting errors with -203 in the
alert then you are not using a recent build since that was removed from the
alert to lessen the likelihood that people would confuse one bug with another
bug per comment #45 and was removed in bug 299085. The -203 error is a generic
error and is shown when ever an unhandled error occurs in the extension manager
install code and chances are what you experienced is not this bug. Try updating
the build you are using to see if it resolves this issue for you.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.