From your screenshot, it does appear that it is missing the pixel overlap for the line-of-death here. I think some of the new UI changes have gotten rid of the old chevron-style design for these popovers, which may exacerbate this.

Could you go to chrome://version and copy-paste the list of variations here? It looks like you might be in an inconsistent browser UI state where some of the new UI features are not all enabled.

[Specifically adding Team-Security-UX label to make sure Enamel can track this.]

Variations:
6a89113b-ccb9a6a5
d01ab0d3-f23d1dea
59aeb88e-3f4a17df
ebeb14fc-3f4a17df
34a6bf44-3d47f4f4
64da5c1e-f23d1dea
b1681d28-803f8fc4
9041608a-f23d1dea
38eb801c-3f4a17df
7c1bc906-8122a015
47e5d3db-3d47f4f4
125b7f68-39db89b5
d442dfb7-41afa35c
1149accc-3f4a17df
4dc30737-b8a5ea08
a582a1b8-ad75ce17
3042ad4b-ca54bb47
98be3390-d93a0620
267255c3-f4950e99
116c6887-d7bc6f45
44827ee5-3f4a17df
edbcf7c5-90fc1f8
5485fc4d-ca7d8d80
9773d3bd-f23d1dea
93731dca-3d47f4f4
9e5c75f1-e10fa620
f79cb77b-3f4a17df
4ea303a6-ecbb250e
bcc34a89-3f4a17df
6e6e0c7e-f23d1dea
d92562a9-cfe3c2ea
4da5ae82-f23d1dea
2c1d398c-3f4a17df
6973a1cf-3f4a17df
4932440-d21eb72d
ff29b1bd-54dd8886
da460ac8-3f4a17df
4bc337ce-69465896
d1466cda-f23d1dea
9a2f4e5b-3fe32955
17507c76-3f4a17df
494d8760-52325d43
3ac60855-486e2a9c
f296190c-f2ffe33a
4442aae2-d7f6b13c
ed1d377-e1cc0f14
12e17bc5-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-6754d7b7
e7e71889-e1cc0f14
469cffe2-21549ebe
3a4029d-ca7d8d80
81c6897f-3f4a17df


Cheers.

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

Thanks! I can replicate this on ChromeOS 68 Beta (without fiddling with any flags). The behavior is also the same on 69.0.3494.0 dev. Nothing in your list of variations looks like it would affect this.

