We've repeatedly wontfixed this in the past, but maybe it's worth another round of looking.

Could implement a bit like Visual Studio, where a "v" marker is a clickable surface that expands the box to show more options.  Though if case sensitivity is all we put in those options, that's kinda overkill.

+CC ainslie because I don't know what the process is these days for "hey UX folks, can you stick this in your list of issues to review".

Regex search would be awesome, if that could be another option.

I'm only an English speaker, so my experience is limited, but other users might like options for diacritic sensitivity.

Hmm. Tricky. I like the simplicity of our current model. 

One idea would be to treat strings in quotes as case sensitive. 
Inspired by Google Search using quotes for refinement: https://support.google.com/websearch/answer/2466433 

maxwalker@ + hwi@ - WDYT?

Deleted: findinpage-today.png 150 KB

	findinpage-today.png 150 KB View Download

What would be a use case? Finding a name quickly e.g. "Ann" filters out "Joann"? Understanding various use cases might help find an alternative. 

re: c5
Trying to understand the issue...
Q: Would it be problematic if it becomes *case sensitive match* when the string includes a UPPERCASE letter, assuming the person has made an extra effort of typing an uppercase letter to find only such string (and case insensitive if typed all in lowercases)? 

I did mention an example in the ticket description. your example also works.
I don't want to take this ticket out of context, but the perfect experience for me is having the common search options in most IDEs:
1) case sensitive (highest priority)
2) whole word (not bad to have)
3) regex (bonus!)

and the use cases are similar to what we handle every day as developers on our IDEs when we search for stuff :)

as for design/simplicity issues, we can hide these buttons or options behind a preference or even a flag, but I still prefer making it easier to find for the avg. users 

as for "Double Quotes" as case-sensitive: I'm not sure. it's better than nothing for sure but what if I'm looking for double quotes, also discoverability will be hard

Thanks for the use case on c7, eng.a7mad.gamal! 

To find a way to provide additional useful options while keeping the UI simple at the same time, I think it's helpful to continue to clarify the range of users and use cases so we can determine a proper approach to this issue. Welcoming more use cases here. Let me continue to monitor this bug. 

Here are some use cases I'd be interested in:

Case-sensitive search:
1. Finding an acronym/initialism that is spelled the same as a common word or word part, e.g. WHO, PLA, IDE
2. Conversely, finding a word but not the acronym/initialism, e.g. who, swat, add
3. Finding a word that you know was used at the beginning of a sentence, e.g. Cats
4. Finding the word "I"

Whole-word search use cases are easy to find:
1. Finding "cat" but not "catheter"
2. Finding "car" but not "carbuncle"
3. Finding "light" but not "lightning"

Regex search:
1. Finding email addresses while ignoring Twitter handles: \S+@\S+ (a more accurate email regex is left as an exercise for the reader)
2. Finding phone numbers: [0-9]{3} ?- ?[0-9]{4}
3. Finding hex identifiers [0-9a-b]{8,}
4. Finding timestamps: [0-9]{2}:[0-9]{2}:[0-9]{2}
5. Finding inconsistently spelled words: colou?r
6. Finding an acronym that is used inconsistently with or without dots: Ph\.?D
7. Finding single quoted words: "[a-z]+"
8. Finding prefixes or suffixes in a linguistics article: \b-[a-z]+|[a-z]-\b
9. Finding derivatives in a math article: d[a-z]/d[a-z]
10. Finding a star name in an astronomy article: [0-9]+ [a-z]{3}

thx @acrume for this perfect list, couldn't have said it any better :)

@hwi thinking again about the "range of users" and the given examples, I think it's fair enough to protect this option behind an option since the user range seems a little bit advanced. that way n00pz get the clean and simple UI and power users who are crazy enough to write regex won't bother the extra UI elements :)

I'm not a designer, but I love how Atom shows these options as tiny toggles with just an icon + tooltip just in case

Deleted: noname.png 1.5 KB

	noname.png 1.5 KB View Download

 Issue 691678  has been merged into this issue.

 Issue 8717  is the historical tracker for this request.

I'm going to assign this to myself for now. I've wanted to add this for a while now, and am already currently working on find-in-page.

Some thoughts on possible ways this can be done...

I do like the current simplicity of the find bar, and there are ways to add case sensitivity without adding to the UI, as were mentioned in C5 and C6, though there are reasons that I don't think that either are a good idea.


1) Make the search case-sensitive automatically if the search string is in quotes.

This seems weird and counter-intuitive to me, as quotes would make me think more about the searching for whole word feature than to search with case-sensitivity. Also, as was pointed out in C7, this would prevent actually searching for a quote (which I have personally done before). I think this would annoy/confuse more users than it would help.


2) Make the search case-sensitive automatically if the search string contains a capital letter.

This is common solution in certain editors, like Emacs. However, this fails in at least two cases I can think of:

- If the user pastes a string into the find bar that contains capitals, then that doesn't necessarily mean that they intentionally wanted them capital, and they may miss results they want to find.

- It is impossible to use this method to case-sensitively search for an entirely lowercase string.

More thoughts...

The way that I personally think would be best to implement this into the UI is similar to what was mentioned in C2 and C7: to have an extra button in the find bar which allows access to additional preferences for find, including case sensitive search.

Optionally, to preserve the current simplicity of the find bar, we could make this extra button only be shown if toggled on as a setting in the settings page, though this will likely require further discussion for specifics. Personally, I'm okay with just adding the button, since that will drastically increase discoverability.

Reasons why I think this works well:

- It still keeps the find bar pretty clean. In FireFox, all of the options are listed out explicitly on their find bar, for example.

- Discoverability (if button appears by default).

- There are no missing use cases like being unable to search for lowercase strings or actual quotes.

- This scales well. Only a single button need be added, but the overlay that comes up can cover multiple cases, including case sensitivity, whole word search, or even regexes.

- There is already a precedence in Google for doing it this way. If you look at Google docs, when you press Ctrl+F to open the find bar, it already includes this extra button, which allows access to both case sensitivity and regex search.

precedent*

how about a new setting but with a notification on the first trigger of the new dialogue informing users about this updated behaviour?
this way the bar stays clean and users stay updated

I'm not sure if a notification would be okay to do. I think many will just be annoyed by that and dismiss and ignore it (that's what I often do when notifications about new features come up). I think just adding the button would be less cumbersome on users than making a popup appear.

even better for me :D

I am increasing priority because I think this will actually have a large positive impact if we can get this feature in.

Hi there, any progress on this feature? I am frequently stymied by the lack of case sensitive and whole word search. (c9 provides a perfect summary of the issue I encounter frequently, and I hate having to launch Firefox just for this purpose.)

Thanks for your efforts.

Unfortunately, this is currently being blocked on UI review, so there is no active progress at this time.

For a very rudimentary method providing case-sensitive search, I found this piece of Javascript and put it in my Bookmarks bar:

javascript:(function(){var text=prompt('Search for:','');if(text==null || text.length==0)return;var spans=document.getElementsByClassName('labnol');if(spans){for(var i=0;i < spans.length;i++){spans[i].style.backgroundColor='transparent';}}function searchWithinNode(node,te,len){var pos,skip,spannode,middlebit,endbit,middleclone;skip=0;if(node.nodeType==3){pos=node.data.indexOf(te);if(pos>=0){spannode=document.createElement('span');spannode.setAttribute('class','labnol');spannode.style.backgroundColor='yellow';middlebit=node.splitText(pos);endbit=middlebit.splitText(len);middleclone=middlebit.cloneNode(true);spannode.appendChild(middleclone);middlebit.parentNode.replaceChild(spannode,middlebit);skip=1;}}else if(node.nodeType==1 && node.childNodes && node.tagName.toUpperCase()!='SCRIPT' && node.tagName.toUpperCase !='STYLE'){for(var child=0;child < node.childNodes.length;++child){child=child+searchWithinNode(node.childNodes[child],te,len);}}return skip;}searchWithinNode(document.body,text,text.length);})();

