Container Queries - Leaky Containers
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: support, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:110.0) Gecko/20100101 Firefox/110.0
Steps to reproduce:
I have been working w/ container queries for the past month on the nightly and there always has been a "leaky container" situation. Where a change in one container dimension affects another. In this case I have built a color picker component and when two are visible and one of the picker / containers has constraints (width) modified this will affect an unrelated picker / container.
This issue does not occur on Chrome. I have attached webm files showing the issue.
Potential reproduction steps:
- Have two instances of the same named container visible
- Resize one of the containers
Viewing the video will help explain the above.
Actual results:
A change in constraints of one container affects another.
Expected results:
The first / top container / color picker should not be affected by a change in container constraints of another component / picker.
The leaky container side effect is only occurs when both components / containers are visible. Changing width of a display: none container does not leak. In this video I have the bottom color picker set to popup mode so you can see the leaky side effect only when it is visible.
|
||
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•1 year ago
|
||
I think this might be the style sharing bug fix that was fixed in bug 1804677, but if it still repros on latest nightly it'd be good to understand what's going on.
Would there be any chance of attaching an html repro / test-case that reproduces the issue? The more minimal the better of course, but I can try to reduce it myself otherwise.
|
|
||
Updated•1 year ago
|
|
|
||
Comment 4•1 year ago
|
||
Ping? It'd be great to get a test-case here, otherwise we can't act on it.
I'd like to get something together... External concerns particularly the flooding in the SF Bay Area w/ the atmospheric river / strong storms is preventing any time available on my side. My building, I'm on the bottom floor, is flooding inside with the recent storms and I'm not looking forward to the next two days of trying to prevent this all happening again which it is going to despite best efforts and manning pumps through the bad weather... :(
I gather a separate test case can be put together. The challenge on my side is that the specific code (color picker) and videos above are from an implementation of container query support in Svelte which requires a custom build I've created. It would be much easier if I could just throw up a demo on the Svelte REPL, but that isn't possible w/ my custom build currently.
I don't see why a test case can't be implemented standalone, but it would possibly take half a day or so. At best I can possibly work on something next week.
So, I was able to spend a ~4+ hours today trying to minimize a test case. There likely will not be a standalone test case possible as it appears that the odd Firefox container query behavior is a combination between Svelte and CQ usage. It requires two components to have a bound variable and my gumption is leading me to believe that whatever is triggering the side effect that I'm seeing has to do w/ how Svelte updates / manages bound variables. Do keep mind that this is not a problem on Chrome. I don't particularly think though can't say for sure if Svelte is at "fault" either.
While the symptoms are not resolved I do believe that this issue can be downgraded to "keep an eye on" as further action needs to occur.
- Svelte officially releases container query support (currently blocked on
css-treeNPM package not supporting CQ). - Re-test / assess the situation at that time as it could be a Svelte bug / issue, but one specific to Firefox.
Here is the independent test repo. Mind that my color picker component is on an unreleased dev branch and I yanked it out of the normal execution environment for isolation. IE it doesn't 100% look like the finished product in this test environment.
The top two color pickers are sharing a bound variable and the 2nd picker shows the defect when changing the width of the top / first picker from the slider just above:
- bound variable
- The third color picker is not using a bound variable and is not affected.
In the previous video demo the two color pickers exhibiting the unwanted behavior were using different bound variables, but in the test environment I bound the same variable.
You won't be able to build my test repo as it requires unreleased versions of my UI framework. I locally npm linked them when I built the test case.
However you can install things as I checked in the built assets.
- npm install
- npm run serve
- open localhost:8080
This is the isolated test case w/ my custom build of Svelte supporting container queries + a complex component w/ a lot of CQ usage that shows either a Svelte or Firefox bug relating to CQ / shared style leaking. Triggered by the component having a bound variable in Svelte.
|
|
||
Comment 8•1 year ago
|
||
The severity field is not set for this bug.
:tlouw, could you have a look please?
For more information, please visit auto_nag documentation.
I just tested the above demo again in FF nightly 111.0a1 (2023-01-25) and the issue is still present.
|
||
Comment 10•1 year ago
|
||
I tried the demo in a VM as well (cloned from repo https://github.com/typhonjs-fvtt-scratch/firefox-cq-test , ran npm commands from comment 6), and I can reproduce the issue.
|
Reporter | |
Comment 11•1 year ago
|
||
Thanks for taking a look / confirming Daniel. Just as a note, I'm submitting a PR this weekend to Svelte to add container query support. The rough expectation is that there will be a new version of Svelte out around the time of FF v110 / ~Feb 14th. It will be much easier at that point to produce a minimal test case in the Svelte REPL or otherwise. I'll certainly make an update when that is available.
Description
•