Closed
Bug 91747
Opened 23 years ago
Closed 23 years ago
iframe larger than screen causes Mozilla to stop painting
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla0.9.8
People
(Reporter: helmut.leininger, Assigned: kmcclusk)
References
()
Details
(Keywords: testcase, top100, Whiteboard: [Hixie-P3])
Attachments
(4 files)
Screenshot after tabbing back and forth.
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010720
BuildID: 2001072003
During loading of the page http://www.keyzone.at Mozilla seems to freeze. It
seems to have something to do with JavaScripts. IE 6.0 anf Netscape 4.76 perform
well.
Reproducible: Always
Steps to Reproduce:
1.Load the URL
2.
3.
Actual Results: Mozilla freezes or loops.
Expected Results: Should finish to load homepage and exeute Javascript.
|
||
Comment 1•23 years ago
|
||
wfm with win2k build 20010720..
|
||
Comment 2•23 years ago
|
||
Here is the HTML at the site, with a <base> and some debugging alerts added:
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.0 Transitional//EN'>
<html>
<base href="http://www.keyzone.at">
<head><title>keyzone</title>
<script language="javascript" type="text/javascript">
<!--
var storyLoc;
var first=true;
var themeID=1;
var subThemeID=1;
var bType="/subBanners/allgemein.html";
if(self!=top) {top.location.href=self.location.href;}
//-->
</script>
<script language="javascript" src="/js/dhtmlCheck.js" type="text/javascript">
</script>
<script language="javascript1.2" type="text/javascript">
<!--
if(window.location.search.indexOf("story=")!=-1)
{ alert('A');
wls=window.location.search;
loc0="/banners/bannerGeneral.html";
loc1="/NASApp/portal/nav/topNav_start.jsp";
loc2="/singleStory.html"+wls;
loc3="/nav/bottomNav_search.html";
storyLoc=wls.substring(wls.indexOf("story=")+6,wls.length);
}
else if(window.location.search.indexOf("channel=")!=-1)
{alert('B');
x=window.location.search.indexOf("channel=");
channelNr=window.location.search.substring(x+8,x+9);
loc0="/banners/banner00"+channelNr+".html"
loc1="/NASApp/portal/nav/topNav_chan"+channelNr+".jsp";
loc2="/NASApp/portal/channel/index"+channelNr+".jsp";
loc3="/nav/bottomNav_chan"+channelNr+".html";
}
else if(window.location.search.indexOf("ec")!=-1)
{alert('C');
loc0="/banners/bannerGeneral.html";
loc1="/NASApp/portal/nav/topNav_start.jsp";
loc2="/ec_start.html";
loc3="/nav/bottomNav_start.html";
}
else if(window.location.search.indexOf("registry=yes")!=-1)
{alert('D');
loc0="/banners/bannerGeneral.html";
loc1="/NASApp/portal/nav/topNav_start.jsp";
loc2="/reg_overview.html";
loc3="/nav/bottomNav_start.html";
}
else if(window.location.search.indexOf("newszone=yes")!=-1)
{alert('E');
loc0="/banners/bannerGeneral.html";
loc1="/NASApp/portal/nav/topNav_start.jsp";
loc2="/NASApp/portal/portal_start.jsp?headers=/newszone_index.html";
loc3="/nav/bottomNav_start.html";
}
else
{alert('F');
loc0="/banners/bannerGeneral.html";
loc1="/NASApp/portal/nav/topNav_start.jsp";
loc2="/NASApp/portal/portal_start.jsp";
loc3="/nav/bottomNav_start.html";
}
var FORUM1=null;var FORUM2=null;var FORUM3=null;var FORUM4=null;var
FORUM5=null;var FORUM6=null;
function discussion(n)
{
FORUM=eval("FORUM"+n);
if (FORUM && !FORUM.closed) {FORUM.focus();}
else
{FORUM=window.open("/NASApp/portal/home?templ=cassiopeiaFOREN&nh="+(n-1),"Forum"
,"scrollbars=yes,toolbar=no,location=no,directories=no,status=yes,menubar=no,res
izable=no,width=815,height=500");}
}
var BOARD1=null;var BOARD2=null;var BOARD3=null;var BOARD4=null;var
BOARD5=null;var BOARD6=null;
function blackboard(n)
{
BOARD=eval("BOARD"+n);
if (BOARD && !BOARD.closed) {BOARD.focus();}
else
{BOARD=window.open("/NASApp/portal/home?templ=cassiopeiaBOARD&nh="+(n-1),"Blackb
oard","scrollbars=yes,toolbar=no,location=no,directories=no,status=yes,menubar=n
o,resizable=no,width=815,height=500");}
}
document.write("<frameset rows='64,40%,260,60%,12' frameborder=0 border=0>")
document.write("<frame name='bannerFrame' sr"+"c='"+loc0+"'
marginwidth=0 marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='topnav' sr"+"c='"+loc1+"' marginwidth=0
marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='mitte' sr"+"c='"+loc2+"' marginwidth=0
marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='bottomnav' sr"+"c='"+loc3+"' marginwidth=0
marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='infoFrame'
sr"+"c='/NASApp/portal/info1.jsp' marginwidth=0 marginheight=0 scrolling=no
frameborder=0>")
document.write("</frameset>")
document.write("</html>")
//-->
</script>
</head>
<noscript>
<body bgcolor="#FFFFFF" leftmargin=0 marginwidth=0
topmargin=0 marginheight=0 scroll=no>
<map name="noscriptimg">
<area shape=rect coords="18,274,53,297" href="http://www.uta.at"
target="_blank">
</map>
<table border=0 cellspacing=0 cellpadding=0 width="100%" height="100%">
<tr><td width="100%" height="100%" align=center valign=middle>
<img src="/img/keyzone_noscript.gif" border=0 usemap="#noscriptimg">
</td></tr>
</table>
</body>
</noscript>
</html>
|
|
||
Comment 3•23 years ago
|
||
And here is the "dhtmlCheck.js" file, included in the HTML above:
var MOZ=(document.getElementById && (navigator.userAgent.indexOf("Gecko")!=-1 ||
navigator.userAgent.indexOf("Netscape6")!=-1))? true : false;
var NS4=(navigator.userAgent.indexOf("4")!=-1 &&
navigator.appName.indexOf("Netscape")!=-1 && !MOZ &&
navigator.userAgent.indexOf("Opera")==-1)? true : false;
var NS=(NS4 || MOZ)? true : false;
var IE=(document.all && navigator.userAgent.indexOf("Opera")==-1)? true : false;
var IE4=(IE && !document.getElementById)? true : false;
var IE5=(IE && document.getElementById)? true : false;
var DOM=(IE5 || MOZ)? true : false;
var MAC=(navigator.userAgent.indexOf('Mac')!=-1)? true : false;
var WIN=(navigator.userAgent.indexOf('Win')!=-1)? true : false;
if(!IE && !NS) {window.location.replace("/redirect/update.html");}
|
|
||
Comment 4•23 years ago
|
||
When I go to the site http://www.keyzone.at in Mozilla trunk 20010713xx WinNT,
I have no trouble loading it. Perhaps this is Win98-specific?
When I save the debugged version of the HTML above locally, I find that
Mozilla falls into the alert('F') case above. This does the following:
loc0="/banners/bannerGeneral.html";
loc1="/NASApp/portal/nav/topNav_start.jsp";
loc2="/NASApp/portal/portal_start.jsp";
loc3="/nav/bottomNav_start.html";
And then we document.write a frameset using these parameters:
document.write("<frameset rows='64,40%,260,60%,12' frameborder=0 border=0>")
document.write("<frame name='bannerFrame' sr"+"c='"+loc0+"'
marginwidth=0 marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='topnav' sr"+"c='"+loc1+"' marginwidth=0
marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='mitte' sr"+"c='"+loc2+"' marginwidth=0
marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='bottomnav' sr"+"c='"+loc3+"' marginwidth=0
marginheight=0 scrolling=no frameborder=0>")
document.write("<frame name='infoFrame' sr"+"c='/NASApp/portal/info1.jsp'
marginwidth=0 marginheight=0 scrolling=no frameborder=0>")
document.write("</frameset>")
document.write("</html>") <---- OOPS!!! THIS DOESN'T LOOK RIGHT !!!
|
|
||
Comment 5•23 years ago
|
||
I see no JS Engine problems here. The browser-sniffing code in the
"dhtmlCheck.js" file seems to be fine. The condition there,
if(!IE && !NS), evaluates to false in Mozilla, so the file doesn't
do the redirect to "/redirect/update.html"; it does nothing in Moz.
Am seeing no errors in the JavaScript Console at this site, either.
What worries me is the document.write(</html>"), because there is already a
static </html> at the end of the file. Perhaps this is causing problems?
The only other potential problem I can see is this line in the
top script block of the HTML:
if(self!=top) {top.location.href=self.location.href;}
Since this is not JS Engine, let me reassign to Browser-General
for further triage. Can anyone else reproduce this hang?
Is it Win98-specific?
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
Keywords: hang
QA Contact: pschwartau → doronr
|
||
Comment 6•23 years ago
|
||
I can confirm this on WinMe build 2001072103 from the 0.9.2 branch. It's really
ugly. Seems to break painting. I was able to click links in another window, but
I couldn't see anything. Seems like everything works normally, it just stops
painting at some point during page load, and it doesn't start again until you
kill Mozilla and restart it.
Setting severity to critical.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 7•23 years ago
|
||
->DOM for investigation.
Assignee: asa → jst
Component: Browser-General → DOM Level 0
QA Contact: doronr → desale
|
|
||
Comment 8•23 years ago
|
||
OK, I'm seeing this now with all these builds on WinNT, Linux.
Changing OS : Win --> All.
20010713xx WinNT trunk
20010721xx WinNT trunk
20010721xx WinNT 092 branch
20010713xx Linux trunk
If I load the site http://www.keyzone.at, the images don't finish
loading. I see "containers" for the images, but not the images themselves.
HOWEVER - if I Alt+Tab to another application and then back to Mozilla,
to force Mozilla to repaint, I DO now see all the images. WinNT and Linux.
OS: Windows 98 → All
|
|
||
Comment 9•23 years ago
|
||
Reassigning to Layout component. Is this a dupe of a known bug
with loading images?
Or is it possibly due to the extra "</html>" the site contains (see above).
To repeat, they do a document.write("</html>") right after they document.write
their frameset, PLUS they have a static </html> at the end of the file -
|
|
||
Comment 10•23 years ago
|
||
Re-summarizing and reassigning to Layout -
Assignee: jst → karnaze
Component: DOM Level 0 → Layout
Keywords: hang
QA Contact: desale → petersen
Summary: Mozilla freezes. Javascript ? → Site does not finish rendering. Must Alt+Tab back and forth.
|
||
Comment 11•23 years ago
|
||
I think that </html> needs to be escaped and that this is Evang fodder.
Component: Layout → Evangelism
|
|
||
Comment 12•23 years ago
|
||
ALT+TABbing doesn't fix this for me. No matter what I do Mozilla is unusable. I
can open new windows with CTRL+N, but they show up empty, so Mozilla is still
responding, it just stops painting.
|
|
||
Comment 13•23 years ago
|
||
I just downloaded the latest trunk build. Same behaviour here. I'll upload a
screenshot of what happens.
|
|
||
Comment 14•23 years ago
|
||
|
|
||
Comment 15•23 years ago
|
||
I tested this with 20010719 on a win98 machine. Same behaviour - Mozilla stops
painting. Updating summary and moving back to layout. Changing OS back to win98
(though it also happens on WinMe) - the workaround mentioned by Phil Schwartau
for NT and Linux does not apply to win98/Me.
Component: Evangelism → Layout
OS: All → Windows 98
Summary: Site does not finish rendering. Must Alt+Tab back and forth. → Mozilla stops painting after visiting this url.
|
||
Comment 16•23 years ago
|
||
|
|
||
Comment 17•23 years ago
|
||
This is the testcase:
<iframe src="http://www.mozilla.org"
style="position:absolute;width:500px;height:2000px;left:0px;top:0px">
</iframe>
Change 2000px to 200px and the problem disappears.
Keywords: testcase
OS: Windows 98 → All
|
|
||
Comment 18•23 years ago
|
||
|
|
||
Comment 19•23 years ago
|
||
Please ignore the first testcase, it was a bit too simple. In testcase #2 I am
now using an IFRAME height of 10000px (same as in orig URL) and lowering this
value makes the bug go away.
|
|
||
Comment 20•23 years ago
|
||
Yes! Testcase #2 exposes the bug. With this I was able to make Moz work again
after about a minute. Seems like the rendering engine goes into a loop without
affecting anything else. Probably not as visible on faster machines, mine is a
500Mhz PIII.
|
||
Updated•23 years ago
|
Whiteboard: [Hixie-P3]
|
|
||
Comment 21•23 years ago
|
||
*** Bug 90341 has been marked as a duplicate of this bug. ***
|
Assignee | |
Comment 23•23 years ago
|
||
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
|
||
Updated•23 years ago
|
Summary: Mozilla stops painting after visiting this url. → Mozilla stops painting after visiting this url.[form]
|
|
||
Updated•23 years ago
|
Summary: Mozilla stops painting after visiting this url.[form] → Mozilla stops painting after visiting this url.[form sub]
|
||
Comment 24•23 years ago
|
||
*** Bug 104111 has been marked as a duplicate of this bug. ***
|
|
||
Comment 25•23 years ago
|
||
*** Bug 110045 has been marked as a duplicate of this bug. ***
|
|
||
Comment 26•23 years ago
|
||
i don't see the bug anymore. (W2000 on a PIII/750Mhz)
chris:
can you verify please?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
|
|
||
Comment 27•23 years ago
|
||
Reopening. http://www.keyzone.at seems to work fine, but Testcase #2 still makes
moz freeze. Also seeing this on http://www.sueddeutsche.de from one of the
dupes. I guess keyzone changed their html?
This is 2001111503 on win98, amd 1,4Ghz.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
|
|
||
Comment 28•23 years ago
|
||
can someone put a test case together please?
|
|
||
Comment 29•23 years ago
|
||
This is a simple testcase, an html document containing an iframe with height
set to 10 000.
|
|
||
Comment 30•23 years ago
|
||
Damn!
I run mozilla trunk build 2001111303 and 2001111603 and is finishing the job
within <1 sec when loading the latest testcase. (win2000/750MHz/T1)
Lasse:
How fast is your connection? What OS? Seems to me that this is a specific issue...
Are you using a special charset? Try playing with them... Who knows... :-)
(thx for the testcase)
|
|
||
Comment 31•23 years ago
|
||
I have 1Mb ADSL, win98. Connection is not the issue, same result when trying to
view the testcase from local drive. I'll play around with my settings a bit.
Alexandru: as far as I know this has never been confirmed on win2K. Can you try
with a win9X machine?
|
|
||
Comment 32•23 years ago
|
||
This is really strange. I tried to change the height of the iframe. The problem
kicks in at 865 pixels. A height of 864 works fine, a height of 865 makes it
behave strangely. I am able to close the window though, I couldn't do that with
my old cpu (500).
|
|
||
Comment 33•23 years ago
|
||
I checked my screen resolution. It is set to 1152x864. It seems that the problem
is when the iframe is bigger than the screen. Changed the res to verify. When
set to 1024x768 the problem starts when the iframe is higher than 768.
|
|
||
Comment 34•23 years ago
|
||
********************************
* WINDOWS 9x / WINDOWS ME *
********************************
confirming... godamit... why only on 9x... i don't want to debug now on 9x ;-)
Linux works...
MacOSX preview works...
so I think is win95, win98, winME only
|
||
Comment 35•23 years ago
|
||
I'd like to suggest adding the keyword mozilla1.0. Reason: when 1.0 comes out
and all the reporters are testing it on their own (probably Win98/ME) systems,
many of them will have a look at http://www.sueddeutsche.de because this is
likely to be one of their favourite pages anyway - the resulting reports on
mozilla would be quite embarrasing if this bug were still present in 1.0.
Not to mention the comments which Sueddeutsche Zeitung itself will give... ;-)
|
|
||
Comment 36•23 years ago
|
||
adding top100 [is more suitable]
(kw reason: top100 german)
Keywords: top100
Summary: Mozilla stops painting after visiting this url.[form sub] → Mozilla stops painting after visiting this url.
|
|
||
Comment 37•23 years ago
|
||
Updating summary to reflect the cause of the bug, and changing URL to one that
actually exposes the bug.
Summary: Mozilla stops painting after visiting this url. → iframe larger than screen causes Mozilla to stop painting
|
|
Assignee | |
Comment 39•23 years ago
|
||
Note: This bug should be fixed when both bug 95952 and bug 114082 are fixed
Target Milestone: --- → mozilla0.9.8
|
|
Assignee | |
Updated•23 years ago
|
|
|
||
Comment 40•23 years ago
|
||
same issue as in bug 91747?
|
|
||
Comment 41•23 years ago
|
||
ooops.. same issue as in bug 64049 i mean?
|
|
Assignee | |
Comment 42•23 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
|
||
Comment 43•23 years ago
|
||
This bug doesn't appear fixed. The right bar on the bottom of
http://www.sueddeutsche.de doesn't work, and is displayed in a garbled state. It
doesn't look like it's being repainted correctly. Reopen?
|
|
||
Comment 44•23 years ago
|
||
Jeremy: this bug is really fixed. You have encountered bug #100574, which is one
of the uglier bugs (many web sites badly affected) not targeted for 1.0.
You need to log in
before you can comment on or make changes to this bug.
Description
•