It's explained at https://knowlet3389.blogspot.com.au/2013/10/js-find-on-page-bookmarkletperform-case.html and it's available as an extension named "Sensitive Search" in the Web Store: https://chrome.google.com/webstore/detail/sensitive-search/lmkiknflakipndgbpihmjmcbenedebfg

Has there been any news on the UI review front? 

Also, if this does go through will this contain diacritic sensitive search too?

Sorry, by blocked on UI review, I didn't mean that the review was ongoing; it has already concluded and the proposed UI changes have been rejected. UI review does not want to add to the find bar UI at this time, which unfortunately precludes the addition of any new features of this type.

I still think that these features are really important though, and am hopeful that the UI proposal can be revisited in the future.

Howabout changing the diacritic search at least? If nothing else at least so that the diacritics will find only themselves. Even if search for "jaa" gives both "jaa" and "jää" as long as "jää" gives only "jää".

Case-sensitivity and whole-word search are definitely useful options for average users. Controlling sensitivity to diacritics would be a nice option as well, especially since the current behavior normalizes them and finds characters without diacritics, but the other two are more important. Regex would also be nice to have advanced users but that's not such a high priority.

I honestly fail to understand why the UI team refuses to make any changes for YEARS when it's obvious the first two features are widely used and wanted.

Here's a constructive but pretty lame option/solution for those as distraught about this going on for a decade now:
You can cut and paste the content into a real search capable doc instead.

Here's a constructive great logical easy option/solution for those doing nothing on this for over a decade now:
Devs could detect regex and pipe it through that.

It's not hard to find a solution here people? Please take time to consider the regex detection approach, thanks for your deep and thoughtful consideration of repairing this embarrassing oversight.
Here's another one a right click pull down with checkboxes for case and whatever else, have it per-page or maybe make a persist checkbox too.

[I would totally be doing both of what the yellow and blue boxes say not too if I didn't see them there. My apologies if I somehow did subconciously.]

According to Google UI designers, English is the only language in the world, US-ASCII the only charset and US QWERTY the only keyboard layout. 

Presumably, the Chrome team practices some flavor of Agile methodology. It's really difficult to understand why something as straightforward as case-sensitive and/or whole-word search could not be introduced. There are lots of UI options with minimal impact, and if it were released and presented a problem, the team could take it out (as they've done with other features in the past).

Firefox has had case-sensitive, whole-word search for years. Attached is a screenshot of their current UI (v. 57) -- I realize that they take up more real estate than Chrome, but the point is they have these two simple features. The recent Firefox rewrite has resulted in a noticeable performance improvement -- enough so that I've started using it again after relegating it to a test-only browser. I hope the Chrome UX team does not underestimate the difference that small interactions like this can make. I'm already drifting back to Firefox for some usages. Chrome team, please don't take your users for granted.

Deleted: Firefox-search.jpg 17.1 KB

	Firefox-search.jpg 17.1 KB View Download

This was spun off from bug 71741. 

If the UI team does not want to add a button/check box,  there are a few alternatives I outlined in https://bugs.chromium.org/p/chromium/issues/detail?id=71741#c30 .  One of them is to add an extension API to control the FiP behavior and let users install an extension to control it. 

I definitely favour allowing the overriding of this behaviour by an extension. 
 That would mean the best of both worlds.

Joe Public can have the same, plain search box they've always had (albeit in its new place as a page action), and developers could create an extension for everyone else.

In the meantime, the current search functionality is extremely limited, especially when it comes to diacritics, and I presume that non-Latin alphabets like Cyrillic fare just as poorly.

