1986388 - Demo on https://codepen.io/netsi1964/pen/wBaOrez spends 22s around T-F on content-process, and 8s in parent-process

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Mayank Bansal]

Attachment: d3.txt

1. Go to https://codepen.io/netsi1964/pen/wBaOrez
2. In the box that says "Text to highlight (whole words)" , copy-paste the attached sample text
3. Scroll down to the very bottom of the page.
4. Click on "Open link in new tab" and measure the timing.

Firefox: https://share.firefox.dev/3JKJ2oO / https://share.firefox.dev/4lTIk6c(22s on content-process, 6s+2s on parent-process)
Chrome: instant-ish probably because chrome does not support T-F generally?

Lots of time spent in content-process. Also lots of time spent on the parent-process, which should be improved.

Comment 1

[Mayank Bansal]

Attachment: bandicam 2025-09-02 11-36-47-054.mp4

Comment 2

[Jan Jaeschke [:jjaschke]]

Thanks for the report! Note that this is about finding a text fragment in a page, not creating one from a page. This code does not have a timeout. This is an unsolved issue (across browsers; I had Chrome/Safari spend 15 minutes on certain text fragment links).

This is a very artificial test case, text fragment links will presumably be created from Browsers in >99% of cases. This text fragment doesn't match anything on the page, and it is using exact matching (of 500+kB of text) instead of range-based matching.

What makes me wonder though, obviously the d3 JS code isn't present in the target page, so the find algorithm should finish much more quickly. Maybe there's something worth tweaking here, so I'll keep it open.

Comment 3

[Mayank Bansal]

Anything interesting on the parent-process, or is that a necko question?

Comment 4

[Jan Jaeschke [:jjaschke]]

From a short look I think having a URL which is hundreds of kilobytes long is pushing the boundaries of the URL parser. Whether that's worth fixing, I don't know. That's a Necko question :)