This is an intentional change as I understand it. See https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html

No I think there is an issue with the feature flag: #omnibox-ui-hide-steady-state-url-trivial-subdomains

When set to Default, https:// and www. prefixes are hidden. When set to Enabled, https:// is visible but www. is hidden. When set to Disabled, https:// and www. are both visible.

There was a big discussion about it here

https://bugs.chromium.org/p/chromium/issues/detail?id=881410#c28

And here as well: https://bugs.chromium.org/p/chromium/issues/detail?id=883038

Re-opening.  

It sounds like the bug is that disabling the flag flag #omnibox-ui-hide-steady-state-url-trivial-subdomains makes the https:// visible in the omnibox, whereas the name kind of implies it should only apply to trivial subdomains.

Indeed there is a cross-effect.

So in my testing, both those flags work correctly and independently when set to Enabled or Disabled.

Default means just use whatever the field trials have assigned the client.

Setting one of the flags manually to Enabled or Disabled takes the client out of the normal field trial group and into one of the Forced_Enabled or Forced_Disabled groups, and changes the meaning of "Default".

It's "working as intended" but unfortunate, basically.

Mark - I don't think this is a big enough problem to make it worth it for us to refactor our field trial configs. Do you?

Thanks.

> I don't think this is a big enough problem to make it worth it for us
> to refactor our field trial configs. Do you?
I'm not sure; can you check the data to see how widely those flags are used.  (Don't report them here; this is a public bug.)

If the numbers are high, we might want to simply remove the forcing flag groups from the config, so setting one flag doesn't mess around with the status of another.