Closed Bug 1482938 Opened 2 years ago Closed 9 months ago

Container height does not recalculate if add content to the container dynamically and after timeout set height auto to the base container

Categories

(Core :: Layout, defect, P3)

41 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- verified

People

(Reporter: alexandrkovl, Assigned: dbaron)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Attached file archive with example of the bug (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

1) create a container with a fixed height
<div style="height: 50px">container<div>
2) add two embedded containers with style height: 100% to the first container by javascript code.
        <div style="height: 100%">
            <div style="height: 100%">                
            </div>
        </div>
3) Add an element with height more then first container to the most internal container using the javascript code
<div style="height: 100px">item</div>
4) Set height: auto style to the first container after some timeout
See example is in the attachment
Reproduced in versions 41.0 and later



Actual results:

The height of the base container does not recalculate


Expected results:

The height of the base container recalculates.
The timeout should not influence to the height calculation
Component: Untriaged → Layout
Product: Firefox → Core
Keywords: regression
Version: 62 Branch → 41 Branch
Looks like going from height: explicit to height: auto is not properly working, presumably (though just a guess for now) because we optimize away the reflows of the inner containers.

David, do you know if we have a bug on file for something like this? Bug 1351924 might be related, but it's not totally clear to me it is...
Attachment #8999683 - Attachment is obsolete: true
Flags: needinfo?(dbaron)
Attachment #8999693 - Attachment filename: file_1482938.txt → file_1482938.html
Attachment #8999693 - Attachment mime type: text/plain → text/html
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a12d1b2e6e17&tochange=09878dde0cc8

Regressed by: Bug 1172239
Blocks: 1172239
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks for the regression range Alice! And thanks for the test-case Alexander, was really easy to reduce.
Bug 1351924 or followup patches to it should definitely fix this.
Depends on: 1351924
Flags: needinfo?(dbaron)
Hello! someone have any news about this problem?
can you tell me when this bug will be fixed?
Flags: needinfo?(emilio)
See comment 4, bug 1351924 should fix this.
Flags: needinfo?(emilio)
Tracking this in bug 1351924. There is a patch there but it hasn't landed yet.
Priority: -- → P3

This will be fixed by the patches in bug bug 1351924 that I hope to land next week.

Assignee: nobody → dbaron
Status: NEW → ASSIGNED

Fixed by bug 1351924.

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Flags: qe-verify+

Reproduces the issue with Firefox 63.0a1 (20180813220525) on Windows 10 x64. The issue is verified fixed with 70.0b9 (20190923154733) on Windows 10x64, macOS 10.14 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

Thanks, the base issue is resolved in the new version. But i find what the issue is still reproduced with "overflow: hidden" style on the base container. As i understand it related to the base issue. Can you see my example ?

Flags: needinfo?(dbaron)

I filed that problem as bug 1595199 (with a simpler version of the testcase).

Flags: needinfo?(dbaron)
You need to log in before you can comment on or make changes to this bug.