Closed
Bug 59243
Opened 24 years ago
Closed 24 years ago
Accessing to IFRAME content crashes Moz
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: federicosasso, Assigned: jst)
References
Details
(Keywords: crash)
Attachments
(6 files)
BuildID: 2000101014 (M18)
Accessing to IFRAME content crashes Moz.
More precisely, it works the first time, but the 2nd Mozilla crashes
Reproducible: Sometimes
Steps to Reproduce:
put an IFrame in your document
<iframe id="myIFrame" src="fill.htm"></iframe>
try both (example: reads document.title)
alert(window.frames.myIFrame.document.title);
alert(document.getElementById("myIFrame").contentDocument.title);
they both do work the first time they are called, but the 2nd Mozilla crashes :-
(
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
sorry for the mess, but the testcase needs the fill.htm file to fill the IFRAME.
I uploaded that too but it seems thay are not in the same directory, can
someone fix the problem?
thanks.
Federico
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
er, that should have been "fill.htm"
In any case, I do not see a crash with linux trunk build 2000110521.
Federico, could you try a recent nightly and see if you can reproduce the
problem? Try to do it with a Talkback-enabled build and submit the Talkback
incident ID with you comments if you crash so that this bug can be correlated
with the Talkback data....
Reporter | ||
Comment 6•24 years ago
|
||
hello Boris, I just tested the testcase :-) and it now crashed at the first
click.
for me is a big pain downloading a talkback build, but I just started.
Comment 7•24 years ago
|
||
WFM for me with win2k and trunk build 2000110420
Assignee | ||
Comment 8•24 years ago
|
||
This works fine on the netscape branch but on the trunk I see weird problems, I
don't even get the alert window to show up when I click on one of the links so
I'm a bit confused about what could be causing this. If I reload the page after
I've clicked on one of the links I crash somewhere in focus code... weird... I'm
guessing there's a modality problem in current trunk builds on linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 9•24 years ago
|
||
I don't know what to say, I tried sometimes the testcase with 2000110604 with
talkback.
sometimes it happens at first, sometimes after more clicks, but Mozilla still
crashes.
to be more precise, it just hangs up without responding to any avent,
the "Netscape Quality Feedback Agent" doesn't even appear and I have to kill
the process with task Manager.
I'm running MS Windows 2000 Professional 5.00.2195, can't remember if with some
service pack.
Federico
Comment 10•24 years ago
|
||
using Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 with win98.
Assignee | ||
Comment 11•24 years ago
|
||
Aha! So this is not really a crash, it's a lockup. This is probably due to the
bugs with modal windows not always showing up and locking up the system then,
there's a couple of bugs on that but I don't have em handy so I'll leave this
one open untill I find those bugs and check if this is possibly a dup, could
even be a dup of 58404...
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
To my testcase!
Using Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/20001126 on Win95 and Win98
I don't think oit have to do with bug 58404 because this bug is permanent and
not unregular but it seem to make a memory leak (because mozilla slow down).
It had also not realy to do with bug 52334 and 60960 but I don't now if they
depend on this bug.
The onload problem can have to do something with the Bug 57636.
OK! Let me know if you need more information.
Assignee | ||
Comment 14•24 years ago
|
||
Alexander, are you still able to reproduce this?
Comment 15•24 years ago
|
||
OK! Today I using:
Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/2000121404 (realy m18 not m0.6 ??)
OK, i get some new error's ... for them I must create a 2 new tescase (because
it is the think, that I can't change websites from other servers (secure
reasons)!). The first testcase is the blind blue frame inside and the second
will the new tester. I think the bug report to the JavaScript Console aren't
clear! (The first is a not filled error with the right line and the filename and
the second error is the uncought exception [access denied bla bla] but with no
source file and line number 0).
"document.getElementById('iframeId').contentDocument.body" is already undefined
and rise an Error on JavaScript Console (if it is undefined, why rise the error??)
ok ... so far ... the two new testcases follow in some minutes.
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
Comment 18•24 years ago
|
||
Last sentencres for that!
*fine* it work's well, if you have write it well!
Please use my old testcase to change some little Error message on the JavaScript
Console.
Because alert(document.getElementById('iframeId').contentDocument.body) must
raise also an access denied error like
document.getElementById('iframeId').contentDocument.documentElement
and not only the 0 Error!
And on body you get back undefined on documentElement not! I think it must the
same on both. But else it is fine.
The onload in the iframe does not fire ... but I don't know if hge/she/it can
fire that :-) !
ok, I will go to bug bug 52334 to lock there for changes an eventuall repair's
of the testcase!
*worksforme
Assignee | ||
Updated•24 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 19•24 years ago
|
||
Ok, now I'm confused, I don't know what's wrong here, all I know is that
whatever I do with the testcases in this bug I can not reproduce a crash,
marking WORKSFORME. If there's a problem with something going wrong in the
testcase then please open a *new* bug on that, only reopen this if mozilla
*crashes* when accessing the testcases...
Comment 20•24 years ago
|
||
marking verified using the 2000122904 nightly build on win2k. i can't reproduce
a crash with any of the testcases.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•