I heard Google likes analytics. Why not perform an A/B test on it?

Although i would really like an API.

Explanation of increasing priority: I often work from ChromeOS, and need to search through logs regularly. I literally cannot do a case-sensitive search by any means; the browser can't do it, the text-editing apps can't do it, nothing else can either.

41: I personally totally agree with the increased priority, since this has been a pain point and real shortcoming of Chrome for... forever.

I've recently had an idea (since thinking about this again today, after seeing your comment). UI team REALLY doesn't want to fiddle with the longstanding find bar, but maybe we can go about this another way...

Perhaps we could add an alternate, more advanced find-in-page feature to DevTools (or accessed through DevTools), which would allow these find options for case-sensitive, whole world matching, regex, etc. This could provide the more advanced users (that are feeling a lot of pain with this) the ability to do the searches that they need, without changing the existing find bar at all or adding any extra complexity for regular users.

Thoughts? Would this solve this problem?

Putting options for case-sensitive, whole world matching, regex, etc into the regular Chrome settings would be just as fine.  Users will only turn on those options they want.  There's no problem here.

Commenting since I was explicitly CCed, but un-CCing myself, since I don't want to be drawn into this bug.

@41: While that's a legit use case, the bug does not lack for legit use cases; those cases do not give cause for elevating to P1.  As for a workaround, I don't know what "the text-editing apps can't do it" means, since Google Docs has case-sensitive matching, so the (ugly hack) workaround of pasting in there and searching would work if case-sensitivity is critical.

@16/44: We're not adding a setting for this; I personally like the toggle in the find box, but if even that is too much for the UI leads, then we'll need a solution (e.g. comment 5, comment 34) that doesn't add UI.

I could not get such a search to work in Docs.

The UI team are just wrong here, and this feature should be forced through over their objections if necessary.

Mark is taking a look at this feature request to see whether the right decision is to do the dev tool option or whether to resurrect the convo with UI. Stay tuned.

I can understand not wanting a cluttered UI for the find box. This is a minority use case, and degrading the UI 100% of the time for a feature that's only used 1% of the time is usually not going to be worthwhile. Several good designs from other projects have been suggested, but if the UI team says that they're not good enough, on that I am willing to accept their judgment as better informed and more expert than my own.

But rejecting adding a _setting_ out of hand? That's preposterous. It doesn't even need to take up scarce menu real estate; it can be heavily buried as long as there's a keyboard shortcut. Power users and other users who use it often can use the shortcut quickly, and others can google the question every time, find a map to the correct setting location, and use it that way.

Ctrl+Shift-F has no bound function, by the way.

Having a hotkey would be nice. I had actually looked at potential hotkeys earlier and also noticed Ctrl+Shift-F. Maybe this could bring up the more advanced UI if we end up going with separate find bars (simple / advanced).

In any case, glad to hear that Mark (PM for desktop UI) is currently looking into this! Probably it would be best to figure out where exactly this advanced functionality can live first, and then decide on whether a dedicated hotkey is warranted.

My god, this simple feature request started from 2009 ( Issue 8717 ), and now 10 years have passed (10 years!!!!) and we still don't have case-sensitive search.

This is REALLLLLLLY frustrating when you have to search a keyword in a long page and there are so many case-insensitive hits!

BTW, I don't think the previous argument "Case-sensitve search will confuse general public" stands, because general public do NOT use search at all!

People who use search absolutely need case-sensitivity!

It is obvious that the makers of Chrome have their focus on the big picture, the small devices that make up half of all internet traffic and searches – which have no need for in-page searches, let alone case sensitive ones. Dinosaurs with keyboards are not welcome in this brave new world.

I don't think that can be it; find in page is the item in mobile Chrome's menu I use the most often.

Hi, I landed here because I am trying to do a case-sensitive search in a PDF, which of course no extension is going to be able to do.

