1879084 - Entering searchmode via keyword in the address bar double highlights the keyword

Status: ASSIGNED

(Core :: DOM: Selection, defect, P2)

Description

[Ardelean Oana, Desktop QA [:oardelean]]

Attachment: test.png

Found in

• Firefox Nightly 124.0a1;

Affected versions

• Firefox Nightly 124.0a1;
• Firefox 123.0b7;
• Firefox 122.0.1;

Tested platforms

• Windows 10;
• Ubuntu 22;
• macOS 12;

Affected platforms

• Windows 10;

Unaffected platforms

• macOS 12;
• Ubuntu 22;

Steps to reproduce

1. Launch Firefox.
2. Focus the address bar and start typing a searchmode keyword, such as `@google’.

Expected result

• Keyword is properly highlighted.

Actual result

• Keyword is doubly highlighted.

Regression range
Mozregression point to:

• last good: 2023-10-26
• first bad: 2023-10-27
• pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=21cb54edc5f62850f2a894190cc74f3ed97caafe&tochange=5e91ccb036dcc938a829cba0e590941fb65a0bdf
• potentially regressed by: bug 1860377

Comment 1

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

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

:jjaschke, since you are the author of the regressor, bug 1860377, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Jan Jaeschke [:jjaschke]]

Yeah, looks like a regression of Bug 1860377. (not sure if DOM::Selection or Layout is the right component. It's related to Selection / Custom Highlight API, but the code responsible lives in layout)
I'm on PTO at the moment. If it's super urgent, I can try to come up with a fix right away, otherwise I'll start working on this on Feb 19.

(keeping the ni?).

Comment 3

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

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

Comment 4

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

We still need to have better understanding and investigation here.

Comment 5

[Jan Jaeschke [:jjaschke]]

Attachment: expected-behavior-Nightly-2022-01-01.png

Attached an image which shows the expected behavior. This is taken from Nightly 2022-01-01.

Comment 6

[Jan Jaeschke [:jjaschke]]

Adding a bit more context here. Bug 1860377 added support for painting overlapping selections, which is needed for Custom Highlight API (which uses selection code to paint ranges). The algorithm that's responsible for painting the overlap does this for all selection types. I assume that we need to change this so that painting overlapping ranges is only done for highlight ranges.

Comment 7

[Jan Jaeschke [:jjaschke]]

I will try and reincorporate the code from before Bug 1811823, so that non-highlight selections are painted the same way as before.

Comment 8

[Jan Jaeschke [:jjaschke]]

Attachment: Bug 1879084 - Custom Highlight API: Only paint one instance of a selection if it overlaps, unless it's a highlight selection. r=emilio!

Comment 9

[Jan Jaeschke [:jjaschke]]

Attachment: fixed-with-patch

Added a screenshot of local windows build with attached patch incorporated.

Comment 10

[Jan Jaeschke [:jjaschke]]

Here's a try run.

The attached patch reduces the amount of selection ranges per segment to one per selection type / one per highlight with same name. This way, the double-highlighting visible in the original post are gone, while overlapping selections (e.g. normal selection over find-in-page, selection over custom highlight, ...) are still possible. Patch goes non-wip if the test results look green.