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

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[alexander]

Attachment: archive with example of the bug

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

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: A little reduced and with less script.

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...

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a12d1b2e6e17&tochange=09878dde0cc8

Regressed by: Bug 1172239

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Thanks for the regression range Alice! And thanks for the test-case Alexander, was really easy to reduce.

Comment 4

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

Bug 1351924 or followup patches to it should definitely fix this.

Comment 5

[angelopez]

Hello! someone have any news about this problem?
can you tell me when this bug will be fixed?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

See comment 4, bug 1351924 should fix this.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking this in bug 1351924. There is a patch there but it hasn't landed yet.

Comment 8

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

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

Comment 9

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

Fixed by bug 1351924.

Comment 10

[Alexandru Trif, Desktop Test Engineering [:atrif]]

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.

Comment 11

[alexander]

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 ?

Comment 12

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

Attachment: example referenced in comment 11

Comment 13

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

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