I understand the interest in keeping Chrome's UI scalable by keeping moving parts to a minimum, but on the flip side I am grateful there is interest in revisiting this after multiple wontfixes!

The historical issue suggested a right-click menu. That could be one approach. But does any OS use CTRL+Shift+F for anything significant? Could Chrome borrow that instead?

Btw: in the current search field, pressing Shift+Enter does a reverse search. So there's already some hidden behavior in there, adding more isn't really going to be exceptionally precedent-setting, IMO.

I've heard the notes about regex search. As a power user, I'd love it. As a (would-be) developer, I fully understand why it's not already present, and an unlikely addition :) but case sensitivity is something that even Internet Explorer (!!) has.

Note that case-sensitive search is already implemented in Blink, and as far as I'm aware, handled properly in the rest of Chromium as well:
https://cs.chromium.org/chromium/src/third_party/blink/public/web/web_find_options.h?l=43-44&rcl=aaa0f22fb2131e09f8d0146c5d5e0ff6b06494e3

So all that's really needed is a bit of UI, the rest is already there...

58:

This is true, and it is already used in the find-in-page API for <webview> (in chrome apps).

The implementation would be fairly simple to extend to Chrome's find bar. It's mostly just a matter of getting some UI that can allow access to it.

In that case, I'd like to throw two bits of anecdata to the UI team:

1. I really like the right-click option in https://bugs.chromium.org/p/chromium/issues/detail?id=8717#c23 and would like to surface this idea. Out of all the meh-looking suggestions scattered throughout the various issues this one looks really decent.

2. I was staring at the Find popdown and got an idea of my own: a subtly stylized "Aa" in between "⌄" and "✕". It works like a toggle, and is shaded grey when active (you might be able to simulate this by hitting Tab (after hitting ^F) to focus the Find popdown's close button).

An unrelated question:

Does the Chrome debugger protocol provide enough interactive control (highlight, focusing, etc) to implement universal (HTML _and_ PDF) in-page search?

If not, it would be cool if such functionality were possible. That's where regex search inside PDF would be implemented, I think - and it would be incredible if this were possible, as PDFs are notoriously hard to search straightforwardly because of OCR glitches.

How many in the UI dev team (or any Google dev team for that matter) have minimal command of a language without phonemic diacritics in its native script (i.e. minimal English, Spanish, Russian, CJK, etc.)? Consider the number of native speakers of Portuguese (203m), German (101m), Vietnamese (70m), French (70m), and Turkish (60m), and that in Western Europe 30-60% of those in these home countries report having no second language competence (http://i.imgur.com/DTKYrNx.png). Consider also the apparent contradictory priority of Google in making its homepage default to one's detected location and attached language (e.g. German if in Switzerland, like a bozo) in 2017 and requiring one to define a custom search url if one wants to default to 
the US/international page.

Finally, to consider what a monolingual native literate of a script with phonemic diacritics has to put up with, the best analogy for English is this: "y" and "i" return the same results.

Whether you are here representing Google or you have your own company, if any of this seems odd to you, ask yourself (and your bosses and/or HR), who do you represent? Who do your competitors?

I have a Use case for which I am now downloading another browser to do. A business colleague has a website where on at least one page they have many instances of FIle rather than File (that is, the second letter has been accidentally capitalised).

I've just had a meeting with markchang@, and this issue is being reviewed again! I believe Mark is on board with this too, and I'm feeling confident that this time it's going to stick. It should now be a matter of how this will be implemented rather than if. :)

Sorry to bother, I like an idea in the reference bug 71741: add an option "Case-sensitive search" to the context menu inside the search box. So, the visible search UI will not be harmed in any way. Moreover, such option may absent by default and appear only after enabling it somewhere in the Settings (or exist by default for diacritic-intensive languages). It's also possible to add the same option to the search UI in Chrome for Android by long press inside the search box.

I hope this way may somehow address the possible objections of UI department.