See https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html for HIG

Safari touch bar, provided by dmaclach@

	safari touch bar.png 18.5 KB View Download

My first thought was to start with the buttons we have on Chrome OS keyboards that don't duplicate functions already available on macOS: search (would likely just open a new tab unless we want to implement new UI), back, forward, refresh and fullscreen

Here are some video demos.

touch_bar_safari.mov 7.3 MB Download

keyboard_suggestions.mov 705 KB Download

touch_bar_quicktime_editor.mov 2.2 MB Download

A couple more — looks like it picks up dialog boxes automatically!

touch_bar_screenshots.mov 386 KB Download

touch_bar_dialogs.mov 618 KB Download

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

As much as I would like to target M-55, M-55 is going to branch before we even get hardware to test this.

*I mean release to stable.

Safari with youtube videos

	Screen Shot 2016-11-01 at 6.00.02 PM.png 2.4 MB View Download

Views dialogs integration - https://codereview.chromium.org/2469213002/

	views_dialogs_touchbar.png 133 KB View Download

Safari full screen (the empty button on the right is just some bad state in the touch bar simulator).

	Screen Shot 2016-11-02 at 4.10.23 PM.png 30.0 KB View Download

Safari playing audio in the background (after I click a button on the right side of the bar). Right now nothing shows up when it's in the foreground.

	Screen Shot 2016-11-02 at 4.14.45 PM.png 33.0 KB View Download

Note I just landed ui/base/cocoa/touch_bar_forward_declarations.h to help us get TouchBar stuff through the CQ (i.e. building against the 10.10 SDK). Add stuff as necessary. See the rest of r430209 ( Issue 661581 ) for possible code fragments to use.

It would be cool if extensions could have a touch bar UI as well. I could see extension icons in the touch bar, and when touched they open the extension with extension-specific UI.

Also, emoji support for text inputs on the web, please!

The touch bar needs to remain a trusted UI surface, so web pages and, I think, extensions, should not be allowed to populate the Touch Bar with controls.

I'm not exactly sure what you mean by emoji support for text inputs on the web.

To clarify comment #18:

1) He's asking for the extension icons from the toolbar (to the right of the omnibox). Not for extensions to be able to add their own UI. I guess the icon itself is extension-defined, but we are already ok with that in the toolbar.

2) He wants emoji entry easily available, similar to the one-touch access in Messages and Safari. It's a button that expands to show more when pressed. 

c#18 says that the extension icon, when tapped, would open up to reveal extension-specific UI - I take that to mean UI created by the extension itself. We don't want to allow extensions to add arbitrary controls to the Touch Bar.

Oh, yeah, you're right. I figured they meant on the laptop screen, not the touchbar, but in hindsight I see that now. 

@21 - are you sure you don't want to allow that. 

First take the example of a regular old web app. Say Gmail. It would be great if archive, star, label, search etc had touch bar icons. It would be very helpful for anyone that didn't know Gmails keyboard shortcuts. Which is basically every user. Here's what the touchbar looks like when you use the native macOS mail app: https://pbs.twimg.com/media/CvysKehWcAAqRy7.jpg

So if you believe that the webapp should be able to control some part of the touchbar, should extension be equally allowed to do so?

Neither extensions nor web apps should be allowed to control the contents of the Touch Bar (for security reasons).

@shrike we have seen many examples of the touchbar even showing a progress bar for pages with video.
i dont see why we cant augment on this and provide shortcuts from webapps.

@apqchan: Could you please take a look at this.

thank you!

I would implore you to reconsider #19.

I believe that by opening up the chrome touchbar UI to customization by extensions, there is huge potential for developers to make exciting and engaging plugins that tap into the magic of the touch bar.

A flaw (I believe) in the way Apple architected the touchbar was to only allow the currently active window to influence its controls. This effectively makes it impossible to utilize the touchbar as a "secondary display" for purposes such as stock tickers, notifications, playback details and controls. But since Chrome happens to be the single application that a user has open the majority of the time, by opening the touchbar UI to developers, it can be "hacked" by extensions for all sorts of fun (and useful) possibilities!

