Open Bug 1729633 Opened 3 years ago Updated 16 days ago

Highlights in the scrollbar are incorrectly shown and constantly updated when searching within a large document

Categories

(Core :: Graphics: WebRender, defect)

defect

Tracking

()

People

(Reporter: whimboo, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: power)

With bug 1725555 fixed and being able to quickly iterate through found search items in a large document, I can see that the highlights as shown in the scrollbar are getting invalidated and updated in a constant manner even with the search term not changing at all.

Steps to reproduce:

  1. Open https://community.taskcluster-artifacts.net/It905wBLQGOFhFaIUiURXA/0/public/logs/live_backing.log
  2. Search for ok and enable Highlight all
  3. Quickly step through the found results by clicking the up and down arrows

After step 2 you will notice that the highlight is only visible for the first around 5% of search results. Means the scrollbar shows only a small purple section at the top but stays normal for all the rest. When scrolling down to the middle of the document there are still items highlighted in the document but not in the scrollbar.

Also with step 3 you can see that the highlights in the scrollbar are getting invalidated and redrawn on a constant manner.

Even with a single click onto one of the arrows the CPU load of the content process directly climbs up to 100% and stays there for a long time.

Here a recorded Gecko profile: https://share.firefox.dev/3l5v7JX

Maybe better to move to WebRender first given that this has the biggest impact in the recorded Gecko profile.

Component: Find Toolbar → Graphics: WebRender
Product: Toolkit → Core

Searching for ok and asking for Highlight All in that document is a pretty extreme case -- there are 85K+ occurrences. I don't know how the scrollbar highlights are implemented but my suspicion is that we basically create an element for each mark to be drawn, and trying to handle 85K of them is pretty overwhelming.

Searching for something like "test_end" (800+ occurrences) may be a more typical scenario; then repeatedly clicking the Next/Previous arrows doesn't bring the browser to its knees to the same extent, but it does still show quite sluggish performance updating the scrollbar highlights -- especially visible if you use the Find Again keyboard shortcut to rapidly skip through the results. The scrollbar highlights are repeatedly repainted (unnecessarily) with a lot of visible lag.

https://searchfox.org/mozilla-central/rev/aa46c2dcccbc6fd4265edca05d3d00cccdfc97b9/layout/xul/nsSliderFrame.cpp#386

we add a display item for every search result it looks like. Maybe we should limit the number of scrollmarks we display or store or something.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.