(except one point that's only {compat} but I think you should care about it. Perhaps that's not the right component but it occurs using JS) Mozilla (checked with M7) works different to Nav4 and/or IE4 if you want to assign new sources to some frames/objects in a showed document: (I'm using all of this at http://start.at/inconstruction) If I'm assigning a new picture to an <img> called "lcarsimg" in a frame called "LCARS_top" (using 'window.top.LCARS_top.document.lcarsimg.src="xy.gif"'), Mozilla acts like IE4, not like Nav4 regarding the path where "xy.gif" is searched. It takes the path of the document in the frame "LCARS_top" as 'home' for relative URLs. Nav4 takes the path of the current document (with the JS codein it) as 'home' for relative URLs. That's OK but makes problems if JS programmers only make differences for IE and Netscape. The REAL problem is this one: If I'm assigning a new URL to a frame called "Nav" (using 'window.top.Nav.location="xy.html"') Mozilla acts completely different to IE4 AND Nav4 (they both act the same)! As Nav4 and IE4 take again the current document's path (that one with the JS code)as 'home' for relative URLs, Mozilla takes the one of the document currently shown in the frame which gets a new source. So it's NOT possible to control acting of relative URLs if you want it relative to the current document because you don't have to know where the currently showed document in this frame is located... As you want Mozilla to be compatible to "old" Browsers beside being compatible to HTML4 and other standards, I think you should care about us poor JS programmers who get irritated by all those different handlings.

wrong component

I can't load your page (http://www.unet.univie.ac.at/~a9805220/trek) in viewer at all, perhaps due to generated-FRAMESET issues. Can you attach a small test case here that demonstrates the bug?

Off the beta list until we can get a test case.

HTML DOM bugs are M11/P2 for Vidur.

OK, I'm working on a testcase but I've lost the internet connection from my personal computer. I hope I'll get back the connection this weekend - then I'll aqttach this testcase. I now found out that M9 loads the right frame when assigning it via JS (relative URL) but Mozilla crashes before, while or after loading the document. I hope the testcase will help - so just wait for the weekend...

OK, I've added the testcase. It seems strange but M9 finds the frame document - as I mentioned before but crashes - at least if you click a few times on "document 2" or "document 3" in the testcase. Be sure your ZIP-decompression writes the right subdirectories: "testdir" for "right1.html" and "right2.html" and "testdir2" for "right3.html". All the other files, "index.html", "left.html", "nsnow.gif" and "explorer.gif" should be placed in the directory hosting "testdir" and "testdir2". Normally, your ZIP program should create the subs anyway. If you check the testcase with Nav4, MSIE (4) and Mozilla, you should see the differences between the programs regarding relative URLs for the pictures. The frame document test runs the same for all of them but Mozilla still crashes (see above).

BTW - M9 Raptor viewer does not crash! (only the nsnow picture collapses if you have "changed" it before clicking on doc2 or doc3)

KaiRo -- I'm a little confused. You say it no longer crashes in M9 viewer. Could you please retest in a recent build of AppRunner (please tell us which one)? M9 is old and we try to use AppRunner for all our testing now. Moving to M12 pending clarification of status in AppRunner. Also, we need to separate out the issues here. A crash is one bug; incompatible JS behavior is a separate bug. Kairo--Any chance you could split this into two bug reports with a simplifed test case for each issue (the crash, and the incompatible JS)? Thanks for all your help!

OK, I think I'll leave this bug for the crash issue which I understand less and less, the {compat} issue now is bug #17857. For the [CRASH] issue, the testcase here is OK but can be simplified (only use the first line with 'document 2' and 'document 3'. It works very strange with build #1999102608 - sometimes it crashes after changing the document 2 times, sometimes it works for changing it 30 times, sometimes the nsnow picture collapses, sometimes this comes back again, sometimes it doesn't. I don't really know what's happening here...

Just checked with M11 if this confusing things are still happening - and HEY! they are! Sometimes crashing after changing document a few times, sometimes collapsing the nsnow picture to a 0x0(???)-picture with a border (from <a>)... What the hell is that???

Moving off M12 radar for the time being. One or more might get back once I get a chance to really look at them.

Here's where I'm at: the resolution of relative URLs to the source of the calling context happens correctly for frames. I have a fix (see bug 17857) for the URL resolution for images. The crash that's occurring for the test case of this page is image related (see the stack below). My understanding is that we're destroying an animated GIF, but the callback for it is still staying around. As a result, we try to reference the corresponding ImageGroup, but it's been destroyed. The reference counting (or lack thereof) in this whole process is bogus, but the immediate fix is to find out why the callback isn't being cleared (or if it is correct for it to still exist, why its still maintaining a reference to a deleted ImageGroup). Passing this one along to Pam, since it's very image library related. Pam, if you have any questions, please send mail or call. ReconnectHack(void * 0x01f3f440, nsIStreamListener * 0x01d00ab0) line 162 ImageNetContextImpl::GetURL(ilIURL * 0x01d06ea0, NET_ReloadMethod NET_CACHE_ONLY_RELOAD, ilINetReader * 0x01d00d50) line 551 + 26 bytes il_image_complete(il_container_struct * 0x01f48ac0) line 1548 ImgDCallbk::ImgDCBHaveImageAll(ImgDCallbk * const 0x01f488c0) line 185 + 12 bytes process_buffered_gif_input_data(gif_struct * 0x01d0eb50) line 694 gif_delay_time_callback(void * 0x01f48ac0) line 713 + 9 bytes timer_callback(nsITimer * 0x01d00ee0, void * 0x01d00ea0) line 71 + 12 bytes TimerImpl::Fire(unsigned long 19397071) line 312 + 17 bytes TimerImpl::ProcessTimeouts(unsigned long 19397071) line 191 FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 28560, unsigned long 19397071) line 105 + 9 bytes USER32! 77e7128c() main(int 1, char * * 0x00be1a10) line 137 + 11 bytes mainCRTStartup() line 338 + 17 bytes

My best idea now is the timer is 'reanimating' a dead request. The img container lives beyond its frame's life, because it is accessed by the other frame. When one frame is unloaded, the ic still lives for it is needed by the other frame. Unfortunately, the timer attached to the ic confuses its origins. This is a guess. I'm currently updating my tree to pick up the recent necko and frame changes. These changes may affect this bug. -pn

This is a dupe. I want to keep the test though. Its very helpful. *** This bug has been marked as a duplicate of 12722 ***

The crash issue is a duplicate of 12722, right. There's an animated gif (nsnow.gif) in both frames, same size everywhere. The same thing as reported in 12722.