Is this a regression from old Options or a feature request?

At first glance, stripping diacritics does not seem trivial at all, given that we would need to understand which language is the user typing in, and have a lookup of the equivalent letter without any diacritics.

Not a regression from old Options. Harder than I thought it was given no native APIs to do this.

One technique would be accent folding, but that could get expensive given the number of text nodes we have: https://alistapart.com/article/accent-folding-for-auto-complete

Given that this is not trivial to implement natively, I am not convinced that doing this just for Settings would be a good investment of our time.

Perhaps it would be much more valuable to add a chrome private API that does this, or even better a standard Web API.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I am marking this as Available to empty the Untriaged queue, but realistically this is no clear path forward for fixing bug.

https://stackoverflow.com/questions/990904/remove-accents-diacritics-in-a-string-in-javascript looks promising

so I actually implemented a prototype for this at https://crrev.com/c/1244550/ but hit some snags.  the 1 snag I could probably figure out:

0) it's unclear to me if running normalize('NFD') on the textContent of every node we search will cause performance degradation

the other snags I'm not really qualified to answer yet:

1) I think typing "a" and matching "á" makes sense, but I'm not sure about the reverse (typing "á" matching "a').  this is probably super tricky to get right across all languages.

2) if the user types "ano" and it matches "año", should the search highlight bubble show "ano" or "año"?  on one hand, I'm sure showing "ano" when the matched text is actually "año" will probably result in some weirdness.  on the other hand, if there's results for both "ano" and "año" the bubbles might little a little weird (or maybe that's OK/desired)?

just a general update: I'd like to implement this.

> 1) I think typing "a" and matching "á" makes sense, but I'm not sure about the reverse (typing "á" matching "a').  this is probably super tricky to get right across all languages.

in general, I think the reverse ought to work, e.g. "á" should match "a" as well as "à" etc.

rationale:

(1) sometimes the same root word has different diacritics depending on the form of the word; we shouldn't hide plural results when the user searches for the singular. Spanish example: función => funciones
(2) sometimes the exact diacritic used isn't easy to control, like when they're swiping on the virtual keyboard or typing with an IME that auto-places diacritics. the user shouldn't have to correct diacritics in their search query just to see results.
(3) the diacritic is unlikely to distinguish the word from different words to the point of being annoying (assuming the user is searching for a word that's longer than a couple letters)

Oh, I just realized I'm the reporter for this bug. Hope that doesn't make my opinion biased :-)

my own input for comment #9, re: 1) using find in page (Ctrl/Cmd+f) does match "a" if you search for "à".  this is decent precedent.