1878504 - searching settings in linux is painfully slow

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect)

Description

[zlice]

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

Steps to reproduce:

• edit > settings (preferences)
• ctrl+f / search
• type

Actual results:

slow and laggy results

Expected results:

was snappy a few weeks ago

mozregression points to here. should be somewhere between jan 22 2024 and the 23rd

2024-02-03T11:41:47.361000: INFO : application_version: 124.0a1
2024-02-03T11:41:47.361000: INFO : platform_buildid: 20240123152526
2024-02-03T11:41:47.361000: INFO : platform_changeset: 1b7bb03e04052e19b817b44fc94f76ed13a165df
2024-02-03T11:41:47.361000: INFO : platform_repository: https://hg.mozilla.org/integration/autoland
2024-02-03T11:41:47.361000: INFO : platform_version: 124.0a1
2024-02-03T11:41:49.312000: INFO : b"[Parent 26604, Main Thread] WARNING: Error loading theme icon 'document-save' for stock: Icon 'document-save' not present in theme ultra-flat-orange: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:187"
2024-02-03T11:41:49.312000: INFO : b''
2024-02-03T11:41:49.314000: INFO : b"(firefox-nightly-autoland:26604): Gtk-WARNING **: 11:41:49.312: Error loading theme icon 'document-save' for stock: Icon 'document-save' not present in theme ultra-flat-orange"
2024-02-03T11:41:51.411000: INFO : Narrowed integration regression window from [84a4dd92, 20e975d7] (3 builds) to [1b7bb03e, 20e975d7] (2 builds) (~1 steps left)
2024-02-03T11:41:51.415000: DEBUG : Starting merge handling...
2024-02-03T11:41:51.415000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=20e975d790c813957b823a4418e599107ec2a097&full=1
2024-02-03T11:41:51.416000: DEBUG : redo: attempt 1/3
2024-02-03T11:41:51.416000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=20e975d790c813957b823a4418e599107ec2a097&full=1',), kwargs: {}, attempt #1
2024-02-03T11:41:51.418000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2024-02-03T11:41:52.350000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=20e975d790c813957b823a4418e599107ec2a097&full=1 HTTP/1.1" 200 None
2024-02-03T11:41:52.410000: DEBUG : Found commit message:
Bug 1872535: Deal with invalid `StaticRange`s and DOM mutations in `Selection`. r=smaug

Ranges inside of a `Selection` are expected to be sorted by their start point by the painting algorithms. Also, `StaticRange`s, which previously were not part of `Selection`, need to be considered for painting based on their `IsValid()` status.

This is now added by introducing a second array for invalid static ranges and an additional re-ordering method which needs to be called before paint that moves ranges in between.
 A potential change in range endpoints can be determined by observing the `Document`s generation and by adding a flag that's set to true in `Selection::NotifySelectionObservers()`.

Differential Revision: https://phabricator.services.mozilla.com/D198943

2024-02-03T11:41:52.410000: DEBUG : Did not find a branch, checking all integration branches
2024-02-03T11:41:52.411000: INFO : The bisection is done.
2024-02-03T11:41:52.412000: INFO : Stopped

Comment 1

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

:jjaschke, since you are the author of the regressor, bug 1872535, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

[Tracking Requested - why for this release]: Seems like this would affect a lot more than just settings.

Comment 3

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

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

Comment 4

[Jan Jaeschke [:jjaschke]]

Hi zlice,

thank you for your report, that's much appreciated!
I could reproduce the behavior on Linux, interestingly not (at least as noticable) on MacOS.
Here is a profile of the situation.

The ranges inside of a selection are expected to be sorted by their starting point. However, after a Selection Change or DOM Mutation, this ordering may have become invalid, which is problematic especially for StaticRanges. The regressing bug implemented a range reordering algorithm, which is triggered if the selection has changed (ie. when NotifySelectionListeners() is called), or when a DOM mutation has happened (which is being detected by caching the Document's "generation").

This bug resulted in AddRange() calling NotifySelectionListeners(), thereby invalidating the range order and forcing a reordering, even though AddRange() inserts the new range at the right position.

Comment 5

[Jan Jaeschke [:jjaschke]]

Attachment: Bug 1878504: Don't trigger range reordering when a range is added. r=smaug!,#dom-core

Ranges stored in Selection::StyledRanges are expected to be sorted by their start point.
In Bug 1872535 a range reordering was introduced which makes sure that static ranges are at the right spot after a DOM mutation has happened.
Reordering is necessary in two conditions:

• The document generation has changed (=There are changes to the DOM tree)
• A selection has changed (which would call NotfySelectionListeners())
  However, when a range is added, it is not necessary to reorder, since the AddRange...() method inserts the new range at the correct spot.

Comment 6

[Jan Jaeschke [:jjaschke]]

Here's a try run.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09758ac01303
Don't trigger range reordering when a range is added. r=smaug

Comment 8

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/09758ac01303

Comment 9

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue in Ubuntu 23.1 and Windows 10x64 by opening the Preferences page searching netw and then deleting it. The browser is very slow and even freezes sometimes on Windows.
The issue is verified fixed with Firefox 124.0b2 on Windows 10x64, macOS 13 and Ubuntu 23.1. Searching netw and other strings in the preferences page performs as before.
However, on one out of three Windows stations, I can still reproduce this issue or a similar one when searching and deleting the string inside the preferences page for the first time in a newly open session. I filled bug 1881695 for this and I will close this one since this happens only on one Windows 10 station.