I think there is so much potential here and locking it away is a bad idea.

Addressing #25: Apple is already building Touch Bar support into WebKit so that Safari webpages could add their own buttons on the Bar (see Release 19 https://developer.apple.com/safari/technology-preview/release-notes/). I think having support for this could be a game changer especially for Google services like Gmail, Inbox, Drive, Docs, Photos, YouTube, etc.

Re: #30, the note for Release 19 ("Added support for Touch Bar in WebKit") does not suggest that Apple is exposing a Touch Bar API to web pages. From looking at

https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/spi/cocoa/NSTouchBarSPI.h

it seems like Apple is making it possible for text fields to display text editing controls in the Touch Bar.

Even so, I think users want special editing buttons for Docs and Photos, special controls for YouTube, etc like Apple has in their stock Mac Apps (iWork, Photos, QuickTime). If they're not making an API I'm assuming this would make this more difficult for Chrome devs, but maybe it could be controlled by extensions(?). I think this type of customization is one of the things that already makes Chrome so much better than Safari and could be really great.

Hey, I am the Johannes who is active in the W3C Editing Taskforce. This touchbar really came as a huge surprise to the various JS editor developers. While being able to give access to certain editing functions would likely be of interest to a lot of webbased editors, the selection of editing options that Safari has seems less helpful, and the fact that these apparently cannot be turned off or exchanged with others is quite a big problem [1]. So please: Don't make the same mistake with Chrome! The best would proabbly be to not add any new menu entries for editing hosts initially, and then work through the Editign taskforce to figure out how to add entries in a way so that they can be removed/exchanged by JS editors.

[1] https://twitter.com/reinmarpl/status/815891989581492224

I agree with Johannes (https://bugs.chromium.org/p/chromium/issues/detail?id=660126#c33 ). I'm CKEditor lead developer and for years now we've been trying to get more control over the native context menu buttons and now we're really sad seeing what Safari displays in the touch bar. Nowadays, every RTE handles all the editing by itself which is the only way to guarantees content quality and implement features like collaborative editing. When I saw "font color" button in the touch bar in Safari my jaw dropped. This puts us back in 00's, because none of the modern RTEs enables font color pickers (in their default setups) anymore. We're on a constant battle to educate users how to format the text and now this ;| 

So, I'd like to ask you to not follow blindly what Safari did. There's clearly a need to open the context menus (the same applies to the native contextual toolbar in mobile Safari) to JavaScript developers. We may not be able to put our own items there, but at least we should be able to prohibit displaying some which the browser wants to show.

as a side note, opera/developer has support coming, too. https://www.opera.com/blogs/desktop/2017/01/opera-44-developer-initial-release/

I'd like to see support for Google Music player and in fact any media such as YouTube and iPlayer.

That's something that can be done with integration with the Media Session API (https://www.chromestatus.com/features/5639924124483584).

Here is how my Chrome TouchBar looks after customizing with BetterTouchTool 

	IMG_20170222_110329.jpg 2.7 MB View Download

I see this now in Dev
58.0.3018.3 (Official Build) dev (64-bit)
Revision	9f90720567a93b798d314c9d4af6bdd092a07767-refs/branch-heads/3018@{#5}

	Screenshot 2017-02-23 10.25.40.png 20.8 KB View Download

I guess in terms of expanding the feature set as I'm sure others above have already echoed: try to work towards customized TouchBar for Docs/Drive/YouTube/Gmail and other Google Apps. For now though, addition of even rudimentary TouchBar support as is depicted is a great boost to Chrome's productivity! Thanks for all the hard work! 

May be because of  issue #710917  touch bar disappeared in last Canary Version 60.0.3076.0 (Official Build) canary (64-bit)

Is there a way to enable it again?

spqchan@ - can you see about getting it turned back on for M60?