Unable to reproduce the issue on chrome reported version 67.0.3396.99 using Mac 10.13.5 with steps mentioned below:
1) Launched chrome reported version and opened New Tab Page
2) On New Tab Page omnibar given the URL: https://rachelbythebay.com, page got loaded and seen "https://rachelbythebay.com" on omnibar
3) Used Cmd+L to edit the URL in omnibar, appended '/bb/' to the existing URL then pressed on enter, page got loaded and seen "https://rachelbythebay.com/bb/" on omnibar

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it in better way.

Thanks!

Deleted: 862444.mp4 1.2 MB

	862444.mp4 1.2 MB View Download

Hello,

Thank you for trying to repro this! I see that your omnibox explicitly shows the "https" scheme, while mine does not. If you explicitly set chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains to enabled, are you able to reproduce the problem? This flag is enabled by default for me (Stable channel), but it may not be for you.

Thanks again.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Also attaching my chrome://version page with variations, in case that's useful (maybe there's a field trial related to this?).

Deleted: version.txt 1.4 KB

version.txt 1.4 KB View Download

I can't reproduce this but from the gif in the original report this looks like it could be caused by some recent changes.

> Setting the flag #omnibox-ui-hide-steady-state-url-scheme-and-subdomains to disabled solves the problem for me, and Chrome Canary does not have this problem. Apologies if this has been fixed already: I couldn't find the ticket so wanted to report. Thanks!

Ok, yes, with that flag enabled, this feature is not expected to work correctly. Did you explicitly enable it earlier, by any chance? Or was it just set to Default before you disabled it?

Tested the issue on chrome reported version# 67.0.3396.99 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and made #omnibox-ui-hide-steady-state-url-scheme-and-subdomains flag Enabled
2) On New Tab Page given the URL: https://rachelbythebay.com, page got loaded and seen as "rachelbythebay.com" with 'Secure Chip'(at left side of omnibar)
3) Used Cmd+L to edit the URL in omnibar, appended '/bb/' to the existing URL then pressed on enter, page got loaded and seen "rachelbythebay.com/bb/" with 'Secure Chip'
Observations: When the flag with #omnibox-ui-hide-steady-state-url-scheme-and-subdomains is Disabled or Default, same behaviour is observed as mentioned in comment# 2.

@Reporter: Please find the attached screencast for your reference and provide your feedback on it which help in further triaging it and could you please respond to comment# 7, hence adding Needs-Feedback label to it.

Thanks!

Deleted: 862444.mp4 3.1 MB

	862444.mp4 3.1 MB View Download

> Ok, yes, with that flag enabled, this feature is not expected to work correctly. Did you explicitly enable it earlier, by any chance? Or was it just set to Default before you disabled it?

The flag was set to default (I only discovered it when trying to debug this repro). I reset all flags to default and tested in that state, just to make sure. So for me, default = enabled.

I don't have any other theories about why this would happen, unfortunately :-/

Thank you for providing more feedback. Adding the requester to the cc list.

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

Unable to reproduce the issue on chrome reported version# 67.0.3396.99 using Mac 10.12.6/10.13.5, hence removing Needs-Bisect label, feel free to add it back if required. Could someone from the UI>Browser>Omnibox team have a look at this issue.

Observations: As shown in Comment# 2 & 8, when the flag is Enabled, URL: https://rachelbythebay.com got loaded as "rachelbythebay.com" with secure chip and after appending the URL with '/bb/' page got loaded as "rachelbythebay.com" with secure chip. When the flag is Disabled or Default, URL: https://rachelbythebay.com got loaded as "https://rachelbythebay.com" with secure chip and after appending '/bb/' to the existing URL page got loaded as "https://rachelbythebay.com/bb/" with secure chip.

Thanks!

Mac triage: assigning to jdonnelly@ directly for triage or further investigation.

Currently on "Version 69.0.3497.81 (Official Build) beta (64-bit)", when I edit a URL, the "https://" prefix automatically reappears, but "http://" does not.

Please ensure that the new editor handles http:// and https:// consistently.  This is a new opportunity to resolve  Issue 41467 .

Sorry I marked this bug as a duplicate of a restricted one.  For concreteness, let me give an answer here, copied from the other bug.  In short, the flag omnibox-ui-hide-steady-state-url-scheme-and-subdomains is not working right in M-67 and M-68.  It should be entirely fixed in M-69, and will be the default behavior there as well.

By way of background:
>>>
We hide HTTP and never re-display it, since it's the "default" protocol. Merely typing "google.com" and pressing Enter will direct Chrome to navigate to http://google.com.

We hide HTTPS and must re-display it on edit, since we don't want users to "lose" HTTPS by editing the URL.

For instance, if the user is on "https://www.google.com", and wanted to append "/maps" to the end of their URL, we don't want to subsequently navigate the user to "http://www.google.com/maps" and lose the HTTPS.

In the long terms, our goal is HTTPS everywhere, by which time Chrome will consider HTTPS the default protocol. In that future, we won't be re-displaying https.

We did consider making storing a hidden bit for https instead of re-attaching it to the string, but there were a variety of issues with that.
>>>

> - We hide HTTP and never re-display it, since it's the "default" protocol. Merely typing "google.com" and pressing Enter will direct Chrome to navigate to http://google.com.
> 
> - We hide HTTPS and must re-display it on edit, since we don't want users to "lose" HTTPS by editing the URL.

When the user types "google.com" and presses Enter, the protocol name is now hidden, regardless of the HTTP vs. HTTPS default; this is a win for UI consistency.  However, this default needn't have any bearing on the canonicalized format displayed in edit mode, because pressing "Enter" takes you out of edit mode.

When HTTPS becomes the default, will the URL editor remove "https://" and add "http://" instead?

To be clear, I'm not criticising new https:// editor.  It works great, and I think it should be expanded in scope to cover http:// equally.

> When HTTPS becomes the default, will the URL editor remove "https://"
> and add "http://" instead?
Yes, I believe that's the plan.

> > When HTTPS becomes the default, will the URL editor remove "https://"
> > and add "http://" instead?
> Yes, I believe that's the plan.

But why?  What's the benefit (to users, or anyone else) of having three modes (display, edit with protocol, edit without protocol) when the latter two could reasonably merge?