Open Bug 1936392 Opened 2 months ago Updated 1 day ago

Recent Firefox update causes overlapping forms

Categories

(Core :: Layout: Tables, defect)

Firefox 133
defect

Tracking

()

Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox133 --- wontfix
firefox134 --- wontfix
firefox135 --- wontfix
firefox136 --- fix-optional

People

(Reporter: jag9111, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Updated Firefox to 133.0.3
Opened a page I visit daily in my Intranet (I cannot provide a working link)

Actual results:

Form at top of page is running over subsequent sections lower on page

Expected results:

Upper bounds should have expanded to encompass form.

Others in my organization were having this issue but I was not. I updated Firefox to test theory and proved that to be the issue.
FWIW, I am the web developer for this organization, though most of our intranet was created by others in the past. We use OpenTaps, which is built on the Apache ofbiz platform. Nothing changed, in this case, expect for the update to Firefox.

Component: Untriaged → Layout
Product: Firefox → Core

Hi Griffin,

Could you provide a static page (a standalone html) via "Attach New File"? Without a reduced testcase, it is difficult to diagnose the cause of the overlapping content. Thanks!

Flags: needinfo?(jag9111)
I cannot include a webpage that shows it. Our system generates the webpages using a combination of xml and ftl (freemarker). There are at least 5 different files of these types used to make the page that is causing an issue. Each logical section of the page is generated by a different include. I found a hack to make our page work for now, but it is definately a hack and not a long term solution.

I cannot include a static webpage that shows it. Our system generates the webpages dynamically using a combination of xml and ftl (freemarker). There are at least 5 different files of these types used to make the page that is causing this issue. Each logical section of the page is generated by a different include or combination of more than one.

FWIW, I found a hack to make our page work for now, but it is definately a hack and not a long term solution.

I've attached a portion of the generating code. This is one of the contributing .ftl files. They are an extension of html.

You can see that I added 9 empty rows to the table. This forces the area of the box to expand just enough to fit the content. For some reason, after the first 10 rows in the included form content, the box no longer expands to fit.

See line 25 ${screens.render("component://po/widget/po/screens/planning/PlanningScreens.xml#eoqItemBasicValues")}

That line of code pulls an xml form listing the data that runs over the box below it in the originally included screenshot. By adding more lines to the table, it forces the box to expand.

Flags: needinfo?(jag9111)

Table layout is tricky. I'm glad you find a hack that makes the site work in Firefox.

This bug sounds like a recent regression per comment 1. In order to move this bug forward, if you have time, you could help us find a specific commit that breaks your site via https://mozilla.github.io/mozregression/.

I've never used mozregression before, but I thinkI got it figured out. Is this the output that you need?

2024-12-11T13:23:00.128000: DEBUG : Found commit message:
Bug 1923201 - Make table row height not influenced by baseline of child cell. r=dshin

This matches Blink, and WebKit trunk1, and prevents regressions when landing
bug 1922900.

Differential Revision: https://phabricator.services.mozilla.com/D224805

2024-12-11T13:23:00.128000: DEBUG : Did not find a branch, checking all integration branches
2024-12-11T13:23:00.129000: INFO : The bisection is done.
2024-12-11T13:23:00.130000: INFO : Stopped

I've never used mozregression before, but I thinkI got it figured out. Is this the output that you need?

Yes, this is helpful because the patch changes the table layout. Thanks for using mozregression to find the regression bug.

Severity: -- → S3
Keywords: regression
Regressed by: 1923201

:emilio, since you are the author of the regressor, bug 1923201, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)

Unfortunately to investigate this I need not only the HTML but also the CSS that applies to the site. Griffin, any chance you could:

  • Install https://addons.mozilla.org/en-US/firefox/addon/testcase-reducer/ (it's made by a mozilla employee)
  • Go to a page that shows the issue.
  • Inspect the relevant broken table with DevTools.
  • Go to the testcase reducer tab, click "Reduce".
  • If it shows a broken table on the right, copy the code on the left and attach it here.

Alternatively, I'd need access to some sort of repro, feel free to mail me and I can look.

Flags: needinfo?(emilio) → needinfo?(jag9111)

I tried to follow your steps, but am not getting any results. I am not familiar with these tools. Here's what I did:

  • Installed testcase-reducer
  • Went to page with issue
  • inspected table with DevTools
  • Went to tab and clicked reduce

Nothing appears on the right except the very top of the page. The table is not included at all. Nor is all the rest of the page.

Would you like to connect remotely at an agreed upon time and run the tool yourself on my computer. Unfortunately, since this is on our intranet, there is no way for me to grant you access from outside.

FWIW, I use AnyDesk to connect from home. I think we could both connect to the same machine simultaneously using AD. Will that work for you?

Flags: needinfo?(jag9111)

Okay, that'd work for me, but we could do something else first (that saves the timezone headaches, and having to figure out how to connect remotely to your machine, I'm not familiar with AnyDesk). Could you:

  • Install https://addons.mozilla.org/en-US/firefox/addon/single-file/
  • Save the page with that extension, and attach it here if it doesn't contain sensitive data.
  • If it contains sensitive data, you can attach it privately (with the "Make attachment and comment private" checkbox checked), or alternatively just email it to me and I can try to reduce it.

Thanks!

Flags: needinfo?(jag9111)
Attached file Overlapping table example.htm (obsolete) —

HTML attached. Wanted to make it private but couldn't find the option. It is not really sensitive data, but better to err on the side of caustion. Alas, unable.

Flags: needinfo?(jag9111)

I think instead of using the SingleFile extension, you used regular Ctrl+S to save it (and thus there are missing images and styles?). The rendering of comment 12 is the same in Firefox and Chrome here (but probably because of the aforementioned issue).

Flags: needinfo?(jag9111)

(alternatively zip the html and the files together, which are in a folder like Overlapping table example_files, and attach the whole zip, was just trying to save you the trouble of zipping it up :)

Added file Financial Success Purchasing (12_13_2024 12:42:57 PM).html

Attachment #9443325 - Attachment is obsolete: true
Flags: needinfo?(jag9111)

Thanks! I can repro the overlap on that page.

Flags: needinfo?(jag9111)
Flags: needinfo?(jag9111) → needinfo?(emilio)
Attached file Reduced test-case.

Fairly shocking that we (and WPT) had no tests for something like this, sigh.

Assignee: nobody → emilio
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(emilio)

This seems to match other browsers. Partially backs out the regressing
bug. Let's see how this fares on try.

Set release status flags based on info from the regressing bug 1923201

As expected comment 18 breaks the container query tests and regresses the baseline-td tests. Safari TP matches our behavior, for what is worth.

Given the container query regressions are mostly about no baseline / empty baseline, I can also look at that, it seems our handling there is a bit funky.

Ian, do you happen to know what Blink is doing? It seems to be accounting for baseline alignment for sizing, which is a bit odd in general...

Flags: needinfo?(ianjkilpatrick)

Our equivalent baseline logic is:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/table/table_layout_utils.cc;l=1732-1760;drc=dd73812bb7bca5b8fb5105127573bcfd4f226a27;bpv=1;bpt=1

The only difference I can see (just quickly) is for rowspanned cells we only accumulate the ascent (not the descent - as it'll typically belong to a different row).

Flags: needinfo?(ianjkilpatrick)

container query regressions

We successfully shipped dropping layout containment from container queries fwiw, and safari has landed code to do so.
https://github.com/w3c/csswg-drafts/issues/10544#issuecomment-2248438355

We too, fwiw :)

Status: NEW → UNCONFIRMED
Ever confirmed: false

Err, status changes weren't intentional...

Status: UNCONFIRMED → NEW
Ever confirmed: true

We too, fwiw :)

\o/ Horray!

Set release status flags based on info from the regressing bug 1923201

@emilio - One difference is that we allow baselines to go negative, vs. gecko which has limited them to zero - https://searchfox.org/mozilla-central/source/layout/tables/nsTableRowFrame.h#293-294 (this is a common bug in baseline code assuming that baselines aren't negative).

Component: Layout → Layout: Tables
Duplicate of this bug: 1942471
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: