Closed Bug 91747 Opened 23 years ago Closed 23 years ago

iframe larger than screen causes Mozilla to stop painting

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: helmut.leininger, Assigned: kmcclusk)

References

(
URL
)

Details

(Keywords: testcase, top100, Whiteboard: [Hixie-P3])

Attachments

(4 files)

Screenshot after tabbing back and forth.
195.87 KB, image/png
Details
Testcase
207 bytes, text/html
Details
Testcase #2
676 bytes, text/html
Details
A simple testcase
163 bytes, text/html
Details 
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.
wfm with win2k build 20010720..
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>

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");}

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

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
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
->DOM for investigation.
Assignee: asa → jst
Component: Browser-General → DOM Level 0
QA Contact: doronr → desale
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
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 -

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.
I think that </html> needs to be escaped and that this is Evang fodder.
Component: Layout → Evangelism
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. 
I just downloaded the latest trunk build. Same behaviour here. I'll upload a
screenshot of what happens. 
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.
Attached file Testcase — 

    
    

    
  
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

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase #2
        — 
      

    


  

    
    

    
  
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.

    
    

    
  
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.
Whiteboard: [Hixie-P3]

    
    

    
  
*** Bug 90341 has been marked as a duplicate of this bug. ***

    
    

    
  
Reassinging to pollmann.
Assignee: karnaze → pollmann

    
    

    
  
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov

    
  
Summary: Mozilla stops painting after visiting this url. → Mozilla stops painting after visiting this url.[form]

    
  
Summary: Mozilla stops painting after visiting this url.[form] → Mozilla stops painting after visiting this url.[form sub]

    
    

    
  
*** Bug 104111 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 110045 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

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

    
    

    
  
can someone put a test case together please?

    
    

    
  

      
      
      
      

        Attached file
          
        A simple testcase
        — 
      

    


  
This is a simple testcase, an html document containing an iframe with height
set to 10 000.

    
    

    
  
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)

    
    

    
  
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?

    
    

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

    
    

    
  
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.

    
    

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



    
    

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


    
    

    
  
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.

    
    

    
  
Updating summary to reflect the cause of the bug, and changing URL to one that
actually exposes the bug.
URL: http://www.keyzone.at → http://www.sueddeutsche.de
Summary: Mozilla stops painting after visiting this url. → iframe larger than screen causes Mozilla to stop painting

    
    

    
  
-> kevin
Assignee: alexsavulov → kmcclusk
Status: REOPENED → NEW

    
    

    
  
Note: This bug should be fixed when both bug 95952 and bug 114082 are fixed
Target Milestone: --- → mozilla0.9.8

    
  
Depends on: 95952, 114082

    
    

    
  
same issue as in bug 91747?

    
    

    
  
ooops.. same issue as in bug 64049 i mean?

    
    

    
  
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
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?


    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: