`content-visibility: auto` breaks Text Fragments directives
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: myf, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
305.42 KB,
video/mp4
|
Details |
STR
data:text/html,<p style="content-visibility: auto;">xx#:~:text=xx
Expected
xx highlighted
Actual
No highlight.
WPT
Presumably content-visibility-auto-text-fragment (results).
Notes
- STR surprisingly fails even when the content is actually in the initial viewport, i.e. it is not even needed to push the content out to reproduce.
- Regular anchor is OK, even in
content-visibility: autoblock far away from the viewport (data:text/html,<hr style="margin-block: 300vh;"><p id="xx" style="content-visibility: auto;">OK#xx). - Stumbled upon this via https://x.com/hypeddev/status/1897599755041050697 that uses link:
https://infrequently.org/#:~:text=React's%20synthetic%20event%20system%20and%20hard-coded%20element%20list%20are%20a%20direct%20consequence%20of%20IE's%20limitations.%20
What addresses content from a "footnotes" block that has content-visibility: auto applied.
|
Reporter | |
Updated•10 months ago
|
|
||
Comment 1•10 months ago
|
||
I can repro the second and third example, but not the first one.
Thanks for pointing me to the WPT, I wasn't aware that there was one for text fragments there. Since it fails, there's definitely a bug. I'll take a look, thank you for reporting!
|
|
Reporter | |
Comment 2•10 months ago
|
||
[cannot repro the first example]
Whoa, now I got the ..xx#:~:text=xx highlight working too, for the firsts time actually (I swear! :]). But after reload, or re-try in blank tab, it is broken again. Kept Alt+D Alt+Entering, and Middle Clicking the reload button and received the highlight in about 10 % loads. (So it seems it's the worst-case scenario: stochastic race condition.)
can repro the second
the ..OK#xx was just to check the jump (not highlight) and show the jump-to-id works, that was not expected to fail …?
|
|
||
Comment 3•10 months ago
|
||
the ..OK#xx was just to check the jump (not highlight) and show the jump-to-id works, that was not expected to fail …?
Oops. :) I misread and thought there'd be a text fragment as well.
|
|
Reporter | |
Comment 4•10 months ago
|
||
I see :] I probably should have been more clear there is actually only one test here.
Anyway, the only scenario when I get highlight on my machine is to navigate to STR, re-paste the URL, and enter it for the second time. Then I get the highlight every time. (Normal reload does not do this trick for me.)
Same applies to slightly amended STR that still keeps the fragment in the viewport:
data:text/html,<hr style="margin-block: 10vh;"><p style="content-visibility: auto;">inView#:~:text=inView
But moving the tested fragment out of the viewport does not get "fixed" by the "re-paste", i.e. I never got the highlight here:
data:text/html,<hr style="margin-block: 100vh;"><p style="content-visibility: auto;">outView#:~:text=outView
|
|
Reporter | |
Comment 5•10 months ago
|
||
Adding screen recording of 1 minute of various loading of
data:text/html,<html style=color-scheme:dark;content-visibility:auto>xx#:~:text=xx
- added dark scheme just because night,
- and applied content-visibility on HTML directly, what is most probably terrible idea for real usage.
- Initial load into blank tab (this first load this time did not produce fragment highlight),
- then did few reloads with the reload button, around fifth try got the highlight.
- Then cuts and pastes in URL bar, getting highlight on each try. (Keys are not shown, so it's not clear, what is going on.)
- Then reloads with Ctrl+R, got highlight on about fifth try again,
- and finally did middle clicks on the reload button, got highlight on third try.
Overall, except for re-paste and enter, got highlight in less than half tries, I guess.
This time on Latest Firefox Nightly 138.0a1 build 20250307090837 on Windows 10 19045.
Description
•