Recent Firefox update causes overlapping forms
Categories
(Core :: Layout: Tables, 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.
![]() |
||
Updated•2 months ago
|
Comment 2•2 months ago
|
||
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!
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.
Comment 5•2 months ago
|
||
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
Comment 7•2 months ago
|
||
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.
Comment 8•2 months ago
|
||
:emilio, since you are the author of the regressor, bug 1923201, could you take a look?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 9•2 months ago
|
||
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.
Reporter | ||
Comment 10•2 months ago
|
||
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?
Assignee | ||
Comment 11•2 months ago
|
||
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!
Reporter | ||
Comment 12•2 months ago
|
||
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.
Assignee | ||
Comment 13•2 months ago
|
||
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).
Assignee | ||
Comment 14•2 months ago
|
||
(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 :)
Reporter | ||
Comment 15•2 months ago
|
||
Added file Financial Success Purchasing (12_13_2024 12:42:57 PM).html
Assignee | ||
Comment 16•2 months ago
|
||
Thanks! I can repro the overlap on that page.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 17•2 months ago
|
||
Fairly shocking that we (and WPT) had no tests for something like this, sigh.
Assignee | ||
Comment 18•2 months ago
|
||
This seems to match other browsers. Partially backs out the regressing
bug. Let's see how this fares on try.
Comment 19•2 months ago
|
||
Set release status flags based on info from the regressing bug 1923201
Updated•2 months ago
|
Assignee | ||
Comment 20•2 months ago
|
||
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...
Comment 21•2 months ago
|
||
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).
Comment 22•2 months ago
|
||
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
Assignee | ||
Comment 23•2 months ago
|
||
We too, fwiw :)
Assignee | ||
Comment 24•2 months ago
|
||
Err, status changes weren't intentional...
Comment 25•2 months ago
|
||
We too, fwiw :)
\o/ Horray!
Comment 26•2 months ago
|
||
Set release status flags based on info from the regressing bug 1923201
Updated•2 months ago
|
Updated•2 months ago
|
Comment 27•2 months ago
|
||
@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).
Updated•2 months ago
|
Updated•23 days ago
|
Updated•6 days ago
|
Description
•