1663411 - Find if slow on HTML spec when trying to find string 'entry update'

Status: VERIFIED FIXED

(Core :: Find Backend, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Load https://html.spec.whatwg.org
Open Find and try: entry update

Apparently this is a regression

Comment 1

[Emilio Cobos Álvarez (:emilio)]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6e14cc79a42dcaf6774fe728dd745134435e44af&tochange=aa337bc4d6693ad1d25236229eb982ebe468e138

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1663411 - Improve the speed of find-in-page when ending a pseudo-element mid-match. r=jfkthame

So what's going on here is that there are pseudo-elements that contain
stuff like content: "Note" or content: "Example".

So when you're searching for "entry", we find the e, and then all the
text nodes afterwards are of course in a different subtree... So we end
up ignoring them, but after having iterated through all the DOM first.

To avoid this, change a bit the code so that we check for different
blocks before checking for different subtrees. There's no point to
keep matching once you're done with a block.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1654270

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b0674d532cab
Improve the speed of find-in-page when ending a pseudo-element mid-match. r=jfkthame

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/b0674d532cab

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9174199 [details]
Bug 1663411 - Improve the speed of find-in-page when ending a pseudo-element mid-match. r=jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: Find-in-page can be very slow in some cases.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): I wouldn't say it's fully risk-free, but it seems like a nice, easy-ish perf win and this code is relatively well tested.
• String changes made/needed: none

Comment 7

[Simona Badau, Desktop QA]

Verified as fixed using the latest Nightly 82.0a1 (Build ID: 20200908215255) on Mac OS X 10.15, Windows 10 x64, and Ubuntu 18.04 X64 - the string "entry update" is properly found.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9174199 [details]
Bug 1663411 - Improve the speed of find-in-page when ending a pseudo-element mid-match. r=jfkthame

Given that this isn't a new problem, we're about to build our final beta of the cycle, and this doesn't appear to be a widespread issue, I think it would be better to let this ride the trains. Feel free to yell if you strongly disagree.

Comment 9

[Simona Badau, Desktop QA]

Considering Comment 8, removing qe-verify+ flag and [qa-triaged] whiteboard.