Closed Bug 114827 Opened 23 years ago Closed 22 years ago

Background color in frames not painted until a browser resize

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: bht237, Assigned: alexsavulov)

References

Details

(Keywords: helpwanted, regression, testcase, Whiteboard: Need Info)

Attachments

(3 files)

frameset. Should have blue and black frames, not white
505 bytes, text/html
Details
Black body (loaded into frames)
65 bytes, text/html
Details
New testcase. Start here.
553 bytes, text/html
Details 
Since Build 201111411 or a little earlier but at least after Build 201111411,
frames are missing in some cases. Refer to testcase. You should see 3 frames.
from left to right, they should be: Blue, black, black.
I see: Blue, white, white.
2001121021 trunk linux: I see blue, black, black
2001121003 NT4
See blue, white, white
Resizing the window, makes it blue, black, black

Win32 only? Anyway, I don't think it's a DOM issue.
Confirmed. (BuildID: 2001 12 10 03/Win98)
blue, black, black
refresh -> blue, white, white
resize -> blue, black, black

On load, colors are blue/default color/default color
Black color in the two last frames isn't detected untill a resize.
Hour old CVS, Linux.
Severity: critical → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Summary: frames not loaded → Frames not loaded until a browser resize
Keywords: regression, testcase
This becomes critical for us and I must admit were are getting nervous.
Why is there no target milestone? Would I have to suggest one or how does it work?
Is anyone still working on this?
Are more testcases required?
Severity: major → critical
Do you see the same problem with data: URL's? What if you put the <body
bgcolor=...> in a HTML file, still the same problem?

This hasn't gotten a milestone yet because nobody has had time to dig into this,
and it's not something that is common enough to get very high priority compared
to the other bugs we're working on. We can't make any promises on this problem
yet, but I doubt it's a DOM bug, so it will most likely go to someone else once
we know more about what's going on...
jst, this bug is limited to javascript: URLs.

It appears to be a racing condition kind of bug and as such I think it is a very
dangerous thing.

It is a regression and does not exist in Netscape releases AFAIK.

What can be done to avoid the propagation of this into a Netscape release?
Well, lets make sure it's nominated for fixing for the next release (keywords
added). Again, I don't think this is a DOM problem, so reassigning to dbaron in
hope that he has some ideas on what could cause the frames to not paint their
background properly. David, thoughts?
Assignee: jst → dbaron
Keywords: mozilla0.9.9, mozilla1.0, nsbeta1
It's interesting that the problem is corrected by a reflow but not by a repaint.
 It's not high on my priority list though, and I have less time than I used to.
Blocks: 114573
->HTMLFrames
Assignee: dbaron → eric
Severity: critical → major
Component: DOM Level 0 → HTMLFrames
I amfraid I think the general issue is not limited to javascript: URLs (jst
asked in comment #7).

Please consider the fact that in the recent bug 114573 http content in a frame
also shows only after a browser resize.

So, like in this bug, an extremely simple page doesn't load.

May I ask how bad the quality state of Mozilla is overall that such fundamental
defects are not critical enough to be worked on in a shorter time frame?

We try to keep our sites as cross-browser and simple as possible and already
avoid many features that simply don't work as advertised. Too bad.

But:

WE CANNOT DESIGN WEB SITES WITHOUT RELYING ON THE BASICS OF LOADING OF PAGES
INTO   BROWSER WINDOWS/FRAMES!!!

Do I really have to mention that such broken load or rendering behaviour is
likely to cause hard-to-detect follow-on problems possibly even crashes?
Severity: major → critical
bht: kindly give the Caps Lock key a rest.

Kevin, can you help get this bug assigned and fixed soon?  Thanks,

/be
Assignee: eric → kmcclusk
Brendan, sorry, my apologies. Me losing my patience and temper getting too
passionate with the Mozilla Project.
Marc, Can you take a quick look? If your too overloaded please pass it over to Alex.
Assignee: kmcclusk → attinasi
Target Milestone: --- → mozilla0.9.9

    
    

    
  


  
The new testcase shows that the problem is unrelated to the javascript: pseudo
protocol.

Seems to be related to frame attribute scrolling="no".

All frames should be black in this new testcase.

The error is that the center frame is white, except a little black spot in the
top left corner before a resize.

    
    

    
  
Here is another report related to this issue:

http://bugzilla.mozilla.org/show_bug.cgi?id=116723

    
    

    
  
Changing summary.
Summary: Frames not loaded until a browser resize → Background color in frames not painted until a browser resize

    
  
Status: NEW → ASSIGNED
Priority: -- → P2

    
    

    
  
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+

    
    

    
  
Moving to Mozilla 1.0 since this is not crashing - sorry to push it off, but
feel free to provide some ideas on where to look, or to take the bug (or
reassign it even, sorry, I'm swamped with crashers!).
Keywords: mozilla0.9.9, 
          
            regression
Target Milestone: mozilla0.9.9 → mozilla1.0

    
    

    
  
adding regression keyword.

is this being seen on any top sites?

is this affecting all frames, and all background color.

marking nsbeta1- per ADT triage. pls renominate if this we persuasive data that
affects many users.
Keywords: nsbeta1+ → helpwanted, 
          
            nsbeta1-, 
          
            regression
Whiteboard: Need Info
Target Milestone: mozilla1.0 → mozilla1.2

    
    

    
  
stating the obvious..: This bug isn't about frame color, but frame size.

I too see a tiny black square upper left in the middle frame of attachment 65737 [details]
Interestingly: when right-clicking to bring up a context menu for that frame, it
will ONLY appear if i right-click over that tiny square:

Before a resize, moz considers that little square to be the *whole frame*.
So no wonder it doesn't paint the "rest" - it has no idea of it being there at
all...kindam and thinks it has painted enough already.
 
Likewise in attachment 61421 [details]: The two frames without color have no context menu.

    
    

    
  
removing myself from the cc list

    
    

    
  
Passing to Alex per Brendan's comment.
Assignee: attinasi → alexsavulov
Status: ASSIGNED → NEW

    
    

    
  
Adding dependency for scrolling=no tracking bug.
Blocks: 124431
No longer blocks: 114573

    
    

    
  
This is fixed by the checkin for bug 119849

    
    

    
  
Fixed with bug 119849.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
 Verified fixed in todays trunk and branch.
Status: RESOLVED → VERIFIED

    
  
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: