New issue
Advanced search Search tips
Starred by 302 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Feature

issue 716099

  • Only users with EditIssue permission may comment.

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Support for Snow Leopard text substitutions

Reported by, Apr 23 2010

Issue description

Chrome Version       : 5.0.375.17 dev
URLs (if applicable) :
OS version               : 10.6.3
Behavior in Safari 3.x/4.x OK
Behavior in Firefox 3.x FAIL
Behavior in Chrome for Windows: Irrelevant

What steps will reproduce the problem?
1.  Define a useful text substitution in Language and Text Preferences, such as substituting 
"\gamma" with "γ".
2.  Type your substition into any text box in Chrome and observe that it is not changed
3.  Right click any textbox in Chrome and observe that there is no option to enable text 

What is the expected result?

What happens instead?

Showing comments 14 - 113 of 113 Older
“me too” on Safari for the same reason…
Yea this is getting ridiculous. Mod flagged this a year ago...

Comment 17 by Deleted ...@, Jul 12 2012

I'm about to abandon Chrome after making the same realization.

Comment 18 by, Jul 13 2012

I have never been able to start with it for the same reason.  Is it such an enormous technical challenge for Google to implement this?

Comment 19 by Deleted ...@, Sep 5 2012

Can't believe this isn't supported yet.

Comment 20 by, Oct 17 2012

This would be super duper nice to have since now people use these shortcuts on iPhone's a lot and desire a level of consistency.

Comment 21 by Deleted ...@, Oct 17 2012

I went back to TextExpander because it works inside Chrome. But sad you have to use a 3rd party tool when there's an option inside the OS.
isautomatictextreplacement / WebAutomaticTextReplacementEnabled are ok keywords for if someone wants to take a look at this

Comment 23 by, Feb 27 2013

WOW.  3 years later and still NOTHING?  If the built in Mountain Lion "dictation" is able to insert text into chrome text fields, why can't the built-in text replacement feature? What's the difference?

I don't think this has anything to do with "services" not being able to interact with Chrome… For instance I just went to services and Click "enter short date", or what not and got...

Wednesday, 27 February 2013

It seems there's a disconnect here and it doesn't have to do services and it doesn't seem that have to do with how Apple handles text insertion. Seems like a Chrome-specific issue.. possibly a bug with "Secure" entry mechanisms?

Project Member

Comment 24 by, Mar 10 2013

Labels: -Area-UI -Feature-OSIntegration Cr-UI-OSIntegration Cr-UI
Yeah!! Text substitution, is like text expander for free, without need to have another app running consuming our precious ram.
Arrrgh this sooo irritating!!! First, there is no 64bit chrome which causes flash problems and now this!! Chrome is such an amazing browser customizable in soo many ways, but why is it lacking such support features!!?? I cant believe google hasnt fixed this already!

Comment 27 by Deleted ...@, Aug 27 2013


Comment 28 by Deleted ...@, Sep 12 2013

I agree. TypeIt4Me works fine but I'd prefer to use the native app, especially as I'm doing CodeSchool, CodeAcademy, etc., which requires working in Chrome all day. 
Chrome has had FIFTEEN major versions released since this ticket was opened.

This isn't just a convenience for people. Text expansion can be used to help those who, for whatever reason (such as disability), have difficulty typing. It's an ACCESSIBILITY issue and as such, I think should be a priority to have implemented. It goes far beyond replacing a parenthetical "c" with the copyright symbol or "!?" with an interrobang (not that I'm giddy about that or anything...). Entire blocks of text -- an address, a signature, and who knows what other commonly written and rarely changing things are out there -- can be substituted.

User experience should be as consistent as possible, and something as fundamental as how text is inputted shouldn't be something users have to re-learn just because they've started to use Chrome.

Please fix this issue.

Comment 30 by, Sep 27 2013

Thank you Rick for such a clear and eloquent expression of this 

Comment 31 by, Oct 3 2013

Google, will this come any time soon?

Comment 32 by, Oct 21 2013

Still waiting…

Accessibility in Chrome is very poor. MacOS provides services and technologies for helping the users to interact with software, but only if the developers enable them.
#29 rick.bec…

@rick I really appreciate the way you put this:

"It's an ACCESSIBILITY issue and as such, I think should be a priority to have implemented."
Come on! It is 2013 (almost 2014) and still nothing? I Love CHROME and I don't really want to stop using it.

Comment 35 by Deleted ...@, Dec 22 2013

That is frustrating. 

Comment 36 by Deleted ...@, Jan 21 2014

Anoying yes, but there is a text expander extension to tide you over.
Safari > chrome + extension trying to make it more like Safari

Tim O'Haver
Wow, almost FOUR YEARS since this ticket was opened (which shouldn't even have been necessary, as we're talking about a basic accessibility feature) and Google still ignores it? What a shame.
> and Google still ignores it

And so has the rest of the open source Chromium community.  Just saying.

If you know C++ or are willing to learn, consider stepping up.

Disclaimer: I DO know C++, a bit, but don't really care for it, and this issue isn't annoying enough to make me roll up my sleeves and get into it.  Sorry.  "Do as I say, not as I do."  :)
 Issue 367105  has been merged into this issue.

Comment 41 by Deleted ...@, May 18 2014

still no improvement shame google chrome

Comment 42 by, May 18 2014

Is "not using the system wide spelling service" also included in this defect?

Comment 43 by, May 19 2014

dbonde: It's not, because Chrome _is_ using the system-wide spell checker. If you see behavior that indicates it isn't, please open a new bug.
really would like \shrug to become ¯\_(ツ)_/¯

Comment 45 by, Jun 26 2014

This has been driving me crazy lately, its been years now that this hasn't been fixed. It really shouldn't be vary difficult to fix considering the system provides all the necessary APIs.
In September 2013, Rick posted comment #23 noting this is an accessibility issue. It really determines who can use Chrome on a Mac. I wish I could make Chrome my primary browser.

Comment 47 by, Jun 26 2014

There's a limited amount of things Chrome engineers can do. It's not that there's no desire to fix this, but that there are other things that are also important.

Any and all help on this is welcome - Chrome is an open source project after all. Nico outlined in comment #22 where to start looking if you want to chime in. 

Meanwhile, please don't post "me too/why is this still not fixed" comments. That does nothing to get this fixed faster, and takes away time that could be spent on fixing things. If the bug is important to you, please star it. That's enough to say that you'd really like to see this happen.

This is not just a technical issue, but also a political issue. My experience is that issues that affect minorities don't get addressed unless people speak up. The original post was made in 2010. 

I appreciate your point that complaining about it doesn't solve the problem. But there's still the question: Does it  matter enough to Google that people with disabilities and other particular needs are currently excluded from accessing Chrome?

 I wish I could help more directly on the technical side, but I am not an engineer, myself.
If I had the technical chops I'd dive in to fix this myself, but I don't. It is concerning that something flagged as an accessibility issue has gone so long without being addressed.

Clearly the people who discover it and take issue with it are not the same as the people who are able to fix it. I can't help but wonder if that's partially because of the historical lack of diversity and concern about accessibility within our industry.

What can we do to help this issue along? I am a web developer and marketer in the open source world, so I have reach but I don't have the skills necessary to fix this bug.

Comment 50 by Deleted ...@, Dec 12 2014

Just use this Extension:
It works perfectly.
I have no affiliation with this extension btw
That extension doesn't work on Google Docs (and other sites). Hence, completely useless for many.

Comment 52 by, Dec 12 2014

How do I unsubscribe to this ... my iMac has grown old and passed on ...
time has solved the problem!​

Comment 53 by, Dec 12 2014

patsmac: Just click the little yellow star in the top left corner. It should become white, which means this is not a favorite of yours, and you don't want to follow this any more.

Comment 54 by Deleted ...@, Dec 12 2014

It is weird this hasn't been resolved yet. I'm unsubscribing just because I'm giving up hope now after 4 years haha.

Comment 55 by Deleted ...@, Dec 13 2014

I switched over to Safari already, I guess I don't care if this ever gets resolved
Posting just to say "I moved on; no longer effects me" or similar doesn't really help anything and only results in lots of unnecessary emails being sent out. You can quietly unsubscribe w/o telling the whole world about it.

Yes, there are text expander/shortcut plugins for Chrome; however, in my experience, they work pretty inconsistently (only in certain text fields, only in certain parts of the Chrome GUI, etc.).

If Chrome did have support for OS X's native utilities, it could provide a consistent experience throughout the whole of its system (which, as I explained in an earlier post, is very important for usability), eliminating the need to use a plugin just to provide what should be a native feature.
Would really like this functionality.
Copied from another report: "Text replacement was originally disabled due to  but Apple has since fixed the root cause of the issue. "
 Issue 444603  has been merged into this issue.
Labels: Cr-Blink-Fonts

Comment 61 Deleted

Comment 62 by, May 22 2015

Please implement this. I will love you long time.

Comment 63 by, Jun 9 2015

I also will love you long time. I use this all the time.

Currently I feel:


But if you implement this I will feel:


But I feel like the implementers feel all:


Comment 64 by, Jun 13 2015


Comment 65 by, Jun 13 2015

Attempting to remove from cc.
unless you're Taylor Swift, I don't think this is gonna happen soon
For anyone wanting this badly, here's a wonderful alternative (Chrome extension):

Comment 70 by, Jun 26 2015

Here's another bump because really, I don't know why this isn't in Chrome already.

Comment 71 Deleted

plus 1 on the bump
Please, for the love of all that is good, implement this. It's a ridiculous oversight that annoys Mac users and harms people who need text expansion as assistive technology.
Status: Assigned
Labels: Restrict-AddIssueComment-EditIssue
Please star this issue instead of commenting.
 Issue 516194  has been merged into this issue.
Owner: ----
Status: Available
 Issue 582139  has been merged into this issue.
eae@, you mentioned there were some recent industry discussion on how to handle IMEs - would these discussion affect this issue? Were automatic input substitutions taken into account?
drott: I don't think this is a bug on the blink/ IME level. Chrome works fine with IMEs. The problem is that the text substitution doesn't reach chrome on the cocoa level. I've looked at this for a very short time a while ago, and I didn't see how this is done in NSTextInputClient. It's possible it's not part of the official NSTextInputClient api (NSTextViews get it automatically, but we obviously can't use that), or we're just not implementing it quite right.

(Then why does it work in Safari? Wouldn't be the first time that system frameworks special-cased safari; the "tap to look up definition bubble" had a two branches, one for text fields and one for the system webview too, at least in the 10.8 era)
Thanks for the additional background and sorry if my comment was a bit confusing. I agree it is not a matter of incompatibility with IMEs. I had not looked into implementing this, I was just curious - perhaps slightly off-topic - whether the discussion that eae@ mentioned was taking such text substitutions into account. 

Comment 84 by, Apr 28 2016

Components: Blink>Input
Components: -Blink>Input Blink>Editing

Comment 86 by, Sep 26 2016

Labels: Hotlist-MacQualityOfLife
Components: Blink>Editing>Spellcheck

Comment 88 by, Oct 5 2016

Labels: -Hotlist-MacQualityOfLife Proj-MacQualityOfLife

Comment 89 by, Oct 18 2016

Labels: -Type-Bug -mstone-X -bulkmove Type-Feature

Comment 90 by, Dec 1 2016

Labels: -Proj-MacQualityOfLife Hotlist-MacQualityOfLife
Labels: -Hotlist-MacQualityOfLife Hotlist-PlatformExcellence
Migrating to more generic platform label, so that it can be applied to other platforms (i.e. I love the idea).
 Issue 677537  has been merged into this issue.
Components: -UI>OSIntegration Internals>PlatformIntegration
Deprecating UI>OSIntegration in favor of the more generic Internals>PlatformIntegration

Comment 94 by, Jan 16 2017

WebKit implementation:

Comment 95 by, Jan 19 2017

Components: -UI -Blink>Fonts -Blink>Editing>Spellcheck
Labels: -Pri-2 Pri-3
Status: Untriaged (was: Available)

Comment 96 by, Jan 23 2017

Components: -Blink>Editing Blink>Editing>Spellcheck
Status: Available (was: Untriaged)
Text substitutions, aka Auto correction in Windows term, is integrated within spell checking. MacOS spell checker returns "text substitution" as similar as miss spell suggestions.

Note: Omnibox also doesn't support "Text substitutions" too.
This is currently the #7 top-starred blink bug, and we're going through all the top starred bugs to better understand their status / priority.

yosin@ is this something you're looking into in Q1 at all?

eae@ you've got an opinion on the priority (or lack thereof) of this one, right?

I wonder if it would be easy to add an UMA metric to count how many users this would impact?  I can imagine a "small but vocal minority" argument here for this being low priority.

rpop@ are you the Mac PM now?  Any opinion from your perspective in terms of Safari feature parity?

Comment 98 by, Jan 23 2017

Labels: -Hotlist-GoodFirstBug
Status: Assigned (was: Available)

Comment 99 by, Jan 23 2017

[Tentatively assigned to erikchen@, but that shouldn't preclude discussion/reassignment/etc. since he's tight on cycles.]

Comment 100 by, Jan 24 2017

re 57: While this would be a nice to have it is not a priority for the layout team at the moment given the relatively low number of users that would benefit (power users on mac).

If the Mac team or anyone else has space cycles this would make for a nice polish feature.

Here's some notes, mostly for myself.

To enable text substitutions:
Settings->Keyboard->Text, make sure there are entries under replace/with.

Here's how text replacement works in TextEdit:
Let's say that "\test" gets replaced by "foo". When the user types "\test", a blue replacement bubble will appear right beneath the word. If they click the word, or press space, or click the mouse, the replacement occurs. If the app is deactivated, the replacement occurs. The only time the replacement doesn't occur is if the user types an alphanumeric. If the user then deletes the alphanumeric, the replacement can occur again.

I tried to set up a replacement with a space in the "replace" text, but that produces an error "original text cannot include spaces". I'm sure there are other arcane rules.

NSTextView and NSTextField get the replacement behavior for free. I'm sure this is how TextEdit works.

Safari has similar behavior to TextEdit, but there are some differences. The replacement bubble only appears if the setting "Correct spelling automatically" is selected. The replacement behavior occurs regardless of that setting. 

In WebKit, automatic text replacement is controlled by [[NSUserDefaults standardUserDefaults] boolForKey:WebAutomaticTextReplacementEnabled], and if that isn't available, [NSSpellChecker isAutomaticTextReplacementEnabled]. There's a bunch of logic in Source/WebCore/editing/Editor.cpp to handle text replacement. The replacement panel, which WebKit calls "correction panel", is shown via AlternativeTextController::show(), which goes through IPC and calls CorrectionPanel::show, which in turn calls -[NSSpellChecker  showCorrectionIndicatorOfType:...]. 

Like Chrome, WebKit cannot directly use NSTextView and NSTextField, and it looks like they've reimplemented the logic for showing the correction panel, and performing the correction when appropriate.

Chrome currently uses the native spell checker to underline words. When they're misspelled, right clicking with bring up the suggestions from the system spellchecker. Alternatively, the setting "Use a web service to help resolve spelling errors" will use another dictionary with some context support. Notably, typing "icland is an icland" will result in different suggestions for the first and second misspellings. There is also a spelling panel that can be invoked under the "Edit" menu. This one always uses the native spell checker.

The relevant APIs for implementing text replacement are:
 -[NSSpellChecker checkString:...], using type = NSTextCheckingTypeReplacement to obtain the desired replacements.
 -[NSSpellChecker showCorrectionIndicatorOfType:...] to show the correction panel.

Assuming we want to mimic Safari's behavior, there are two separate tasks we need to do:
1) Implement automatic text replacement logic.
2) Implement the correction panel.

3) For macOS apps including Safari and TextEdit, the correction panel is also the UI for performing spell checking/replacement. Dismissing the panel will then result in an underlined word, whose context menu will have replacements.  We would need to figure out how (2) interacts with the existing underline spell-check UI.
I have some disorganised notes in an internal doc too -

This will likely be a big task, which needs a proper Chromium design doc.
I spent a little while trying to figure out how to best hook this new logic. In WebKit, the relevant method is Editor::markMisspellingsAfterTypingToWord. There are two implementations, one gated behind unifiedTextCheckerEnabled(), and another behind isContinuousSpellCheckingEnabled(). The former uses m_alternativeTextController, as described above.

Chrome's Editor.cpp has a method Editor::appliedEditing which calls  spellChecker().markMisspellingsAfterApplyingCommand(). This is probably the right place to throw in the new hooks? But I'd need to become more familiar with Blink to figure out exactly what to do.
Thanks.  I agree it doesn't make sense to prioritize this from a layout-team perspective, the priority is probably entirely up to the Mac team.

So erikchen@/shrike@ is this something you think the Mac team will work on in Q1, or maybe revisit in Q2?  I'm just trying to understand what the plan is / what expectation we should set with the folks who have starred this issue.

Note that while stars might make sense for prioritizing web platform stuff, we don't use stars to prioritize UI features. Chrome has millions of users on macOS, and most of them (rightly) don't know how to find and use our bug tracker. The people who do come here are skew highly technical.

(I'm not saying we shouldn't fix this bug, just pointing out that we don't look at star as much in UI land.)
thakis, that's a really good point.  We're looking at top web platform starred bugs assuming the denominator is all web developers.  But in this case the denominator is much larger.

Is there really any web platform exposure to this feature at all?  I.e. other than the normal IME mechanisms that can be used on any OS, will web developers need to be aware of this feature?  If not, then perhaps we should remove the Blink>Editing>Spellcheck label completely (which will have the side-effect of getting it off our "highly starred web platform issues" list)?
Blocking: 716099
lgrey@ has expressed interest in possibly getting this to work in the future.
 Issue 837908  has been merged into this issue.
 Issue 884618  has been merged into this issue.
[Mac triage] Over to ellyjones@ for triage.
Labels: M-X
This one's still M-X since we have no scheduled time to work on it. :(
Showing comments 14 - 113 of 113 Older

Sign in to add a comment