Closed Bug 60161 Opened 24 years ago Closed 24 years ago

Unknown error 804b0005 appears in status bar

Categories

(SeaMonkey :: Installer, defect, P3)

Product:
SeaMonkey
Component:
Installer
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jhelfert, Assigned: ssu0262)

References

Details

(Keywords: regression)

Attachments

(1 file)

[patch] Fix installer fu for necko files
5.05 KB, patch
Details | Diff | Splinter Review 
Upon loading Mozilla, one is immediately presented with a status bar reading:

An unknown error has occurred (804b0005)

This doesn't appear to affect Mozilla functionality or stability. (that I've
noticed)

Message changes in the last few digits to 0007 if one clicks then on a button in
the Personal Toolbar, and again to 0003 if one clicks on something else in the
same toolbar.

My toolbar contains only two entries; the first is for kuro5hin.org, and the
second is for slashdot.  I clicked on the slashdot one followed by kuro5hin.
(just in case this is important..)
dupe of 59776

*** This bug has been marked as a duplicate of 59776 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Are you sure that this is the same problem as in 59776 ?
I saw this also in my status bar but never 804b0010 ?
I see 804b0005 (see bug 60091).
The bug 59776 is reported at 11/13 but this seems to be introduced at the 11/14


I agree with Matti. This didn't show up until the 11/14 nightly build. It
doesn't seem to have any effect on functionality (the 11/14 build seems to be
just as solid as the 11/13, if not mroe), but it's still disconcerting to see an
error message on every page load
I don't think this is a dup either.
I see it all the time in linux installed build 2000111421 and never saw it before.
I see it for almost every page that starts loading.
The numbers sometimes vary, even during loading, 0005 - 0003 - 0005 again etc.

In addition: Contrary to 59776 (which seems to be a bug where networking has
stopped working all together) - networking works just fine. All pages load - it
goes wherever i point it, but almost all pages show this oddity in statusbar.

I have also seen the other bug in linux, where mozilla networking bits stop
working and that error prints to console. But it never printed to statusbar.

Yet a differenfe is that the error message output is different in these two bugs.
One reads "Error loading URL" and this one reads "An unknown error  has occured".

Reopening, OS: All.
Status: RESOLVED → UNCONFIRMED
OS: Windows 98 → All
Resolution: DUPLICATE → ---
And confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 60202 has been marked as a duplicate of this bug. ***
it may still be warren though.. Some network related changes were made to
nsAsyncStreamListener.cpp
Adding to CC just in case.. Please remove CC if i'm guessing wrong here.

a fine sample URL going through all the agoany of this bug is
http://www.telehuset.no/snPublish.asp?NodeKey=01

During load it will show a plethora of "unknown error" numbers - in the middle
of it all a "Page finished loading" even displays, before it goes "unknown
error" again.
when page is loaded, mousing over a link will "refresh" the statusbar, and
displaying "Document: Done" time instead.
gagan, does this belong to networking?

occurs on mac, linux and winnt, 2000.11.15.08 *trunk* bits.
Assignee: asa → gagan
Component: Browser-General → Networking
Keywords: regression
QA Contact: doronr → tever
Hardware: PC → All
no. law can help you more on this.
Assignee: gagan → sairuh
er, i don't know why this was assigned to me. i assume this should go to
bill...? :)
Assignee: sairuh → law
QA Contact: tever → claudius
*** Bug 60278 has been marked as a duplicate of this bug. ***
Reporter of 60278 says he started seeing this bug on the 13th.
But bug 59776 is still something entirely different, i believe.
I've been seeing that one for weeks, on and off, and even commented about it in
bug 56366 on Nov. 9th.
I just DLed a build from 11-13-2000, loaded Yahoo again (the same site as my two 
other shots) and captured the screen, with the error visible. The build number 
is in the Title bar, as usual. the shot for build 200111321 is here:
http://www.burntelectrons.com/moz-error/shot3.gif
The other two shots are in the same directory.

Since you (R.K.Aa) said you've seen it off and on for a while, I won't bother to 
go back further unless asked to. Also, sorry for filing a duplicate bug report. 
I tried searching for "unknown error" in Bugzilla, but didn't see these relevant 
ones. D'oh!
Grey: The error i referred to having seen before is the one this bug was
originally marked duplicate of. A message saying something like
"Error loading URL http://www.blah.com/: 804b0010"
at which point the browser won't go anywhere anymore.
That bug originated a good while before the 13th., even if it wasn't filed as a
separate bug before that date.