On Linux Chrome 68 Beta (trying to match the version and variations you're in) I can't replicate, but the top Chrome UI is different in M68 (it looks like ChromeOS 68 Beta has some of the new UI design enabled by default). I also can't replicate it in Linux or Mac Chrome 69. Because of that, I'm marking this back as ChromeOS only, but will keep tracking it as a Security-UX bug. Also, tentatively calling this Severity-Medium.

Specifically, I see the following with the line-of-death [1]:

Good
- The Page Info bubble correctly overlaps the line-of-death
- The bookmark bubble correctly overlaps the line-of-death

Bad
- Extension popovers do not overlap the line-of-death and in fact appear to have a ~1px gap between the bottom of the top chrome and the content area
- The right-click context menu for an extension has no gap but also does not overlap the line-of-death
- The main Chrome menu has no gap but also does not overlap the line-of-death

I'm not familiar with the top chrome UI differences between Linux Chrome and ChromeOS Chrome, so adding rkc@: Do you know what might be causing this or who would be a good owner?

Also adding meacer@ as another Security-UX team member who may have ideas.

[1] https://textslashplain.com/2017/01/14/the-line-of-death/

Forgot to upload the screenshots of the UI in question.

Deleted: extension-context-menu.png 25.8 KB

	extension-context-menu.png 25.8 KB View Download

Deleted: extension-popover.png 45.2 KB

	extension-popover.png 45.2 KB View Download

Deleted: chrome-menu.png 58.4 KB

	chrome-menu.png 58.4 KB View Download

Deleted: bookmark-bubble.png 28.9 KB

	bookmark-bubble.png 28.9 KB View Download

Deleted: page-info-bubble.png 59.3 KB

	page-info-bubble.png 59.3 KB View Download

Notably, even on Chromium 67.0.3396.99 on Linux, the degree to which extension popovers and bookmark/page info bubbles overlap the LoD is different. It seems to me that these Y offsets should be calculated relative to the LoD or the bottom of the chrome, from the same set of constants.

Yep, I don't think the overlap has ever been very consistent, although I think this is more of an issue now that the chevrons are gone :-/

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

This bug needs to be fixed and merged back within the next week or it will start blocking our R68 stable release.

Whom is the right owner for this?

groby@ Do you know who could be a good owner for this? This is Views UI but it appears to only be manifesting on ChromeOS.

xdai@ is this something you or someone on your team can look into?

It seems to me that it might caused by the disappeared chevrons. Anyone know if the chevrons were removed in 68?

sammiequon@, can you take a look? It's a regression in 68 and we probably should either find the CL that caused it or find a fix for it. 

Yes, the designs for GM2 Refresh UI do not include the chevrons (per go/crux-gm2). However, these bubbles are clearly misaligned vertically compared to prior UI and to non-Chrome OS platforms. The chevrons are a UI decision (which we may want to debate later), while the alignment here is a bug.

+afakhry

This was in here for a while but behind the flags SecondaryUiMd and --top-chrome-md=material-touch-optimized.

I bisected to https://chromium-review.googlesource.com/c/chromium/src/+/961722. Ahmed, could you take a look?

+pkasting@, +ainslie@ Is there a spec for the Y-coordinate of those popovers?

+bettes@ will know 

Things inside the omnibox are supposed to align with the base of the omnibox.  For things outside the omnibox, it's less clear.  On non-touchable, they happen to line up with the base of the omnibox.  I don't think it's necessarily a bug that on touchable they line up with the base of the toolbar as in comment 6.

The sentiment behind wanting to make things unspoofable is a good and noble one, but I would be surprised to find any user testing showing that the particular methods we've been using have been effective.  I am skeptical that the actual (as opposed to theoretical) user harm of shipping this rises to the RBS level.

Since this is only occurring for less important UI (extension popovers and the chrome menu, rather than for e.g. Page Info where we'd have stronger consequences for spoofing), I'd be fine with lowering this to Severity-Low and removing RBS.

I would still argue that this is a bug -- Chrome's UI has generally tried to maintain this guarantee in the past (such as with the use of chevrons) and all other platforms (and even other UI on this platform) ensure an overlap.

It's true, we tried pretty intentionally to give some indicator, and moved away from doing that.  I'm just skeptical that we did much good with the indicators (and I think the designers are too).  My totally-unproven hypothesis is that there's a large group of people who still believed spoofed versions, and a smaller group of people who wouldn't believe the spoofed versions now even though it's theoretically harder to tell them apart.

It may be the case that a generic user could likely fall for a spoof even with the previous designs, if they are not a regular user of extensions with popovers, but for the subset of users who pay attention to this as an operational necessity (I have seen training slides at workplaces specifically talking about spoofed extension popovers), the reward/risk of a spoof of this sort is high.

Just my two cents.

I could probably fix this, assuming it is a simple matter of changing the y offset calculation. The question of whether or not the popover ovelaps the LoD seems to be a minor/incidental outcome of the new design, so changing it to overlap (like the other popovers/bubbles) should be equally minor a change.

I can no longer repro this issue. The top line of the popup is always above the toolbar bottom separator. Attached are some examples in different MD modes.

I believe this was fixed by pbos@ in https://chromium-review.googlesource.com/c/chromium/src/+/1152525.

pkasting@ can you please confirm this is WAI before I close this issue?

Deleted: material-touch-optimized.jpg 291 KB

	material-touch-optimized.jpg 291 KB View Download

Deleted: material-refresh.jpg 306 KB

	material-refresh.jpg 306 KB View Download

Deleted: material-refresh-touch-optimized.jpg 319 KB

	material-refresh-touch-optimized.jpg 319 KB View Download

From your screenshots, I agree that that this appears to be fixed now (also, I hadn't previously seen  Issue 800372 ). I don't have a touchable device to test on myself right now however.

Can confirm that the current Beta channel image on the same Chromebook (touch-enabled Cyan) no longer exhibits this issue (though the size of the UI seems to have shrunk in general, so it's possible this is due to something else, maybe the device is no longer being treated as "touch-optimized").

Deleted: Screenshot 2018-08-28 at 15.04.32.png 132 KB

	Screenshot 2018-08-28 at 15.04.32.png 132 KB View Download

Re #25: https://chromium-review.googlesource.com/c/chromium/src/+/1152525 intentionally fixes it (I just heard about it through the grapevine and didn't know that there was a canonical bug for it). Since this is Severity-Low can we wait for this to just trickle in instead of backporting it?

Re #27: I believe M69 changes ChromeOS behavior so that only certain tablet devices are "touch-enabled" (not just if they have a touch screen). As a result Cyan probably no longer thinks it's a touch-only device and reverts back to using non-touch sizes. This restricts the number of devices that are impacted by this.

Let me know if anyone feels strongly that this warrants a merge, otherwise I think this can be left alone. Thanks!

Great, thanks! Since that fix made M70 I think we'd be fine not merging back to M69 Stable for this (and I don't know if there are any other respins planned).

Thanks for the report aaron@! I'm afraid that our VRP panel declined to reward for this (as we often tend not to for low severity bugs).

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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