I get an intermittent code clicking around in http://www.wb.com, particularly when I get to http://www.wbmovies.com/main.html by clicking on the middle right image (today it says "Practical Magic".) Then click on "Feature Presentation", this opens a second window and I click around. Eventually I get the crash in image group. ======================================================================= stack: ReconnectHack(void * 0x0134aa40, nsIStreamListener * 0x013fca70) line 125 + 9 bytes ImageNetContextImpl::GetURL(ilIURL * 0x013fcca0, NET_ReloadMethod NET_DONT_RELOAD, ilINetReader * 0x013fca40) line 463 + 30 bytes il_image_complete(il_container_struct * 0x0135c1b0) line 1338 process_buffered_gif_input_data(gif_struct * 0x012a3120) line 637 + 9 bytes gif_delay_time_callback(void * 0x012a3120) line 657 + 9 bytes timer_callback(nsITimer * 0x014a2b60, void * 0x014a2bb0) line 70 + 12 bytes TimerImpl::Fire(unsigned long 16282523) line 308 + 17 bytes TimerImpl::ProcessTimeouts(unsigned long 16282523) line 187 FireTimeout(void * 0x00000000, unsigned int 275, unsigned int 26756, unsigned long 16282523) line 101 + 9 bytes USER32! 77e7128c() main(int 2, char * * 0x011f6570) line 96 mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b304()

You might just want to give it to V. Insensitive bastard that he is... :-)

hmmm. seems like the best thing is to just keep passing the buck...

Nice try Sparky, but Vidur wrote the code and you're the gfx owner...

i've done a good bit of navigation through the site and can't duplicate the problem today. steve, does it still explode for you today?

Hmm...I can reproducibly bring down the Viewer app (1.28.99 optimized) in this web site by clicking on "Classic Sites" (from www.wbmovies.com/main.html), "Contact" and letting the opening animation go through about 5 cycles. No stack crawl; is this a different bug? Assuming probably, but wanted to be sure before breaking it off. Thanks!

get a stack trace if you want to know if it's a different bug or not...

Hi, Mike --- I'd love to have provided a stack crawl, but QA does not have debug builds available to do so. (And the bug isn't taking place on Mac OS, so I can't just do it from Macsbug.) Would you be open to sending a debug build by E-mail, or just reproducing the bug? (two mouse clicks and a URL) Thanks!

Setting all current Open/Normal to M4.

I can't see the bug either.(NT, tip build.) Eli, could you retest with current build? Thanks. -pn

