95147 - Frame's aren't painting properly when you resize the window

Status: RESOLVED WORKSFORME

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

Description

[Scott MacGregor]

Someone recently added a new frame to the tinderbox page which lists the build
status of all the port machines. (pretty cool).

Try horizontally resizing the tinderbox page. Notice that we paint the ports
frame twice (once at the upper right hand corner of the window and again in the
correct position). It's almost like a "shadow" type efffect. As you move the
positioning back & forth you can see us incorrectly painting the frame in the
upper right hand corner of the window.

Using a windows build. Build ID: 2001080904.

Comment 1

[Kevin McCluskey (gone)]

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

Comment 2

[John Morrison]

Isnt' this actually a view manager thing (as opposed to iframes)? 

Comment 3

[John Morrison]

Attachment: simplest case; depends on iframe which is floated right

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Could be views, but I suspect it's really reflow.

Comment 5

[John Morrison]

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

Comment 6

[Kevin McCluskey (gone)]

My guess is the reflow is doing an uncontrained reflow first which causes the
widget associated with iframe to be positioned at the upper right, followed by
resize reflow which positions the iframe in the correct position. Since the
iframe has a widget we see the in-between result.

Comment 7

[Kevin McCluskey (gone)]

Bulk moving Moz1.2 bugs to future-P3. I will pull from this list when scheduling
post Mozilla1.0 work.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Nils Hammar]

I think that I have noticed a bug that relates to this bug, and it is
demonstrated by the following:

- Open a JavaDoc page (E.g. http://jakarta.apache.org/log4j/docs/api/index.html)
in a relatively small browser window.
- Move the horizontal frame separator between the left frames down a bit.
- Move the horizontal frame separator between the left frames up a bit.
- Grab the top of the browser window to enlarge it vertically.

In this case the lower left frame isn't resized, but will leave a blank space
below the horizontal scrollbar.

This also seems to be related to an effect where the vertical scrollbars and the
frame separators can be differently placed if the data in the lower left frame
is longer than the data in the upper left frame and the frames are resized
horizontally.

My current versions/drivers:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
Windows 2000SP3
ATI RAGE MOBILITY-M PCI graphichs adapter.

/Nils Hammar

Comment 10

[James Ross]

Just came accross this today, using Mozilla 1.3b build 20021220.

Not sure how useful this is, but I did notice that the iframe content painted in
the wrong place doesn't have the iframe's border round it (i.e. it's only
painting the content in the wrong place, not the actual iframe).

Comment 11

[Stefan Borggraefe]

Also happens with Linux.

Comment 12

[Sergey Sokoloff]

Still happens in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8)
Gecko/20050511 Firefox/1.0.4

It was detected and reported recently by Dmitriy Karlovskiy in the newsgroup
named Fido7.Ru.HTML.Profy.

The bug assignee is gone. Should the bug be unassigned then?

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Works now.