Is there any more information about how a site can do this and how a user could get the toolbar back if they want it?

palmer@ is the best historian for this, but he's out for at least a month. This is also a longstanding problem, so it doesn't need an immediate fix.

Let's just treat this as a reminder for now, until we can circle back with the right people and come up with a solution.

The history is that we *wanted* for this never to happen. :) The toolbar should only hide on a real user gesture (scrolling down).

I take it the mechanism for hiding it involves synthesizing a scroll-down event? Does anyone have a proof-of-concept?

A malicious site can allow the toolbar to be hidden (by user gesture as that is indeed the only way to get it to hide) and then start capturing all user gestures and prevent it from returning.  That is the evil case where it can then spoof a fake toolbar (+johnme who made a proof of concept of this ages and ages ago).

If the user focuses on any text field, we do bring back the toolbar.  So typing in a field should ensure the full URL is visible (but a site could spoof the keyboard entirely and then we are out of luck).

Because we allow the website to consume the gesture events first, there will always be a avenue for sites to take control.  We mitigate it by bringing back the toolbar very aggressively when we think it is needed, but I'm not aware of any work on the gesture capturing case.

Adding aelias and bokan on that front.

Thanks, tedchoc, I remember this now.

So, unless someone comes up with a PoC that breaks the "show toolbar on text input focus" mitigation, the status quo continues to be acceptable (even if not perfect).

Question: Does the mitigation work for editable elements (e.g. <div contenteditable="true" ...> as well as the specific text input elements (<input ...>, <textarea>, others?)?

> Question: Does the mitigation work for editable elements (e.g. <div contenteditable="true" ...> as well as the specific text input elements (<input ...>, <textarea>, others?)?

Yes, it works for all of those.

Great, thanks. In that case I don't think there's anything more we can do here.

I should clarify, this bug is because the status quo really is not acceptable, and was only a temporary compromise. It's still much too common to hit a site that accidentally perma-hides the omnibox, and it's trivial to make a perfect UI spoof. By comparison, Safari handles this very nicely, and always makes the origin available in portrait orientations. So, I want us to revisit this and consider solutions that aren't so clearly deficient relative to what Safari does.

I apologize for misunderstanding this bug. :( I thought it was that someone had a new, previously-unknown PoC.

I am happy to be of help in finding a solution! FWIW I quite like Safari's behavior on iOS:

* Portrait Mode: Normal view, with toolbar/location bar, editable location

* Portrait Mode after scrolling down: half-size, non-editable origin display (incl. tiny security lock for HTTPS); tap to show full-size editable location bar

* Landscape Mode: No toolbar/location bar; content gets full screen

* Landscape Mode after scrolling up to top: Normal view with toolbar/location bar, editable location

It seems to me like Chrome could do something similar. In particular, the landscape/portrait change is something that Chrome can learn about from the trusted computing base/platform, rather than having to let web content synthesize it. (Activity.onConfigurationChanged; in chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java, and elsewher, we don't seem to be handling ORIENTATION_{LANDSCAPE,PORTRAIT} specially right now.)

Interesting. One of the ideas we were playing around with was a mini-status bar at the top with our new bottom toolbar explorations: https://docs.google.com/presentation/d/15XxD_Jx-ju1qhivUeV83agfM8kv-YQmNSL1D5zRXi4E/edit#slide=id.g17f5f91530_0_85

Re-assigning to nickrad@ who is taking PM responsibilities for Clank FE projects

nickrad has never visited, according to Monorail. We should get an active owner for this.

(Probably +Lukasz if you're looking for a PM?)

I just read the comments on this ticket - wow, all the way back from 2016.

I'll add Emily Schechter to the thread because the is actively thinking about the omnibox as it relates to website security.

I'm open to a number of solutions, including always keeping the omnibox visible, replacing the large omnibox with a smaller ribbon once the site fully loads, or some of the proposals in the comment left by palmer@chromium.org on Nov 9 2016.

Since this has been around since 2016 (and before), is it fair to say it's not extremely urgent?

Note: Chrome on iOS has now implemented the mini status bar that has been discussed in this bug. Our long-term hope is to eventually de-emphasize URLs (Google-internal link: https://docs.google.com/presentation/d/18MgF9UoAA9EmuGL85Ur6hqUBtA9afmSoRnDK5W8zCxA/edit) but in the meantime I'm still in favor of the mini origin bar for Clank.

Does anyone object to making this bug public? I think there have been multiple public PoCs of attacking this. (I'm making a public version of go/urldisplay and would like to reference this bug.)

FWIW I have no objections, but I'd defer to +awhalley.