270804 - relatively positioned does not take 100% width until clicked

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Jelle Ursem]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The bug kinda looks like IE's peek-a-boo bug :
http://positioniseverything.net/explorer/peekaboo.html

If you check out http://www.schizofreend.nl/windowtest/ you'll see some of my
DHTML experiments. The bug is in the header part of the 'windows'. The titlebar
should as usual fill out over the entire width of the parent element, but it
does not until clicked.

Please note that the entire site is built dynamically using javascripts.


Reproducible: Didn't try
Steps to Reproduce:
1.
2.
3.



Expected Results:  
The titlebar of each window should as usual fill out over the entire width of
the parent element, but it does not until clicked.

Comment 1

[Jelle Ursem]

Attachment: Bug rendered in browser

This shows the bug in progress

Comment 2

[Jelle Ursem]

Attachment: expected results.

This shows what the page looks like after the 'faulty' elements have been
clicked.: The element is expanded as expected.

Comment 3

[Jelle Ursem]

I have not had the time to break this example down to a bare example, mostly due
to lack of time. Please note that the bug doesn't occur in two of the five
windows. Why this happens i don't know.

Comment 4

[Martijn Wargers (dead)]

I'm seeing this also with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041119
Firefox/0.9.1+
A simple example/testcase is needed here.

Comment 5

[Martijn Wargers (dead)]

Attachment: Testcase

The window is an absolute positioned div, with no width set (=auto), so the div
shrink wraps around the content.
When content gets added dynamically, the div gets larger, but the title div
doesn't 'grow' along.

This does also happen with float:left on .window instead of position: absolute;

and with width:100% for .title.

Comment 6

[Martijn Wargers (dead)]

It's clearly a bug in Mozilla, but it might be a duplicate (but I couldn't find
one).

Comment 7

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

Attachment: fix

The problem is that the shrink-wrap logic requires us to mark dirty any lines
that need to be reflowed once we know the final width. ReflowBlockFrame and
PlaceLine (for inline lines) do this for the blocks and inlines that get
reflowed. But if we skip reflowing a line during the first pass, then we won't
reflow it during the shrink-wrap fixup pass either.

This patch just forces any lines that we skipped reflowing to be reflowed
during the shrink-wrap fixup pass. I can't think of a better way right now.
Maybe post-reflow-refactoring, this could work better.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Do you need to mark the line dirty, or is just setting the flag enough?  If so,
maybe we should just get rid of BRS_NEEDRESIZEREFLOW entirely.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

never mind, I read your comment now.  But BRS_NEEDRESIZEREFLOW should probably
go anyway, although that could just be part of reflow refactoring.

Comment 10

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

checked in, with an additional comment:

          // XXX For inlines, we could record in the line box
          // that HorzontalAlignFrames does not depend on the line width,
          // and thus we don't have to mark it dirty here

Comment 11

[Boris Zbarsky [:bzbarsky]]

So is this fixed?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Note that that patch caused a regression when moving around position:fixed
elements (which it really shouldn't have...).  See bug 277766

Comment 13

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

Sorry, this is fixed ... modulo the regression, which I'll work on there.