User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

1. Navigate to https://github.com/MaoJianwei/eAIP-2015-Nr.13/blob/master/Download_eAIP_2015_Nr.13.py
2. Scroll down

Actual results:

The webpage initial loading will take a long time. And, after loaded, scroll down the page, then the page content will leave blank below some position of the page. When the page freezes, key bindings (like arrow keys) won't work.

Expected results:

The page shouldn't freeze so much.

Tested Firefox versions: 120.0.1 and 122.0a1.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Additional info
Chromium 119.0.6045.199 handles this better. Seems that horizontal content isn't lazy-loaded?

Something odd happening with style handling
https://share.firefox.dev/4a7AAc8
https://share.firefox.dev/3RtLK3F

https://share.firefox.dev/41oBE7D with sequential styling. It seems there's a range of siblings where revalidating selectors takes most of the time, which shouldn't happen, ideally...

Ok, so the invalidation machinery could improve, will file a separate bug about that. But having improved the revalidation stuff and trying to improve some other bits and pieces, I realized that there's something clearly different between Chromium and Firefox on that page. In Firefox, document.querySelectorAll("*").length is 829448.

In Chrome, same window size, also logged out, scrolled to the top, etc, I get 1556. So something Github is doing is clearly not working out, and they're giving us a massive DOM to work with which they don't give other browsers...

I filed https://github.com/orgs/community/discussions/77953 about this. Will file a bug about improving revalidation to bucket by attribute.

Safari also gets the "good" version.

https://github.blog/2023-06-21-crafting-a-better-faster-code-view/#css if you read below this section, the para starting "Our second attempt..." you can see that each letter in a span needs to be separated to work around Firefox text selection issues. There is code to check if the UA string includes firefox which then changes the rendering strategy of Syntax highlighted code to render these individual spans. You can observe the behaviour without this strategy by switching UA string.

With text selection issues you mean that you can find ::before pseudos? Or something else?

Sorry yes that's correct.

I mean that's a feature, generally...

Why is that an issue? I guess you don't want the two texts (the underlying textarea contents, and the ::before pseudo) to be selected when you use find in page? Or is it deeper than that? (e.g window.find returning odd stuff or what not)

https://searchfox.org/mozilla-central/rev/648a427a0ffc4c62118dbb24bcd88a6b52f54d78/toolkit/components/find/nsFind.cpp#163 is the relevant code.

Maybe we should add some sort of control over the findability of text... Something like user-find (akin to user-select and such)? But I want to understand the issue first.

An example of this being useful is being able to Ctrl+F for line numbers in searchfox :)

Your assumption about not wanting two texts returned in the find is correct. That is the reason we split each character into it's own element.

We do have some worked planned to help cut down on the number of nodes rendered for Firefox but it won't bring it inline with other browsers.

That said, having a control over the findability of text would be fantastic and would eliminate the problem altogether.

Okay, I filed https://github.com/w3c/csswg-drafts/issues/9726 about this and then realized that there was https://github.com/w3c/csswg-drafts/issues/3460 on file with more discussion. I added a concrete proposal there and added it to the working group's agenda.

Even with bug 1868399 in place, this is still janky, so let's hope that GitHub responds. Edit: I just now noticed that Cody clearly works at GitHub. Sorry for missing that. :)

Nightly-only for now waiting on CSSWG discussion.

https://hg.mozilla.org/mozilla-central/rev/6fdde7dce003
https://hg.mozilla.org/mozilla-central/rev/90d84a362f05

Ok, so the working group didn't love the user-find proposal, but chatting a little bit more, inert should prevent searchability: https://html.spec.whatwg.org/#inert-subtrees

I think browsers disregard the last bullet point, but I think that's wrong. If we fixed, that, could you use the inert attribute?

(We also talked about the custom highlight API being a potentially better approach for your virtualization, but that's obviously more effort :))

As per the HTML spec.

Thanks for the update! It's a bit disappointing about user-find discussion but I read through the IRC log and understand their reasoning.

As for inert, I'll need to do some checking to see how that would look / act on our end and get back to you. That's a promising idea though!

If it works as expected, I think our only roadblock will be detecting that inert is now preventing find so we can change the rendering strategy. I assume the simplest approach there would be checking the UA for whatever version the potential inert fix landed in.

How can we set inert to ::before pseudos?

You'd set the inert attribute on their source code container (but not on the line numbers because those are hittable).

I checked and GitHub is already hiding it from pointer events and a11y, so inert kinda does all that for you.

(In reply to Cody Bodfield from comment #26)

As for inert, I'll need to do some checking to see how that would look / act on our end and get back to you. That's a promising idea though!

Yeah I think it should be a relatively low effort fix. I was poking at your DOM and just applying it to the aria-hidden div where you stash the code should do...

If it works as expected, I think our only roadblock will be detecting that inert is now preventing find so we can change the rendering strategy. I assume the simplest approach there would be checking the UA for whatever version the potential inert fix landed in.

Yeah, I think that sounds about right, unfortunately. You could do proper feature detection with an iframe and window.find(), see the test I added to the patch, but it's a bit of a heavyweight check.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #24)

(We also talked about the custom highlight API being a potentially better approach for your virtualization, but that's obviously more effort :))

As an FYI, here’s a POC of that: https://codepen.io/bramus/full/VwRqGVo

This most likely comes with its own challenges, as you no longer have actual elements to hook things such as “an overlay on hover” on.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #29)

Yeah I think it should be a relatively low effort fix. I was poking at your DOM and just applying it to the aria-hidden div where you stash the code should do...

Agreed! I just needed to spot check to make sure there weren't any other gotchas on our end. I'll have a change out to add inert attribute early next week.

Yeah, I think that sounds about right, unfortunately. You could do proper feature detection with an iframe and window.find(), see the test I added to the patch, but it's a bit of a heavyweight check.

Unfortunately the iframe check will be too heavy-weight for us so we should stick with the UA. Is there a recommended way to target Firefox Nightly UA versions or is there a Firefox version you'd like to target this fix to?

Assuming the patch sticks, it should make it into Firefox 124.

https://hg.mozilla.org/mozilla-central/rev/4eab1cec8f07

I changed the summary so this bug will be easier to find.