1448564 - Find API returns wrong `rangeData` (repeated same result) if searched text is written in input element

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[juraj.masiar]

Attachment: Screenshot 2018-03-24 16.40.44.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180322152034

Steps to reproduce:

1) visit page:
https://www.safaribooksonline.com/search/?query=monads&extended_publisher_data=true&highlight=true&is_academic_institution_account=false&source=user&include_assessments=false&include_case_studies=true&include_courses=true&include_orioles=true&include_playlists=true&formats=video&sort=relevance

2) in background script execute:
browser.find.find('monads', {caseSensitive: false, entireWord: false, includeRangeData: true, includeRectData: true}).then(console.log);

3) observe the `rangeData` returned


Actual results:

Each item in the `rangeData` array has same values, except `text`.
All other properties in each object is set to same these values:
"framePos": 0, "startTextNodePos": 534, "startOffset": 0, "endTextNodePos": 534, "endOffset": 6

See the attachment picture.


Expected results:

Since the found matches are on different nodes, there should be different numbers for each item.

So far I managed to reproduce this bug only on this page and on the Facebook (after login in).

Comment 1

[juraj.masiar]

Attachment: broken_find_api.zip

I found what triggers this bug - the input element with the searched word.

This is a add-on you can use for easy reproduction of this bug:

1) load the add-on
2) https://www.wikipedia.org/ page will be opened
3) wait 5 seconds until you see "en" text highlighted
4) write text "en" into the search
5) wait another 5 seconds
6) open debugging console and observe results:
search result 26,37,156,1095,1108,1147,1156  background_sah.js:7:3
search result 26,37,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192,1192

As you can see, the `startTextNodePos` value get's broken once it reaches the input element.

Comment 2

[Shane Caraveo (:mixedpuppy)]

I can reproduce the problem, I'll have to dig into why it happens.  Strange thing is, the highlighting appears to work correctly, bu the nodes returned are bad.  Maybe Mike has some knowledge to contribute here.

Comment 3

[Mike de Boer [:mikedeboer]]

I'm sorry, I don't have the time right now to dig into where the fault may lie - I do know that no similar bug was reported for the core Find Toolbar or Find Backend components. So that'd point my nose toward the Find API here...

Comment 4

[xia]

I developed an add-on [1] that uses find API and had a problem probably same to this bug.
[1] https://addons.mozilla.org/ja/firefox/addon/auto-find-text-fragment/

This GitHub issue [2] reported that the add-on had incorrect behavior.
[2] https://github.com/xia-sava/auto-find-text-fragment/issues/1#issue-656971013

To reproduce, open the web page [3], and searching string 'City Fur' (including single quote) with find.find({includeRangeData: true}).
[3] https://pool.wikifur.com/w/index.php?title=Convention_map_script&action=edit

The page has big <textarea>, it contains target string, at almost middle of content.

find.highlightResults() works correctly.

rangeData[0].startTextNodePos is incorrect. startTextNodePos is 305 (when I tested),
but traversed DOM with TreeWalker, it's real position is 255.

Do you have any workarounds...?