I don't know if this helps but I see errors 0003, 0004, 0005 and 0006 (not 
necessarily in that order!) as pages are loading. I don't think that I have seen 
any others but they flash past so rapidly, it is difficult to tell. Other than 
that, Mozilla seems to work ok.
When installing PSM with build 2000.11.15.08, the text "An unknown error has
occurred (804b0004)" will appear but everything installs just fine.
I decided to look harder at this after seeing Asa's comments about it on 
Mozillazine. I ran a screen recording program and picked apart the video. A 
little more digging shows that, at lest on my machine, the error message appears 
on the status bar IMMEDIATELY after telling Mozilla to go to an URL, whether by 
clicking on the personal toolbar, entering an URL and hitting enter, entering an 
URL and clicking the GO button, bookmark, Task Menu site list, before any data 
is received from the site.

My testbed has been Yahoo because of it reliably loading every time (from my 
neck of the net, it's always quick to load and quite predictable), but I've 
checked it on other sites too. I have a personal toolbar button for them, and I 
click it, and INSTANTLY upon lifting the mouse button when clicking the error 
message occurs, so it's not related to rendering the page at all. Same with the 
URL bar, etc. It also happens when using Viewer.exe, so it's not the UI (my 
first guess). My best guess (maybe worthless, maybe redundant) is networking.
I'm going to pass this back to Networking.  We (xpapps) might display this error
message in the status bar but that could only happen if the Networking code
detected this error and told us about it.  They are better able to determine
what is happening to generate this (and why).  If it is some misinterpretation
of some notification callback to our code, then we'll be glad to look into that.
 I'm just skeptical about that being the case, based on the discussion here.
Assignee: law → gagan
QA Contact: claudius → tever
Well if these error codes, that probably mean the good old 'connect: waiting for
reply' messages, are translated to real messages, I wouldn't really say this is
a regression. The "Document: Done" messages is useless anyway, as it is
displayed far too early.
I'm seeing tons of this with a debug build:

WARNING: chrome: failed to get base url for
chrome://necko/locale/necko.properties -- using wacky default, file
../../../../mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 513

I did some simple debugging and it looks like it's the cause.  It can't find
that resource for some reason.
The latest comment made by tinus_mozilla@blib.win.tue.nl got me thinking. Aside 
from having to try and read that name over a PA system, I thought the idea these 
'error' messages were there in place of Connect: messages and suchdid some 
more poking and playing. I think he's on to it. 804b0005 seems to be "Contacting 
host, waiting for reply"; I'm not sure what 07 would be; I think 06 is a 
"receiving image" or somesuch message, etc. I saw an 08 a few minutes ago, while 
doing some thing in reference to getting a page.

Now I see Chris Blizzard just added his two cents. Maybe there's a typo 
somewhere, Chris? I'd check but the last time I DLed the source was back before 
M13, so I think a few things have changed since then...
currently using build 2000111604 win98 mtrunk (i think mtrunk is redundant now).

an interesting update to error behavior - while loading a url, the status bar
sometimes rapidly flickers between "804b0005" and "804b0003", "804b0004", and so
on up to "804b0008".

PSM displays "804b0004" and installs correctly; java shows a flicker between
804b0003, 01, and 05 and fails to install correctly (i am filing a separate bug
for the install failure).

I'm poking around lxr trying to 'help'. I think there may be a correlation
between the fix for bug 49424 and the appearance of this one.

