New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 870002 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 7
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

chrome://flags/#upcoming-ui-features disables Touchable Refresh

Project Member Reported by tommycli@chromium.org, Aug 1

Issue description

For ChromeOS Dev channel, if you just boot it up on a touch device like a pixelbook with no flags, you'll get the Touchable Refresh UI mode with enlarged controls for touch.

However, if you enable chrome://flags/#upcoming-ui-features, you will revert back to REGULAR MD Refresh instead of Touchable Refresh.

I did not expect this behavior, and I think it's unintended.

This may also negatively affect finch trials, depending on the root cause.

Sending to robliao@ for triage. I think we will want to fix this and merge to 69.
 
Cc: jdonnelly@chromium.org
One more comment.

As long as #upcoming-ui-features is enabled, setting #top-chrome-md to Touchable has no effect. That definitely does not seem intended.
#upcoming-ui-features forces Material Refresh as a one stop shop of setting all of the flags to the same state. 

Finch trials will not and should not be using #upcoming-ui-features for deployment, so experimentation should work fine.
Cc: groby@chromium.org
I think the general sentiment is we will shutdown #upcoming-ui-features for M70.

If usage of #upcoming-ui-features blocks testing, ping back on this bug and we'll reconsider adding support for touchable.
I think I was unclear in c#1. I meant setting #top-chrome-md to "Touchable Refresh" has no effect when #upcoming-ui-features is on.

Making #upcoming-ui-features force Material Refresh on Touchable devices seems a bit unintuitive since we are planning to ship Touchable Refresh on Touch ChromeOS devices for 69.

I would expect "upcoming-ui-features" to set top-chrome-md to Touchable Refresh for those devices.

Moreover, it seems like #top-chrome-md should still be able to override #upcoming-ui-features to set Touchable Refresh.
Labels: -Pri-1 Pri-2
This is the fun issue with meta-flags, which one wins?

Because the goal was to have a one-stop-shop, #upcoming-ui-features necessarily needed to override any setting for #top-chrome-md (as it may not have been set to default in the past).

Now that #top-chrome-md has Material Refresh as default, #upcoming-ui-features should have less of a heavy hand.

I can imagine making a change for M70, but I don't think it will meet the M69 bar.
Alrighty - thanks for the consideration.

It's not blocking my testing - just surprising behavior.
Project Member

Comment 8 by bugdroid1@chromium.org, Aug 6

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc273a4f9bf82ee2ccda28a92b75b5c18964fa17

commit dc273a4f9bf82ee2ccda28a92b75b5c18964fa17
Author: Robert Liao <robliao@chromium.org>
Date: Mon Aug 06 20:57:45 2018

Relax #upcoming-ui-features Setting of #top-chrome-md Flags

Setting #upcoming-ui-features previously locked you into Material
Refresh. If you have a touchable device, you probably want
Material Refresh Touchable.

This change also allows users to choose between Material Refresh
and Material Refresh Touchable if #upcoming-ui-features is set.

BUG= 870002 

Change-Id: I8006fcaab8c6f8da299b77fafb9e3418f18bbfa5
Reviewed-on: https://chromium-review.googlesource.com/1159239
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Robert Liao <robliao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580982}
[modify] https://crrev.com/dc273a4f9bf82ee2ccda28a92b75b5c18964fa17/ui/base/material_design/material_design_controller.cc

Status: Fixed (was: Started)

Sign in to add a comment