1948211 - Creating text-fragment does not work across lines on this testcase. Chrome allowd you to create.

Status: ASSIGNED

(Core :: DOM: Navigation, defect)

Description

[Mayank Bansal]

Attachment: p5.js

Enable dom.text_fragments.create_text_fragment.enabled
Open attached testcase
Scroll to the bottom
See text like this:

 * This is a list of languages that we have added so far.
 * If you have just added a new language (yay!), add its key to the list below

Select both the lines and right click

AR: Highlight link to copy option appears
ER: Option does not appear

If you individually select each line, the option appears for both.

Profile: https://share.firefox.dev/411vbQd
So this does not fall into the bucket of "takes more than 5 seconds to compute"

Comment 1

[Mayank Bansal]

is this a dupe of bug 1948202 ?

Comment 2

[Jan Jaeschke [:jjaschke]]

No, not necessarily. This is plain text, so there should be no block boundaries.
I'd have to debug this to find out what's going on.

Comment 3

[Mayank Bansal]

Infact you dont have to open the attached document. Selecting the two lines in comment 0 also do not trigger the creation of text-fragment.

Comment 4

[Mayank Bansal]

Chrome allows you to create the text-fragment for the two lines in comment 0 :https://bugzilla.mozilla.org/show_bug.cgi?id=1948211#:~:text=*%20This%20is%20a%20list%20of%20languages%20that%20we%20have%20added%20so%20far.%0A%20*%20If%20you%20have%20just%20added%20a%20new%20language%20(yay!)%2C%20add%20its%20key%20to%20the%20list%20below

Comment 5

[Jan Jaeschke [:jjaschke]]

Attachment: Bug 1948211, part 1 - Text Fragments: Keep special chars at beginning or end of range. r=#dom-core!

When creating a text fragment from a range, the range
needs to be expanded to the nearest word boundaries.
This is done by first moving the range boundary inwards by one word,
and then outwards by one word.
If the range boundary is a special char, the algorithm would jump to the
end of the next word and then back to the beginning of the word:

|* test
* test|
* |test

This patch makes sure that the range boundary is not moving inwards.

Comment 6

[Jan Jaeschke [:jjaschke]]

Attachment: Bug 1948211, part 2 - Text Fragments: Correctly consider prefixes for range-based matching. r=#dom-core!

For range-based matching, the previous matches were determined incorrectly:
The start match must be matched until the end of the start of the target range,
and the end match must be matched until the end of the end of the target rage.

Before this change, the start of the target range was always considered as a
match to eliminate, therefore producing wrong results.

Comment 8

[Peter Van der Beken [:peterv]]

I assume this requires dom.text_fragments.create_text_fragment.enabled = true.

Comment 9

[Jan Jaeschke [:jjaschke]]

This needs more work, because the logic for extending range boundaries to word boundaries is more complex than anticipated, and I'll likely have to switch back to using the DOM tree here. Therefore, I moved part 2 of this patch set (which is standalone) into its own bug (bug 1951362), so that it can land in the meantime.