Thank you for the review. Changes since the diff you read:

@emilio Updated after the Speedometer 3 runs; the numbers, before and after, and the try runs are in comment 46.

Try results for the stack, three pushes on one base, are in bug 1117079 comment 6.

Try results for the stack, three pushes on one base, are in bug 1117079 comment 6.

Rebased onto current main.

Rebased onto current main. The test setup now waits for the whole word's highlight before counting the ranges.

The try runs for the tests, and a page that shows seven cases side by side without and with the patch, are in bug 479829 comment 45.

In D324918#11309998, @emilio wrote:

In D324918#11304628, @r.majdodin wrote:

The user-facing benefit is that the fix from bug 1566783 works on the loads where today it does not.

Sure. But only on iframes right?

Re-submitted after the backout. The only change since the r+ is in the test: it
waits for the find bar to finish opening before moving focus to the page, since
outside macOS the find field is focused again when the page selection arrives.

The user-facing benefit is that the fix from bug 1566783 works on the loads where today it does not. That fix has ScrollToAnchor() put the fragment target back at the top at load end after late-loading content above it moved the page, unless the scroll position changed since GoToAnchor() recorded it, which would mean the user scrolled. When GoToAnchor()'s own scroll was deferred, because the flush it asked for could not run, the position it recorded is the one from before the scroll, so the check fails on every such load and the target ends one image height above the viewport, showing whatever sits below it (comment 51 on the bug has dholbert's trace).

Try, from the tree at 0d44a1298c7e:

@mstriemer thank you for the review and for applying the testing tag.

@bolsson thanks for the review.

@mossop — a scheduling problem with the routing: NeilDeakin is blocking on this and on D317720, but his Bugzilla profile reads "away until Sept 6" and his last activity there was Aug 13. That lands well after the 156 merge on Aug 27, which is what I am aiming for (therefore I had added firefox-desktop-core-reviewers ).

Also in this update: testScrollMarksRefreshedAfterRescan now waits for the specific post-rescan scroll-mark event rather than the next one to arrive, drops a fixed 1000 ms wait, and turns mark testing back off at the end.

Also in this update: the test's file-level eslint-disable for no-arbitrary-setTimeout is narrowed to the one line that needs it.

Adding firefox-desktop-core-reviewers - mots lists Desktop Firefox as the owning module for toolkit/**. Widening so this is not blocked on a single reviewer before the 156 merge on Aug 27.

jules is on leave - he noted on D314529 (Aug 13) that mstriemer is covering during his time off - so swapping him for mstriemer as blocking reviewer. mstriemer is also the owner of the UI Widgets module in mots (toolkit/content/widgets/**), which this patch touches. Also adding firefox-desktop-core-reviewers for the toolkit/modules changes. Aiming for the 156 merge on Aug 27.

Thanks for the review.

Fix eslint consistent-return: explicit 'return undefined;' on the no-params early exit in FinderIterator.restart().

The obvious version of this — recompute the marks when the restart
notification fires, after requestMatchesCount resolves — was tried
first and falsified live: it resolves about 2 ms after the restart,
before the re-iteration has repopulated the selection, so the marks
were re-derived from the stale range set. Chaining on the
range-collection promise fixed it: over repeated collapse, expand and
in-place-swap cycles the final marks write matched the fresh match
set every time.

Verification context, since I don't have a local build: I mirrored the
change onto Nightly 155 by hot-patching the module from a privileged
context and drove it on a purpose-built page (static baseline of 9
matches, with in-place text swaps and real node insertion/removal)
and on live sites.

Some context on how this was verified, since I don't have a local build: I mirrored the exact change onto Nightly 155 by hooking Finder.prototype.highlight from a privileged context, with logging on FinderHighlighter's setScrollMarks/removeScrollMarks/updateScrollMarks.

Both optional nits are in:

Both firefox.js items are applied: "for non-related links" is restored verbatim, and the exceptPinned condition now reads "next to a pinned tab".

All three items and the nits are applied.

Updated per the inline: the test's lifecycle is now explicit setup()/teardown(env) helpers called at the beginning and end of each task.

This extends the originAttributesToSuffix identity you pointed to in D315860 from the notification filter to the row key itself. #getCookieUniqueKey's last slot carried only the partitionKey, so in an everything-scope session two same-named cookies from different jars collapse into one row - delete then removes both jars' cookies and edit can land on a different jar than the row displays (bug 2061166 has the evidence, including a rendered-panel screenshot). The key's last slot becomes the full suffix - byte-identical for default-jar cookies - and editCookie()/_removeCookies() compare the same suffix when resolving a row. Verified live on Nightly 155.0a1: two rows, jar-exact edit and delete, and the panel renders them correctly.

Implementation folded into D315860 per the review (the complete-originAttributes comparison covers partitionKey); this revision now carries only the regression test.

Reworked as suggested: getMatchingHosts() now compares the cookie's originAttributes against every entry of getOriginAttributesListFromHost() via ChromeUtils.originAttributesToSuffix, filtering out the undefined entries. The helper extraction moved here from D315861, and since the complete-originAttributes comparison covers partitionKey, this patch now fixes bug 2060029 on the same path; D315861 keeps only the test. Also switched the oaKey computation to originAttributesToSuffix.

Notes for review: