Closed Bug 8244 Opened 26 years ago Closed 26 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: 26 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.