New issue
Advanced search Search tips

Issue 879048 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocking:
issue 869928


Participants' hotlists:
Launcher-Polish


Sign in to add a comment

UX: Ash Shelf Bubbles: Anchoring offsets should be consistent ?

Project Member Reported by tapted@chromium.org, Aug 30

Issue description

Chrome Version       : 70.0.3528.4
OS Version: Chrome

See also Issue 805612  (new shelf ui)

Context: in https://crrev.com/c/1186218 I experimented with consolidating some seemingly-unused logic for ShelfTooltipBubble for catering for an arrow on the bubble, which no longer exists.

Removing that logic makes the tooltips hug the shelf rather than positioning away from it to leave room for an arrow. See screenshots at https://crbug.com/869928#c6 . The consensus is that the screenshots "look weird". Although, it would be consistent with the IME and stylus popup bubbles. However, there are other bubbles that do other things.


I'm wondering whether we should try to remove this complexity and just have a single constant for all "bubbles" appearing above the shelf due to hover/touch/click. It's currently a bit of a mess.


There is
 - ShelfTooltipBubble --> ash::kBubblePaddingHorizontalBottom = 6;
 - Right-click menus --> views::MenuConfig::touchable_anchor_offset = 8
 - IME popup, stylus palette --> 0
 - unified system tray -->tray->shelf()->GetSystemTrayAnchor()->GetBubbleAnchorInsets() = 9 (from constants in views/bubble_border.cc)


tray->shelf()->GetSystemTrayAnchor()->GetBubbleAnchorInsets() is complex, but the distance-from-shelf offset boils down to "9". First there is some logic to find the distance from the button *on* the shelf that shows the tray to to the edge of the shelf. That's from -1*TrayBackgroundView::GetInsets(), which ... comes from  ash::StatusAreaWidgetDelegate::SetBorderOnChild(), which is also complex, but it's "basically"

 const int padding = (ShelfConstants::shelf_size() - kTrayItemSize) / 2;

which is (chromeos::switches::ShouldUseShelfNewUi() ? kShelfSizeNewUi : kShelfSize) - kTrayItemSize) / 2
which is [for me] ((false ? 56 : 48) - 32) / 2
which is (48 - 32) / 2  ==  16 / 2  ==  8  \o/


.. unless we run with --shelf-new-ui, which makes it 12.

The remaining offset comes from TrayBubbleView::GetBorderInsets(), which comes from BubbleBorder::GetInsets(), which is GetBorderAndShadowInsets(nullopt), which is kShadowBlur + kBorderThicknessDip + kShadowVerticalOffset = 6 + 2 + 1 == 9  \o/
 
Note complexity also currently comes from the shelf alignment (I assumed a bottom-aligned shelf above).

But, e.g., the tray popup has a different anchoring offset for a vertically (i.e. left/right) aligned shelf. It's based on where the outside "edge" of the bubble _shadow_ is, which (from constants) extends out 9 pixels below the bubble but only 7 pixels to either side. So the bubble is further away from a bottom-aligned shelf than a side-aligned shelf.

(note it probably also doesn't make sense to use kBorderThicknessDip for the unified system tray since it doesn't really have a border).

Basically, the offset used for the tray popup is a coincidence, currently made up via arithmetic on eight different constants, which happens to end up with a reasonable result.

It might instead be nice to say "the offset should be 8 DIPs" :)
Cc: newcomer@chromium.org
Glad you decomposed all of this! 
Owner: manucornet@chromium.org
Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sign in to add a comment