I'm going on the premise that this is a regression (seems reasonable).
xpcom.properties contains the error message ('An unknown error has occurred...'
as mentioned in Bug 60161) and is used in a #define in nsStringBundle.cpp. Then
its used as GLOBAL_PROPERTIES in code looking like: if (NS_FAILED(rv)) { rv =
getStringBundle(GLOBAL_PROPERTIES, nsnull, getter_AddRefs(bundle)); <etc.>...
The fix was in nsStringBundle.cpp and looked like if (NS_FAILED(ret)) { delete
bundle; <etc.>

The diff for the fix is at
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15593 and starts at
line 771.  The line where GLOBAL_PROPERTIES (which is xpcom.properties) is used
is 982.

The one thing that makes me doubt this lead is that the first bug opened on this
(apparently 59776) was opened on Nov 10, but the patch was not r='ed or marked
as checked in until Nov 13.

(Crossposted between 59776 and 60161, since both are still open.  Apologies)

*** Bug 60420 has been marked as a duplicate of this bug. ***
i think Utke is onto something. Again: 59776 is older - i've seen that for
weeks. It is not caused by the same that causes this bug, which rather seems to
be connected to refreshes of the progress meter/status-bar itself.
hrm, is this related to/dup of bug 54241?
The message does not appeart anymore in 2000111720 trunk win98
I have it on the 2000111720, win2000
Fixed for me in 2000111721 Linux.
Stephan, I still see this error with the same build as you are using. I'm using
Linux too.
I've been seeing this on Linux build 2000111708. It's very very annoying.

build: 2000111704

hmm.. the only errors i get is 804b000x where x is 5 and 4..
anyways, cc:ing myself.
I have the identical build (04) for Win32, and all errors are still present. 
Also, the last few nightlies seem to have problems loading images. Is this 
related, just me, or a different problem?
What can I say, the error messages are gone for me, I get human readable
messages now (Resolving host, sending request etc.). I tried with different
themes, they all work. Are you using a self-made build or the binary nightlies?
I use the binaries and with them it seems to be fixed.
Yes! This is fixed in the nightly (2000111808) for Win32.
wfm in latest build.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Seems to be fixed in 2000111806 Linux build for me, haven't checked the Plugin
download screen or news yet though (other places where I saw the problem)
Just downloaded the latest nightly, works for me now.
Im using nightly build 2000111906 and am still experiencing this bug (first had 
the problem since 11/15, im using Linux w/installer). Ive been using the 
nightlys for the past week and the problem hasnt been fixxed on any of them so 
far. Additionally, the problem also exists on my windows machine, running 
2000111820, again w/ installer
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Using today's build (2000111906) on linux... The problem exists using the "sea"
installer package, but not in the tar.gz package.

I'm currentely using 2000111908 trunk win98 (the zip file without talkback) : no
errors shown.
Ah.. I see...

install.js needs to register necko too...

cc'ing leaf... leaf, I recently added contents.rdf for necko content (comm.jar)
and locale, can you modify install.js?
*** Bug 60726 has been marked as a duplicate of this bug. ***
*** Bug 60762 has been marked as a duplicate of this bug. ***
This does not appear for me in build 2000112004 Win32 with talkback.
still occurs for me [2000.11.20.08 trunk: mac, linux, winnt], but slightly
differently now: i only see this error appear *while* the pages is loading. it's
no longer in the statusbar once the page is done loading.
Seeing this with Mac Mozilla installer build 2000111708, running Mac OS 9.0.4,
MRJ 2.2.3.

Silly me, I reported this as part of bug 47359.
with build 2000112104 mtrunk win98 installer version - bug is still there
with build 2000112104 mtrunk win98 win32.zip version - no bug!

however - after a page is finished loading, status bar relays "sending request
to <server_name>" instead of "document done"; after mousing over a link, the
status bar resets to normal.

Based on jag's input reassigning to the install folks... Need to register Necko
chrome apparently now.
Assignee: gagan → ssu
Status: REOPENED → NEW
Component: Networking → Installer: XPI Packages
*** Bug 60996 has been marked as a duplicate of this bug. ***
mostfreq keyword
Keywords: mostfreq
*** Bug 61084 has been marked as a duplicate of this bug. ***
I still see it. "An unknown error has occurred (804b0005)". But as soon as I
hover over a link it disappears. installer build 2000112304 and w98SE.
This should theoretically fix this problem.
accepting the bug
Status: NEW → ASSIGNED
adding sgehani to the CC: list.
Status: ASSIGNED → NEW
sr=mscott
still there in my latest nightly, browser only.
build 2000112804  OS is Win NT 4.001381

Patch from disttsc@bart.nl has finally been checked in to both mozilla and ns 
trees.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
build 2000113004 win32-installer mtrunk on win98:
no more "804b000x" errors appear at all.  the only problem is that upon
completion of page load, the status bar reads "sending request to <hostname>",
where <hostname> is the server being accessed.  mousing over any link or item
that changes status bar text then returns the status bar to normal ("document
done" as default).

seems like a simple defaultstatus issue, i'd think.


Something like that...

I've got a fix for that if someone's got a bug :-)
this is back to what it used to be. The server in 'Sending request to <server>'
is the server that was last used, not the one mozilla is loading the page from.

Also the message used to be stuck, only much more than it is now.
If you've got a fix, disttsc@bart.nl (can I call you "jag"? <g>), check bug
48722, bug 47579, and bug 47359 to see which one you can fix.  Perhaps one or
two of them dupes another, and this (closed) bug seems to block a couple, too.

This have been working for a loong time now, so verifying fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Component: Installer: XPI Packages → Installer
QA Contact: tever → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: