Open https://nodejs.org/docs/latest-v20.x/api/os.html#ostmpdir isn't rendered initially
Categories
(Core :: Layout, defect, P2)
Tracking
()
People
(Reporter: hiro, Assigned: fredw)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(6 files, 5 obsolete files)
319 bytes,
text/html
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
STR;
- Open https://nodejs.org/docs/latest-v20.x/api/os.html#ostmpdir in a new tab
The contents are not fully rendered properly. If you do scroll or select some text there, it will reveal the contents.
Comment 1•3 months ago
|
||
:fredw, since you are the author of the regressor, bug 1807253, could you take a look?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Updated•3 months ago
|
Comment 2•3 months ago
|
||
[Tracking Requested - why for this release]: rendering regression from feature shipping in 124
Updated•3 months ago
|
Assignee | ||
Comment 3•3 months ago
|
||
I can reproduce with a trunk build. Attached is a testcase minimized with lithium. Bug disappears if content-visibility flag is turn off.
Assignee | ||
Comment 4•3 months ago
|
||
So per the spec these content-visibility: auto
elements should only turn out size containment when they "skip their contents". In that they would use the specified contain-intrinsic-height
(rather than sizing as if empty).
I'm assuming the #target thing should reveal div "2" making it take a small size. Then as a consequence of it, the same would happen for its siblings making everything visible.
However, checking the inspector when the bug happens, 1-2-3 actually have a non-zero small height (like if it they would skip their content?) and 4 has 5000px height (like if it would skip its content?). But the page is scrolled to the bottom with div 4 taking all the viewport size, hence showing no text.
Updated•3 months ago
|
Comment 5•3 months ago
|
||
The bug is marked as tracked for firefox124 (beta) and tracked for firefox125 (nightly). However, the bug still isn't assigned.
:fgriffith, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Comment 6•3 months ago
|
||
So do we have a way forward for a fix, are we considering backing out the regressor, or do we turn off content-vis by default until we have a solution?
Assignee | ||
Comment 7•3 months ago
|
||
(In reply to Frank Griffith Jr from comment #6)
So do we have a way forward for a fix, are we considering backing out the regressor, or do we turn off content-vis by default until we have a solution?
I'm not clear what's the regressor is but backing out the multiple content-visibility patches will likely be tricky, so turning off will likely be the easiest work around.
(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #5)
The bug is marked as tracked for firefox124 (beta) and tracked for firefox125 (nightly). However, the bug still isn't assigned.
Assigning myself, as I plan to investigate more.
Assignee | ||
Comment 8•3 months ago
|
||
I just checked a bit what's happening with attachment 9381018 [details] when the bug happens.
Placing some loggings in PresShell::ProximityToViewportResult PresShell::DetermineProximityToViewport()
one can see the function is repeated indefinitely and the proximities of content-visibility: auto
divs don't stabilize:
- At one call last div is close to viewport and the others far from it.
- At the next call last div is far from viewport and the others close to it.
- At the next call last div is close to viewport and the others far from it.
- etc
Checking nsRefreshDriver::Tick
, we actually don't stop ticking, the reason is always eHasObservers | eNeedsToNotifyResizeObserver
. We actually don't have resize observers on the page but this is happening because of our "last remember size" observer for the contain-intrinsic-height
node (see backtrace below). emilio mentioned in the past we can probably get rid of that observer and handle this stuff directly when determining proximity to the viewport (see bug 1807253 comment 39) so that's probably what we should do to avoid this kind of subtle issues...
#0 0x00007f0b9f31efc1 in nsRefreshDriver::EnsureResizeObserverUpdateHappens() (this=0x7f0b8bf3ea00) at layout/base/nsRefreshDriver.h:426
#1 0x00007f0b9f2c3ecf in mozilla::dom::Document::ScheduleResizeObserversNotification() const (this=0x7f0bb35eb300) at dom/base/Document.cpp:17137
#2 0x00007f0b9f3d7e23 in mozilla::dom::ResizeObserver::Observe(mozilla::dom::Element&, mozilla::dom::ResizeObserverOptions const&) (this=0x7f0b8bff4820, aTarget=..., aOptions=...) at dom/base/ResizeObserver.cpp:317
#3 0x00007f0b9f2c1a27 in mozilla::dom::Document::ObserveForLastRememberedSize(mozilla::dom::Element&) (this=0x7f0bb35eb300, aElement=...) at dom/base/Document.cpp:16450
#4 0x00007f0ba379d8cc in nsIFrame::HandleLastRememberedSize() (this=0x7f0b9038c3a8) at layout/generic/nsIFrame.cpp:1422
#5 0x00007f0ba37ad194 in nsIFrame::UpdateIsRelevantContent(mozilla::EnumSet<mozilla::ContentRelevancyReason, unsigned char> const&) (this=0x7f0b9038c3a8, aRelevancyToUpdate=const nsIFrame::ContentRelevancy & = {...}) at layout/generic/nsIFrame.cpp:7159
#6 0x00007f0ba35dc5bc in mozilla::PresShell::DetermineProximityToViewport() (this=0x7f0b8ac04000) at layout/base/PresShell.cpp:12176
#7 0x00007f0b9f2c3f54 in mozilla::dom::Document::DetermineProximityToViewportAndNotifyResizeObservers() (this=0x7f0bb35eb300) at dom/base/Document.cpp:17168
#8 0x00007f0ba358470a in nsRefreshDriver::DetermineProximityToViewportAndNotifyResizeObservers() (this=0x7f0b8bf3ea00) at layout/base/nsRefreshDriver.cpp:2278
#9 0x00007f0ba35837a6 in nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsRefreshDriver::IsExtraTick) (this=0x7f0b8bf3ea00, aId=..., aNowTime=..., aIsExtraTick=nsRefreshDriver::IsExtraTick::No)
at layout/base/nsRefreshDriver.cpp:2770
Assignee | ||
Comment 9•3 months ago
|
||
This reduces testcase a bit more, using scrollIntoView()
to scroll to the target instead of clicking a link a forcing a reload.
Assignee | ||
Comment 10•3 months ago
|
||
Comment 11•3 months ago
|
||
Comment 12•3 months ago
|
||
Thanks Fred. So I posted comment 11 which is in line with what I meant bug 1807253 comment 39. I confirmed that fixes the rendering of the test-case.
The thing that's missing is for DetermineProximityToViewport (which should probably be renamed) to also clear stale remembered sizes for things that no longer have frames, which is a bit of work but hopefully straight-forward? I think PresShell can keep a list of weak refs to elements that call UnregisterContentVisibilityAutoFrame
. For every element in that list which doesn't have a content visibility auto frame we just clear the last remembered size.
If you don't have the cycles to do that I'm happy to give it a poke.
Assignee | ||
Comment 13•3 months ago
|
||
Thanks Emilio, I can confirm my WPT tests and all the testcases work properly with your patches.
From https://drafts.csswg.org/css-sizing-4/#last-remembered the last remembered size is updated "At the time that ResizeObserver events are determined and delivered" which is now done at step 15 of https://html.spec.whatwg.org/#event-loop-processing-model so that's indeed consistent with the suggestion to move things to DetermineProximityToViewportAndNotifyResizeObservers()
.
Note that the function exits early if the document has neither resize observers nor content-visibility: auto
frames per https://searchfox.org/mozilla-central/rev/a8cc31504a2379bcf8ba395d2da7bb632b5521d6/layout/base/nsRefreshDriver.cpp#2266 ; which means removing the last remember size observer may cause it to be executed less often.
@Oriol: Since you worked on the last remember size stuff, do you think there is any other cases we should consider too?
Assignee | ||
Comment 14•3 months ago
|
||
Essentially reverting D154324 since we no longer need it to accept
internal callback functions.
Assignee | ||
Comment 15•3 months ago
|
||
Sent current patchset to try server and there are many failures: https://treeherder.mozilla.org/jobs?repo=try&revision=b51383897a2af77eb67890512316c378915a48fc
Assignee | ||
Comment 16•3 months ago
|
||
Assignee | ||
Comment 17•3 months ago
|
||
For content-visibility: auto
nodes that are relevant to the user,
make sure their recorded "last remembered sizes" is up-to-date so that
the proximity to the viewport can be properly determined.
This change is covered by tests added in D202403.
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Assignee | ||
Comment 18•3 months ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #13)
Thanks Emilio, I can confirm my WPT tests and all the testcases work properly with your patches.
Same here with the latest patchset.
Note that the function exits early if the document has neither resize observers nor
content-visibility: auto
frames per https://searchfox.org/mozilla-central/rev/a8cc31504a2379bcf8ba395d2da7bb632b5521d6/layout/base/nsRefreshDriver.cpp#2266 ; which means removing the last remember size observer may cause it to be executed less often.
OK, so as discussed on D202424 we also need to handle last remembered size updates for other nodes, not just content-visibility: auto
nodes. So D202571 removes the internal resize observer and should be more correct. D202731 contains the actual fix from Emilio's original patch: update the last remembered sizes of some content-visibility: auto nodes before determining the proximity to viewport.
(In reply to Frédéric Wang (:fredw) from comment #15)
Sent current patchset to try server and there are many failures: https://treeherder.mozilla.org/jobs?repo=try&revision=b51383897a2af77eb67890512316c378915a48fc
I'm getting better results locally with the new patch set. I sent them to try: https://treeherder.mozilla.org/jobs?repo=try&revision=4832c3a3f89c3657141a9c62412b8e6cd170d18e
Updated•3 months ago
|
Comment hidden (spam) |
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Assignee | ||
Comment 20•3 months ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #8)
Checking
nsRefreshDriver::Tick
, we actually don't stop ticking, the reason is alwayseHasObservers | eNeedsToNotifyResizeObserver
. We actually don't have resize observers on the page but this is happening because of our "last remember size" observer for thecontain-intrinsic-height
node (see backtrace below). emilio mentioned in the past we can probably get rid of that observer and handle this stuff directly when determining proximity to the viewport (see bug 1807253 comment 39) so that's probably what we should do to avoid this kind of subtle issues...
So another subtle thing is that content-visibility: auto
forces contain-intrinsic-height
to gain auto
per https://searchfox.org/mozilla-central/rev/9cd4ea81e27db6b767f1d9bbbcf47da238dd64fa/servo/components/style/style_adjuster.rs#536 ; this is why we ever use a "last remember size" even if auto is not explicit in the reduced testcases. The original testcase at https://nodejs.org/docs/latest-v20.x/api/assets/style.css really uses an explicit auto though:
#apicontent section {
content-visibility: auto;
contain-intrinsic-size: 1px auto 5000px;
}
Backtrace:
(rr) rc
thread 1 hit Hardware watchpoint 2: -location mContainIntrinsicHeight
Old value = mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength> {tag: mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength>::Tag::AutoLength, : {length: mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength>::StyleLength_Body {_0: mozilla::StyleCSSPixelLength {_0: 5000}}, auto_length: mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength>::StyleAutoLength_Body {_0: mozilla::StyleCSSPixelLength {_0: 5000}}}}
New value = mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength> {tag: mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength>::Tag::Length, : {length: mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength>::StyleLength_Body {_0: mozilla::StyleCSSPixelLength {_0: 5000}}, auto_length: mozilla::StyleGenericContainIntrinsicSize<mozilla::StyleCSSPixelLength>::StyleAutoLength_Body {_0: mozilla::StyleCSSPixelLength {_0: 5000}}}}
0x00007ff0d07d9679 in style::properties::generated::gecko::GeckoPosition::set_contain_intrinsic_height (self=0x7ff0b4387bb8, v=...) at obj-x86_64-pc-linux-gnu-release/x86_64-unknown-linux-gnu/release/build/style-f050414487bf3194/out/gecko_properties.rs:3518
3518 self.mContainIntrinsicHeight = From::from(v);
(rr) bt
#0 0x00007ff0d07d9679 in style::properties::generated::gecko::GeckoPosition::set_contain_intrinsic_height (self=0x7ff0b4387bb8, v=...)
at obj-x86_64-pc-linux-gnu-release/x86_64-unknown-linux-gnu/release/build/style-f050414487bf3194/out/gecko_properties.rs:3518
#1 0x00007ff0d037aa68 in style::style_adjuster::StyleAdjuster::adjust_for_contain_intrinsic_size (self=0x7fffa1a02da0) at servo/components/style/style_adjuster.rs:558
Updated•3 months ago
|
Assignee | ||
Comment 21•3 months ago
|
||
This is doing the same as D202731 but keeping the ResizeObserver-based
implementation of last remembered sizes.
This change is covered by tests added in D202403.
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Comment 22•3 months ago
|
||
This reverts D198689.
Comment 23•3 months ago
|
||
Pushed by fwang@igalia.com: https://hg.mozilla.org/integration/autoland/rev/467f563c9ea5 Add tests for content-visibility update with contain-intrinsic-size. r=cathiechen https://hg.mozilla.org/integration/autoland/rev/3508e2bd4e3c Remove last remembered size observer, handle it in Document::DetermineProximityToViewportAndNotifyResizeObservers. r=emilio,layout-reviewers https://hg.mozilla.org/integration/autoland/rev/e01ba93d881f Update some "last remembered sizes" before determining proximity to the viewport. r=emilio,layout-reviewers https://hg.mozilla.org/integration/autoland/rev/dfad870b0c8e Make ResizeObserver::mCallback a ResizeObserverCallback again. r=Oriol
Assignee | ||
Comment 24•3 months ago
|
||
This is doing the same as D202731 but keeping the ResizeObserver-based
implementation of last remembered sizes.
It also imports the tests from D202403.
Original Revision: https://phabricator.services.mozilla.com/D202926
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Assignee | ||
Comment 25•3 months ago
|
||
@emilio: I uploaded two alternatives patches for beta: either disable the feature completely or apply a similar fix without the lastremeberedsize refactoring. Please tell me what you think.
Comment 26•3 months ago
|
||
Uplift Approval Request
- String changes made/needed: None
- Explanation of risk level: This is just moving when the internal ResizeObservervation for last remembered size is broadcast before determination of "proximity to viewport" for
content-visibility: auto
nodes, rather than after so should have minimal behavior. It is sligthly different from the (more complex) nightly patches and has only been tested locally, so we might prefer D203093 instead. - Fix verified in Nightly: no
- Risk associated with taking this patch: Medium
- Needs manual QE test: no
- User impact if declined: This may be causing a blank rendering for a quite likely use case on modern website (several
content-visibility: auto
sections with acontain-intrinsic-size
to optimize performance). - Is Android affected?: yes
- Steps to reproduce for manual QE testing: n/a
- Code covered by automated testing: yes
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44851 for changes under testing/web-platform/tests
Comment 28•3 months ago
|
||
Uplift Approval Request
- Is Android affected?: yes
- Code covered by automated testing: no
- Steps to reproduce for manual QE testing: Open attachment 9381952 [details]. It should not remain blank until you start interacting with the page.
- User impact if declined: This may be causing a blank rendering for a quite likely use case on modern website (several
content-visibility: auto
sections with acontain-intrinsic-size
to optimize performance). - String changes made/needed: None
- Explanation of risk level: This is just turning off content-visibility, which has not been shipped yet in release. We might prefer D203094 which fixes the bug and adds automated tests to verify it.
- Risk associated with taking this patch: Low
- Needs manual QE test: yes
- Fix verified in Nightly: no
Assignee | ||
Comment 29•3 months ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #25)
@emilio: I uploaded two alternatives patches for beta: either disable the feature completely or apply a similar fix without the lastremeberedsize refactoring. Please tell me what you think.
Was supposed to be for emilio@crisal.io ; but answer is https://phabricator.services.mozilla.com/D203094#6968520
I guess that's fine and the safest option to delay content-visibility again.
Comment 30•3 months ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Updated•3 months ago
|
Comment 32•3 months ago
|
||
Comment on attachment 9388327 [details]
Bug 1880928 - Update some "last remembered sizes" before determining proximity to the viewport.
It was decided to disable content-visibility in 124 beta rather than uplift this patch. It remains enabled for 125.
Comment 33•3 months ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/d64810040b0f
Updated•3 months ago
|
Comment 34•3 months ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/f069a175c6e0
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Comment 35•3 months ago
|
||
Reproduced this issue on an affected Nightly build from 2024-02-19, on Windows 10.
Verified as fixed on 125.a1 (20240305094850) on the following platforms: Win 10, Win 11, Ubuntu 22 and macOS 11.
Description
•