9906 - [CRASH] {compat} assigning new sources to frames/objects via JS using relative URLs

Status: VERIFIED DUPLICATE of bug 12722

(Core :: DOM: Core & HTML, defect, P2)

Description

[Robert Kaiser]

(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.

Comment 1

[cbegle]

wrong component

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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?

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

HTML DOM bugs are M11/P2 for Vidur.

Comment 5

[Robert Kaiser]

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...

Comment 6

[Robert Kaiser]

Attachment: testcase for bug #9906 - by KaiRo - 1999-10-06

Comment 7

[Robert Kaiser]

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).

Comment 8

[Robert Kaiser]

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

Comment 9

[ekrock's old account (dead)]

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!

Comment 10

[Robert Kaiser]

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...

Comment 11

[Robert Kaiser]

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???

Comment 12

[vidur (gone)]

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

Comment 13

[vidur (gone)]

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

Comment 14

[pnunn]

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

Comment 15

[pnunn]

This is a dupe. I want to keep the test though.
Its very helpful.

*** This bug has been marked as a duplicate of 12722 ***

Comment 16

[Robert Kaiser]

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.