On 4.20.99 Mac OS and Win32 builds (worked on Linux), I immediately crash upon going to www.wbmovies.com/main.html, before the page even begins loading. But, this looks like a different crash: PowerPC unmapped memory exception at 0A7AC9EC nsPluginInstanceOwner::GetPluginPort()+00024 Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0ABC7968 02FF9AC0 PPC 0ABC6278 main+009FC 02FF9830 PPC 0B9DD760 nsAppShellService::Run()+00018 02FF97F0 PPC 0AEFF33C nsAppShell::Run()+00038 02FF9770 PPC 0AEFFD44 nsMacMessagePump::DoMessagePump()+0003C 02FF9720 PPC 0AEFFEEC nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00084 02FF96D0 PPC 0AF00080 nsMacMessagePump::DoUpdate(EventRecord&)+0004C 02FF9680 PPC 0AF00808 nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort *)+00044 02FF9630 PPC 0AEFAC98 nsMacMessageSink::DispatchOSEvent(EventRecord&, GrafPort*)+00038 02FF95F0 PPC 0AEF6B7C nsMacWindow::HandleOSEvent(EventRecord&)+00020 02FF9590 PPC 0AEF6EB0 nsMacEventHandler::HandleOSEvent(EventRecord&)+0006C 02FF9550 PPC 0AEF7958 nsMacEventHandler::HandleUpdateEvent(EventRecord&)+ 00018 02FF9510 PPC 0AEE1484 nsWindow::HandleUpdateEvent()+0016C 02FF9490 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF93F0 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF9350 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF92B0 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF9210 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF9170 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF90D0 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF9030 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF8F90 PPC 0AEE1688 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+00190 02FF8EF0 PPC 0AEE1584 nsWindow::UpdateWidget(nsRect&, nsIRenderingContext* )+0008C 02FF8E50 PPC 0AEE1B90 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00018 02FF8E10 PPC 0AEE1ABC nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus& )+00090 02FF8DC0 PPC 0A6E2B48 HandleEvent(nsGUIEvent*)+00058 02FF8D70 PPC 0A6E0178 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus&)+002D8 02FF8C30 PPC 0A6DDBFC nsViewManager::Refresh(nsIView*, nsIRenderingContext*, const nsR ect*, unsigned int)+0019C 02FF8B80 PPC 0A6DE2FC nsViewManager::RenderViews(nsIView*, nsIRenderingContext&, const nsRect&, int&)+00560 02FF88F0 PPC 0A6DF7E0 nsViewManager::RenderView(nsIView*, nsIRenderingContext&, const nsRect&, nsRect&, int&)+000BC 02FF8890 PPC 0A6E3448 nsView::Paint(nsIRenderingContext&, const nsRect&, unsigned int, int&)+0012C 02FF8620 PPC 0A720734 PresShell::Paint(nsIView*, nsIRenderingContext&, const nsRect&)+ 000AC 02FF85C0 PPC 0A7307C0 nsHTMLContainerFrame::Paint(nsIPresContext&, nsIRenderingContext &, const nsRect&, nsFramePaintLayer)+00150 02FF8540 PPC 0A709260 nsContainerFrame::PaintChildren(nsIPresContext&, nsIRenderingCon text&, const nsRect&, nsFramePaintLayer)+000C8 02FF84D0 PPC 0A709498 nsContainerFrame::PaintChild(nsIPresContext&, nsIRenderingContex t&, const nsRect&, nsIFrame*, nsFramePaintLayer)+0015C 02FF8440 PPC 0A8B5BF8 nsBlockFrame::Paint(nsIPresContext&, nsIRenderingContext&, const nsRect&, nsFramePaintLayer)+001A8 02FF83B0 PPC 0A8B5E94 nsBlockFrame::PaintChildren(nsIPresContext&, nsIRenderingContext &, const nsRect&, nsFramePaintLayer)+00090 02FF8340 PPC 0A709498 nsContainerFrame::PaintChild(nsIPresContext&, nsIRenderingContex t&, const nsRect&, nsIFrame*, nsFramePaintLayer)+0015C 02FF82B0 PPC 0A8B5BF8 nsBlockFrame::Paint(nsIPresContext&, nsIRenderingContext&, const nsRect&, nsFramePaintLayer)+001A8 02FF8220 PPC 0A8B5E94 nsBlockFrame::PaintChildren(nsIPresContext&, nsIRenderingContext &, const nsRect&, nsFramePaintLayer)+00090 02FF81B0 PPC 0A709498 nsContainerFrame::PaintChild(nsIPresContext&, nsIRenderingContex t&, const nsRect&, nsIFrame*, nsFramePaintLayer)+0015C 02FF8120 PPC 0A7A9A24 nsObjectFrame::Paint(nsIPresContext&, nsIRenderingContext&, cons t nsRect&, nsFramePaintLayer)+0001C 02FF80E0 PPC 0A7AC6C8 nsPluginInstanceOwner::Paint(const nsRect&)+00024

eli, Looks fine to me on NT. Am I missing something? -pn

Hi, Pam --- Using today's Win32 build, I'm reproducibly still crashing upon loading the www.wbmovies.com/main.html page. (You're welcome to drop by and see it if you're curious.) Unfortunately, this page is consistently triggering bug #5483 on Mac OS, so I can't investigate further there. I'd like to hold a few days until Pinkerton fixes that bug, and then look into this one further. Hope that helps. See ya.

