Closed Bug 283468 Opened 19 years ago Closed 19 years ago

[FIX]page briefly appears then disappears

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: mndnormand, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Real testcase
226 bytes, text/html
Details
Proposed fix
3.71 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050223
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050223

the above url becomes http://www2.photim.com/info/Sommaire.php 
the corresponding page briefly appears then a blank page takes place.

popup and cookies are allowed

with mozilla 1.7.3 and Firefox 1.0 (and internet explorer 6.0 sp1) this page is
well displayed.

Reproducible: Always

Steps to Reproduce:
1.enter the url http://www.photim.com/infos/default.asp
2.
3.

Actual Results:  
the corresponding page briefly appears then a blank page takes place.


Expected Results:  
The Chasseurs d'Images Home page
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050221
Firefox/1.0+

I eventually got a redirect to http://www.pixiphot.com/ , however I suspect
that the problem (if any) is with faulty javascript on the page you gave.

That page has a proper DOCTYPE:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
but numerous markup errors.

I may be wrong (and my lizard is a few days old) but Firefox is
probably handling the code received per specification.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050223
to the interested reader: 
debug is for debuggers, change the settings mentioned here, but don´t expect
changing other settings in this menu won´t give you problems.
Good setting for generating invalid bugs is checking the 'debug XUL Boxes'
setting, you´ll need to delete your profile or edit prefs.js using notepad.

Preferences->Debug
[x] show strict Javascript warnings
[x] show chrome Javascript errors & warnings 

JS console is showing nearly a hundred of this error message:

Error: Error in parsing value for property 'visibility'.  Declaration dropped.
Source File: http://www2.photim.com/info/Sommaire.php
Line: 0
Yeah, if you disable JS the page displays fine. Tech Evanglism?
Actually, that's not the case.  We screw up a getElementById call on the page. 
Minimal testcase coming up.
Assignee: general → general
Status: UNCONFIRMED → NEW
Component: General → DOM: Core
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → Trunk
ccing the other people who didn't read the page source...
Attached file Testcase (obsolete) — 
Note that if I remove the if check things work.  The problem is that we're
caching the "not in document" state till we get notified on the new content,
but in this case we don't get the notification before the next GetElementById
call (due to lack of a content flush).
Attached file Real testcase — 

        Attachment #175745 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Proposed fix
        — 
          — Splinter Review
      

    


  
This was "broken" by the fix in bug 144072.  What used to happen is that the
page would resolve document.getElementById, this would call into
nsHTMLDocument::ResolveName, which would trigger a FlushPendingNotifications(),
which would update the ID table.  Then we'd actually call the method, and get
the object.  The patch for bug 144072 changed the flush in ResolveName to only
flush content (not content notifications); this isn't quite correct, as the
comments in this patch explain.  But in any case, simply resolving the
"getElementById" property no longer caused a flush, so the lack of a flush in
GetElementById started to bite us.

This patch has two parts:

1)  Fix GetElementById to flush when it needs to (with some comments on why I
    think this is the only case it needs to flush in...  but I'm not
    _completely_ sure the reasoning there is correct, to be truthful).
2)  Fix the flush in ResolveName to flush notifications when they're necessary.
Assignee: general → bzbarsky
Status: NEW → ASSIGNED

        Attachment #175751 -
        Flags: superreview?(jst)

        Attachment #175751 -
        Flags: review?(jst)

    
  
Keywords: regression
OS: Windows 98 → All
Priority: -- → P1
Hardware: PC → All
Summary: page briefly appears then disappears → [FIX]page briefly appears then disappears
Target Milestone: --- → mozilla1.8beta2

    
    

    
  
Comment on attachment 175751 [details] [diff] [review]
Proposed fix

r+sr=jst

        Attachment #175751 -
        Flags: superreview?(jst)

        Attachment #175751 -
        Flags: superreview+

        Attachment #175751 -
        Flags: review?(jst)

        Attachment #175751 -
        Flags: review+

    
    

    
  
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
  
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: