Open Bug 1521088 Opened 6 years ago Updated 12 days ago

A height of DIV containers with specified paddings is re-calculated incorrectly while resizing a browser's window (causing failure in WPT css/css-grid/table-grid-item-dynamic-004.html )

Categories

(Core :: Layout: Grid, defect, P3)

Product:
Core
Component:
Layout: Grid
Version:
52 Branch
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox-esr60 --- wontfix
firefox-esr115 --- wontfix
firefox-esr128 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox129 --- wontfix
firefox130 --- wontfix
firefox131 --- wontfix
firefox132 --- wontfix

People

(Reporter: support, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

testPage.html
642 bytes, text/html
Details
Screencast 2019-01-18.mp4
313.77 KB, video/mp4
Details
ChromeTest.mp4
414.97 KB, video/mp4
Details
table cut Jira.png
200.37 KB, image/png
Details
Attached file testPage.html —

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

  1. Create the following HTML page
    <!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div style="height: 150px; display: grid;">
<div style="height: 100%; display: table; padding: 2px 2px 0px 0px;">
<div style="width: 50px; min-width: 50px; display: table;">
<label>Test:</label>
</div>
<div style="width: 100%; height: 69px; background-color: lightcoral; display: table-cell;">
</div>
</div>
</div>
</form>
</body>
</html>

  1. Try resizing a browser's window

Actual results:

The DIV height is always increasing

Expected results:

The DIV height should remain unchanged (like in other browsers)

See the attached video

Attached video ChromeTest.mp4 —

Video demonstrates the same scenario in the Chrome browser
The DIV's height is not changed

Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
Component: Layout: Block and Inline → Layout: Tables

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c11a7836e61b18bcb4dd3d75191ffd10830b9280&tochange=cb5c261faec02c184166fe2c3221870caf394248

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox64: --- → wontfix
status-firefox65: --- → wontfix
status-firefox66: --- → affected
status-firefox-esr60: --- → wontfix
Component: Layout: Tables → Layout: Grid
Ever confirmed: true
Keywords: regression
Version: 64 Branch → 52 Branch
Blocks: css-grid
Priority: -- → P3

Sounds like it might be the same underlying issue as bug 1492315.

Depends on: 1492315

Sean, do you think your team will get to this soon? It's been a wontfix regression for a while now so the regression triagers were wondering if we should stop tracking it and just let it go into your backlog.

Flags: needinfo?(svoisen)

Yes, given the P3 priority, will just get this part of our backlog of upcoming grid fixes.

Flags: needinfo?(svoisen)

Thanks. Sounds like a wontfix for 67, too, so I modified that and we can let it "fall off the radar" of the regression bug triage meeting.

status-firefox67: affected → wontfix
Severity: normal → S3
Blocks: interop-2023-grid
Summary: A height of DIV containers with specified paddings is re-calculated incorrectly while resizing a browser's window → A height of DIV containers with specified paddings is re-calculated incorrectly while resizing a browser's window (causing failure in WPT css/css-grid/table-grid-item-dynamic-004.html )

When resolving the grid rows of a grid container frame, we use an unconstrained
block size as the block axis's percentage basis to measure a grid item's content
size. However, during an incremental reflow, the grid item may have been
reflowed against a definite grid row size previously. To address this, the grid
container sets relevant BResize flags to the item's ReflowInput [1] to indicate
that the item's block size may change and a reflow is needed. However, these
flags are not propagated from table wrapper frame's ReflowInput to table
frame's ReflowInput, so the table frame doesn't get reflowed due to the check
in [2].

This patch is similar to the handling in ViewportFrame [1] or
ScrollContainerFrame [2], where these flags are also propagated to their inner
frame's ReflowInput.

[1] https://searchfox.org/mozilla-central/rev/a85b25946f7f8eebf466bd7ad821b82b68a9231f/layout/generic/nsGridContainerFrame.cpp#5382-5384
[2] https://searchfox.org/mozilla-central/rev/a85b25946f7f8eebf466bd7ad821b82b68a9231f/layout/tables/nsTableFrame.cpp#1658-1660
[3] https://searchfox.org/mozilla-central/rev/a85b25946f7f8eebf466bd7ad821b82b68a9231f/layout/generic/ViewportFrame.cpp#352-357
[4] https://searchfox.org/mozilla-central/rev/a85b25946f7f8eebf466bd7ad821b82b68a9231f/layout/generic/ScrollContainerFrame.cpp#897-902

Assignee: nobody → aethanyc
Status: NEW → ASSIGNED
Pushed by aethanyc@gmail.com: https://hg.mozilla.org/integration/autoland/rev/e573e9da7c9e Carry BResize flags from table wrapper frame's ReflowInput to table frame's ReflowInput. r=dholbert

https://hg.mozilla.org/mozilla-central/rev/e573e9da7c9e

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
status-firefox131: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch

Hi good people, I think this fix broke something, at least with Jira. Recently Jira moved to a table display for the results of a query, and it was working fine in the first part of August. However, while I was working on my teams' metrics in recent days, I noticed that when I have results like:

  • 1 issue in query - the issue display is cut in half and I need to scroll to view it
  • 2 issues - only the first is displayed, I need to scroll for the second
  • 3 issues - only 2 displayed, etc you got the idea.

I complained about this to my team, and they told me that it properly works for them. So I cleared my cache first for Atlassian, then did a hard refers (Ctrl+F5), same results. So I've run a regression window which got me to this bug number. On August 24th it was ok, it started to happen on the 25th build.

I'll share a picture with the outcome, let me know if you need more details.

Could you file a separate bug with a concrete URL so we can reproduce it? Thanks!

Flags: needinfo?(poiegas)
Regressions: 1917028

I can repro, so I went ahead and filed (bug 1917028). If Paul happens to have also filed, we can mark one bug as a dupe of the other.

Flags: needinfo?(poiegas)

Backout for causing Bug 1917028
Backout link beta: https://hg.mozilla.org/releases/mozilla-beta/rev/cb62ef7a511b79f11b0bdc03e54b36bd53912e12
Backout link central: https://hg.mozilla.org/mozilla-central/rev/067bb0e7490429dfc19415b08a74b5f7fbdbe6c4

Status: RESOLVED → REOPENED
status-firefox131: fixed → ---
Flags: needinfo?(aethanyc)
Resolution: FIXED → ---
Target Milestone: 131 Branch → ---

See Bug 1917028 Comment 8 for an analysis of why the patch in comment 10 won't work. We probably need to tackle bug 359481 or bug 1883699, or get a better understanding of how percentage block-size in table works.

Assignee: aethanyc → nobody
Flags: needinfo?(aethanyc)

Marking affected since the backout means 131 and 132 would still be affected.

status-firefox131: --- → affected
status-firefox132: --- → affected
Attachment #9420607 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: