Text-Fragments: Make use of timeout on JS side
Categories
(Firefox :: Menus, task)
Tracking
()
People
(Reporter: jjaschke, Assigned: jjaschke)
References
(Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
In rare occasions creating a text fragment can take a considerable amount of time. The new backend implementation (Bug 1957557) speeds up the process to create a single text directive. However, there are situations where the selection on the page consists of multiple ranges, which means invoking the backend algorithm several times. In extreme cases (such as going to html.spec.whatwg.org and doing CTRL-A) there can be thousands of ranges, which would block the main thread for minutes, even if finding a single text directive only takes a few hundred milliseconds or less.
Therefore, the existing timeout should also be used in the JS code and abort the operation if necessary.
| Assignee | ||
Comment 1•1 year ago
|
||
In rare situations, the user could request
creating lots of text fragments for a page.
The existing timeout could fail in that case,
because the individual calls to create a
text fragment are fast, but the accumulated
time is larger than the timeout.
This patch checks for the timeout on the
JS side as well, aborting the operation if the
total accumulated time exceeds the timeout
(currently 5 seconds).
| Assignee | ||
Comment 2•1 year ago
|
||
Ah, nevermind. Profiling showed that performance should be better if I change the API to take the Selection itself, or a list of ranges (instead of only one). I'll do that in a new bug.
Updated•1 year ago
|
Description
•