Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to find words containing <wbr> elements #33

Open
olivierdagenais opened this issue Jun 4, 2021 · 0 comments
Open

Unable to find words containing <wbr> elements #33

olivierdagenais opened this issue Jun 4, 2021 · 0 comments

Comments

@olivierdagenais
Copy link

I am so happy to see the quick-find extension was available again for Google Chrome!

I tried to use it to find a job in a Jenkins instance and couldn't (for the life of me) figure out why I wasn't getting hits from this extension when there were dashes in the job name. Viewing the HTML source of the Jenkins job revealed that Jenkins is generating HTML that looks like this for a job named job-name-with-dashes:

<a href="job/job-name-with-dashes" class="model-link inside">job<wbr>-name<wbr>-with<wbr>-dashes</a>

This renders as

job-name-with-dashes

...meaning the <wbr> elements are effectively invisible and only support the browser re-flowing long chunks of text (I had to look it up - <wbr> stands for "word break").

I looked at the code and it appears that the NodeIterator is configured to go through text nodes only (NodeFilter.SHOW_TEXT) which means the utility.textMatch() function doesn't really get the opportunity to consider the "whole word" as we would perceive it when attempting to match the search text; it only sees "job", "-name", "-with" and "-dashes" as separate text nodes.

It seems to me there would probably need to be a different mechanism in play, such as using a NodeIterator (or TreeWalker) that's able to also consider elements and process the nodes in a first pass to emit a new set of nodes (this time, adjoining text nodes that had been previously separated by "invisible" elements show up as a single text node) that's filtered as usual.

The above suggestion might also add support for finding text where the formatting changes in the middle of the sentence, such as a sudden bold mid-sentence (try finding as a sudden in this page to see what I mean).

Please let me know if anything's unclear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant