Closed Bug 170688 Opened 22 years ago Closed 22 years ago

opasia.dk doesn't render completly [DHTML]

Categories

(Core :: Layout, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(3 files)

screenshot of what I seen with trunk build
67.70 KB, image/png
Details
mostly simplified testcase
580 bytes, text/html
Details
fix
1.94 KB, patch
dbaron
: review+
kinmoz
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
this bug is really really weird. Sometimes http://opasia.dk shows up almost 
blank. The top part of the site is there but the "content" is missing. I now 
have a profile that does this all the time.

I've seen this on multiple computers running Mozilla at work. I have no clue 
what the problem is.

http://mit.opasia.dk shows up just fine

the page http://opasia.dk validates just fine!

20020923
saving it as "complete webpage" and showing it from local drive produces the
correct page.
WFM - trunk build 2002092404 - WinXP.
if I disable JavaScript the page shows up fine everything.

a little more info:
The whole page actually loads when I have javascript off. If just seems to stop
rendering the layout.
If I turn of JavaScript the page loads and renders just fine.
Summary: opasia.dk sometimes shows up almost blank → opasia.dk sometimes shows up almost blank with js active
frederic: please try and set Edit -> Privacy -> Popups to Reject and then load 
opasia.dk

I've found you that it's that setting that makes opasia.dk blank!
Sorry to say, but even with your setting, site is loading without problem.

Using trunk build 2002092404 - WinXP.

I will try with today's nightly and see.

It also works in Pheonix (yesterday build). So :-)

    
    

    
  
Oups ! Looking at attachment, I confirm I see this bug with trunk build 2002092511.

Sorry :-[

    
    

    
  
I see the same problem with nightly build of phoenix!
Release 0.1 of Phoenix does not have the problem. So this is some kind of
regression.
Keywords: regression

    
    

    
  
Mozilla release 1.2 also shows the site correct. Nightly build doesn't.

moving to layout...
Assignee: asa → attinasi
Severity: normal → major
Component: Browser-General → Layout
QA Contact: asa → petersen

    
    

    
  
this bug is totally blocking the use of opasia.dk, which is the largest portal
in denmark.

seen on Windows 2000 - build 20020926
Severity: major → critical
OS: Windows XP → Windows 2000

    
    

    
  
I've arrowed it down to this:

Works with build       : 2002092404
Doesn't work with build: 2002092506

reproduceable all the time!

    
    

    
  
WFM: Using 10/13/2002 cvs trunk build on WinXP.

    
    

    
  
kevin: are you really seeing the entire site.
does URL's like:
http://opasia.dk/sektion/underholdning/
http://opasia.dk/sektion/markeder/
work? I only see the site like in the attachment:
http://bugzilla.mozilla.org/attachment.cgi?id=100561&action=view

    
    

    
  
I'm seeing this with linux trunk build 20021013.  I can help out with the
regression window a bit... :)
linux trunk build 2002092221 doesn't work, 2002092408 does not
that puts the regression between 4-8am on the 24th.
OS: Windows 2000 → All

    
    

    
  
backing out bug 75121 fixes this for me.

    
    

    
  
Andrew
thanx for the debuging info. I tried to reopen the bug but it was closed. Not
really sure what to do now.

This bug is bitting us here at TDC Internet, which owns opasia.dk. Opasia.dk is
Denmarks largest portal and currently Mozilla users cant see it!

Can we back out the patch in bug 75121 ?

It has somwthing to do with reflow since I can get the site to render if I use
the [+] buttons in the menu to the left. This seems to cause Mozilla to reflow
and repaint the site.
Summary: opasia.dk sometimes shows up almost blank with js active → opasia.dk doesn't render completly [DHTML]

    
    

    
  
Backing out the patch is not necessarily the solution.  If we backed out
anything that caused any regression we'd be making significantly slower progress
on issues like performance, and, in fact, such a policy might discourage people
from working on difficult issues like performance at all.  Landing and relanding
large patches is not easy.

However, it is worth mentioning the regression in bug 75121 so that people
involved in that bug are aware of the problem.

    
    

    
  
If you can reduce the testcase to something small, that would help immensely.

    
    

    
  


  
This still links to one external script.  I think the bug depends on both the
contents of the script and the fact that it's loading from the network,
although I'm not sure.

    
    

    
  
(And, FWIW, it took me the full 40 minutes to simplify that, not just the time
starting from roc's comment.  If you want a bug to be fixed, making sure that it
has a simplified testcase is probably the first thing to do.)

    
    

    
  
(And, FWIW, the testcase requires a Shift-Reload after it's been loaded for the
first time.)

    
    

    
  
I did some investigation. Here are some notes before I go to bed.

After the script has loaded, we add some more content which triggers a reflow
which should lay everything out properly. I do see a Dirty reflow being targeted
at the DIV, but the child list is *empty*. This reflow doesn't do anything
because the child that has changed is on the Absolute child list.

So the question is, how was the reflow generated with the wrong child list? I
suspect that somewhere in the table code an incremental reflow is converted to a
dirty reflow, but that this process sets the wrong child list.

    
    

    
  
IIRC, there's only one caller that uses the child list ability of the reflow
command, and that one doesn't really need to.  In other words, I think that when
the child list is null, it's meaningless, rather than indicating the default
child list.

    
    

    
  
An interesting note -- using printf debugging, I found that I enter the
non-incremental handling code for absolutely positioned elements only once when
things work correctly (i.e., first load when the script is cached) but that I
enter it twice when things are broken.

    
    

    
  
Yup --- the second time is when we're doing a dirty reflow with the wrong child
list; nsAbsoluteContainingBlock::IncrementalReflow can't handle it, so
nsBlockFrame::Reflow goes ahead and reflows dirty lines. Of course there aren't
any :-). Once we fix this the second reflow will be handled by
nsAbsoluteContainingBlock::IncrementalReflow. So this is a perf issue as well as
a correctness issue.

    
    

    
  
But, er...

nsAbsoluteContainingBlock::Reflow does get a chance to handle it, and does call
ReflowAbsoluteFrame (with Resize rather than Dirty, admittedly, but that's
because of a bug that I just fixed in my tree and it doesn't help).

It's also worth noting that we're hitting the code in
IncrementalReflow::AddCommand where there are two commands on the same target,
although in this case they both have the same type (Dirty).

    
    

    
  
There is actually an empty line after the table... perhaps I'm seeing the reflow
for that, and the reflow for the absolute frame is being completely lost
somewhere. I'll have to do more printf debugging tonight.

    
    

    
  
> nsAbsoluteContainingBlock::Reflow does get a chance to handle it, and does call
> ReflowAbsoluteFrame

That's not what I remember from last night, but I could well be wrong. I'll just
have to look at it again tonight.

    
    

    
  
OK, I found the problem!

nsAbsoluteContainingBlock::IncrementalReflow absolutely must go through all the
child absolute frames and incrementally reflow any that are on reflow paths.
nsBlockFrame::Reflow will not do it --- my comment to the contrary was just
plain wrong. So basically IncrementalReflow must never exit early. We still need
to set aWasHandled correctly, though, so I've changed the way we do that to
something a little more sane.

    
    

    
  
Comment on attachment 103279 [details] [diff] [review]
fix

a=asa

        Attachment #103279 -
        Flags: approval+

    
    

    
  
now we have r=, sr= and a= could someone with cvs access check the patch in?

    
    

    
  
roc has cvs access
Assignee: attinasi → roc+moz

    
    

    
  
yeah, I'll check this in.

    
    

    
  
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: