Closed Bug 8244 Opened 25 years ago Closed 25 years ago

Beeps and Warnings loading images

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
All
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: mikepinkerton, Assigned: pnunn)

References

(
URL
)

Details

go to www.foxsports.com and you'll get lots of beeps and warning messages (in a
debug build). Things like:

Alert: Alert! did not find a converter or
decodernsDocumentBindInfo::OnStopBinding: Load of URL 'http://www.foxsports.com/
buttons/images/leftsideofnavboard.gif' failed.  Error code: 1

This has been happening (but hard to dupe) for about 6 months, so it's not
anything new.
Target Milestone: M8
per pam's request, marking M8.
Severity: normal → critical
Pam, this has started getting much much worse lately. I can't go to most pages w/
out getting these asserts and beeps and problems loading images.

Bumping up to critical because it makes this thing unusable as dogfood.
FWIW, I haven't been able to reproduce this yet on this morning's or yesterday
morning's Mac OS & Win32 builds.
eli, you'll only see it in debug builds since there is no console on mac in
optimized builds.
Err...specifically...it wouldn't be returning these errors to the Win32 console
on optimized builds?
these asserts might be compiled out for optimized. Pam?
Status: NEW → ASSIGNED
Target Milestone: M8 → M9
This may have been affected by recent code changes by
warren for necko. Pushing bug to m9 to give us time to test.
This is really a webshell bug.
-pn
i'm sorry, this had nothing to do with necko. it's beeing going on for months.
No.... I didn't mean the bug was _caused_ by necko, but I noticed
that warren had made changes to nsDocumentBindInfo:OnStopRequest() in the
last couple of days. And that may change the bug behaviour.

Why do you think this bug is in the image library and not the webshell document
code? Its looks like its having problems finding the image url, not decoding
the image.
-pn
Pink:
When you have a minute, would you drop by my cube?
I have the breaks set in my mac build. The stack
on this error msg break is:

nsDocumentBindInfo:OnStopBinding
bam_exit_routine
net_call_exit
NET_ProcessNet
NET_PollSockets

The error passed to nsDocumentBindInfo::OnStopBinding()
is passed from netlib.

-pn
I have some more information on this problem, which is more serious now that
it causes the GFX scroll bars to completely fail to load in mailnews.
*** Bug 9170 has been marked as a duplicate of this bug. ***
Adding everyone who was on 9170 to cc list.  This bug also happens on Linux
(without the beeping but with all of the warnings).  It's a very big deal for
Mac usage of mailnews since only the most diehard users, ie engineers and QA,
would probably use this left in its current state.

9170 which I have marked as a duplicate basically says that we get these beeps
and warning when loading the scrollbar images for mailnews trees.  They occur
when starting up, when clicking on a folder, and each time a new message loads
in the thread pane.
Hardware: Macintosh → All
Changing platform to ALL since this is occurring on more than just the Mac
platform.  To summarize: this is also occurring the release Mac and Linux builds
when using Messenger as Scott Putterman describes.
Notes to self: in if.cpp; look at IL_StreamCreated, brk at ic->state==abort.
Watch ic->state progress.
-pn
And of course this beeps like crazy in the address book window and select address
dialog.  Every click on the tree widget causes a series of beeps.  I noticed that
I can make it stop by resizing to force the scroll bar to appear once on the
tree.  Even if I resize back such that I do not need a scroll bar there are no
more alerts.
I think this has something to do with frames and how we interrupt a stream when
we unload the frame. I have a simpler url for this:
http://jazz/users/pnunn/publish/twoframes1.html

The images used are large. And a bunch of them is requested at different
widths, so the imglib cache version can't be used.

Sorry, only available inside the firewall.
I've wrapped the offending calls with #ifdef DEBUG_pnunn so that only she will
see it.

This way, the other mac and linux people who build debug won't go insane.

Index: cstream/cstream.c
===================================================================
RCS file: /cvsroot/mozilla/network/cstream/cstream.c,v
retrieving revision 1.2
diff -r1.2 cstream.c
246a247
> #ifdef DEBUG_pnunn
248a250
> #endif
Index: main/mkstream.c
===================================================================
RCS file: /cvsroot/mozilla/network/main/mkstream.c,v
retrieving revision 1.9
diff -r1.9 mkstream.c
245a246
> #if DEBUG_pnunn
247a249
> #endif
one more place:

Index: nsDocLoader.cpp
===================================================================
RCS file: /cvsroot/mozilla/webshell/src/nsDocLoader.cpp,v
retrieving revision 3.119
diff -r3.119 nsDocLoader.cpp
2004c2004
< #if DEBUG
---
> #ifdef DEBUG_pnunn
adding hangas to cc list.

paul, I checked in the fix, but I am still seeing it on the mac.  it must be
coming from somewhere else.

I'll look into it and apply the same #ifdef DEBUG_pnunn to it.
warren stomped on my changes to nsDocLoader.cpp, which is why it showed up again
on linux and mac.

I added the #ifdef DEBUG_pnunn back so only see sees it.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Anyone still seeing this problem on the Mac?
The only DEBUG_pnunn 's I see are in mozilla/network
which is dead now.

This was fixed in the necko landing as far as I can
see. I'm closing. Please reopen if you see this
problem again.

-pn
[pinged pinkerton by e-mail to request confirmation that he's no longer seeing it
on debug builds.]
Status: RESOLVED → VERIFIED
i guess it's ok, but it will only beep for pam, so.....
Pink:
The lines commented out were in network. not netwerk.
network is no longer in the codebase.
-pn
You need to log in before you can comment on or make changes to this bug.