I'm changing the URL location to the crash. -pn

The bug that was holding investigation was marked a duplicate of a fixed bug. I'm also reproducingly seeing this crash, Mac OS-only, on http:// www.jcinteractive.com/test/pnglive_ps5.html, the PNG test suite. (It'll crash as soon as you scroll.) Please let me know if you'd like me to decompose this page and isolate the crash, or if it's easier for you to do in the code. Thanks!

The wbmovie page is driving me crazy. From your post, it sounds like this bug is due to an object tag. Is this correct? Do we have a nice simple object tag test page? Why is the pngtest page and this page similar? -pn

There is a timer bug on the wbmovies page. Could you make a new bug for the object tag bug (ie the png test page)? It is probably a duplicate of bug#5829. -pn

Here's the call stack I get for the timing problem. A very different stack from the one previously listed. Using apprunner: GlobalWindowImpl::RunTimeout(nsTimeoutImpl * 0x03d211a0) line 1206 + 21 bytes nsGlobalWindow_RunTimeout(nsITimer * 0x03d311a0, void * 0x03d211a0) line 1088 TimerImpl::Fire(unsigned long 881458940) line 308 + 17 bytes TimerImpl::ProcessTimeouts(unsigned long 881458940) line 187 FireTimeout(void * 0x00000000, unsigned int 275, unsigned int 19250, unsigned long 881458940) line 101 + 9 bytes USER32! 77e71373() nsAppShellService::Run(nsAppShellService * const 0x00ef2bb0) line 209 main(int 1, char * * 0x00ec1980) line 462 + 12 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b304() Vidur, I'm passing this one to you since its happening in the dom. Reassign as needed. -pnunn

Took me a while to see the bug. It occurs only when you wait about 30 seconds - at that point a timer fires to close the larger of the two popup windows. The timer callback closes the window and we don't deal gracefully with a timer closing its own window. I have a fix waiting in my tree. Will check it in when the tree goes green. [Note, there is another bug associated with the items in the left navigation bar (the ones that say "OPENING soon", "NEW releases",...). The images corresponding to those items have NAME attributes that are "1", "2",.... They are accessed off the document using their names as if they were ordinal values (i.e. document[1], document[2]). This is valid and would work in 4.x, and required a fix (also soon to be checked in) to our generated JS code. Note that the expectation is that the links should hilight as you mouse over them. However, there is a bug in the page itself that prevents this from working in Gecko or 4.x. The name of the 5th image is "7", though the JS code attempts to access it as document[5]. Fixing this (see the attached test case), makes the hilighting work correctly. What's curious is that it works unchanged in IE4.0.]

Fix checked in on 6/11/1999 as discussed above.

I can't reproduce this problem anymore, although the web site is completely broken right now [can't click on any links, which use javascript; will check vidur's test case to see if it's the same thing].

[broke the "can't click on links" stuff into bug #8259.] I'm not sure what to do with this bug --- as far as I can tell it's fixed, but with the site untraversable, I don't feel comfortable formally marking the bug verified. Thus, I'm weaseling out, and marking it as dependent upon 8259, and will verify this bug when 8259 [or whatever JS bug I couldn't find, of which it's probably one of many duplicates] is fixed.

I'm frankly not sure what to do with this bug. I'm sure this bug is fixed, but www.wbmovies.com keeps crashing our browser in new ways that I see every time I check out this bug. (27284, most recently) Added chrisd & petersen to CC: list in order to ask them whether they might have a list of Nasty Sites that wbmovies.com could be added to for ad-hoc testing. (Otherwise, I can just keep verifying this bug every 2-3 months and come up with new bugs. ;)

This is more Chris Petersen's area - I'll let him followup

QA Assigning to chris petersen. Thanks!

With the Feb 18th build (2000021808), I can't reproduce the crash that is indicated.Marking verified fixed.