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

Issue 790958 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Regression
Team-Security-UX



Sign in to add a comment

Regression: Unwanted text continuation is seen on permission bubble of screencastify extension

Project Member Reported by kebalaji@chromium.org, Dec 1 2017

Issue description

Chrome Version: 64.0.3280.5/10172.0.0 dev-channel Paine, Celes, Kip
OS:Chrome OS

What steps will reproduce the problem?
(1)Sign-in to user>> Install screencastify extension and click on the screencastify icon beside omnibox
(2)Then click on 'Set up Camera Access' and observe the Permission bubble

Actual: Unwanted text continuation is seen in the beginning
Expected: Instead it should not be seen 

This is a Regression as same is working fine in M63

@tapted: Please confirm the issue
 
actualbubble70.png
83.0 KB View Download
ActualBubble80.png
70.8 KB View Download
ExpectedBubble.png
88.0 KB View Download
Cc: tapted@chromium.org
Labels: Needs-Bisect
Owner: ----
Status: Untriaged (was: Assigned)
Cc: aelder@chromium.org ellyjo...@chromium.org
Owner: dominickn@chromium.org
checking the git log, this is most likely

"Elide the permission bubble title from the head of the string."
in https://chromium-review.googlesource.com/768312

there's also "Show extension name in permission bubble." and "views: use title font for permission bubble title in harmony mode"

But this should probably just be merged into  Issue 774438 .
Cc: benwells@chromium.org raymes@chromium.org
Components: -UI>Browser>Bubbles UI>Browser>Permissions>Prompts
+benwells, +raymes for thoughts

This is an interaction between crrev.com/c/768312 (elide permission bubble title from the head) and crrev.com/c/677983 (show extension name in permission bubble).

Eliding the title like this is important when displaying a URL requesting permission. However, it doesn't need to happen if we have a non-URL title like an extension name. So I think the right solution is that the permission bubble title should be allowed to be multiline and not elided for extensions. Otherwise, we must retain the elision behaviour for security purposes (we couldn't find another good solution for displaying the URL properly, see  Issue 774438 ).
Cc: mgiuca@chromium.org
I think your suggestion sounds reasonable (allow extension names to by multiline but keep URLs as a single elided line). 

Would it be good to get UX input here though? 
I might put together the fix proposed in c#3 to unblock beta, and longer term we can explore a different solution. WDYT?
sgtm

A related comment: previously it looks like we would push the "wants to" text to a new line for long URLs? That gave a bit more space for the URL. I'm not sure if we want to keep that as right now it seems quite a small space.

With permission delegation we may be able to get rid of the URL altogether which would really nicely solve all these problems..
Status: Assigned (was: Untriaged)
Since this one is assigned to dominickn, I am changing the status from untriaged to assigned. Feel free to change back if that's incorrect.
Status: Started (was: Assigned)
Attached is what extension web permission requests look like after my fix. URLs will continue to be elided from the head if they are too long.
Screenshot from 2017-12-06 14:34:44.png
59.1 KB View Download
Project Member

Comment 9 by bugdroid1@chromium.org, Dec 6 2017

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

commit 693c964b23fbc82049b2a2d795ecabe40a8ff017
Author: Dominick Ng <dominickn@chromium.org>
Date: Wed Dec 06 05:15:29 2017

Do not elide non-URL display origins in permission prompts.

http://crrev.com/c/768312 addresses a URL spoofing risk in permission
prompts by eliding display origins in prompts from the HEAD. This means
that the most significant part of the origin will be displayed if the
entire origin is too long. http://crrev.com/c/677983 replaces the
extension URL with the extension title when extensions request web
permissions. These two CLs mean that extensions with long names have
their titles elided, which is undesirable.

This CL addresses the issue by not eliding the display origin if it
isn't a URL. This requires a minor API change to
PermissionPrompt::GetDisplayOrigin, making it return a small struct
containing the display origin string and a bool indicating whether or
not the string is a URL. The struct is neccesary to ensure that the bool
state is calculated at the same time as the display origin.

BUG= 790958 
TBR=tapted@chromium.org

Change-Id: Icdf37feae4448f1fdd7044c7bbe690989f118023
Reviewed-on: https://chromium-review.googlesource.com/807606
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522012}
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/permissions/permission_request_manager.cc
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/permissions/permission_request_manager.h
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/ui/cocoa/permission_bubble/permission_bubble_controller_unittest.mm
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/ui/permission_bubble/permission_bubble_browser_test_util.cc
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/ui/permission_bubble/permission_bubble_browser_test_util.h
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/ui/permission_bubble/permission_prompt.h
[modify] https://crrev.com/693c964b23fbc82049b2a2d795ecabe40a8ff017/chrome/browser/ui/views/permission_bubble/permission_prompt_impl.cc

Hi, I don't see that this made yesterday's DEV RC build.  Does this need a merge request for M64? 

M64 beta is targeted for next Tuesday (12-Dec); anything we can do to close this out and/or retag as stable block is appreciated.   I'll ping the owner as well.  Thanks!

c#10: this has only just made Canary on Windows and Mac as of today, meaning that it probably needs at least another day before requesting a merge to it's safe.
Understood.  We're getting close for making the Merge for CrOS...  Fingers crossed.  Thanks again.
Labels: Merge-Request-64 OS-Linux OS-Mac OS-Windows
Requesting merge of c#9 to M64 to address a beta blocker. It's been on canary for a couple of days now with no issues.
Project Member

Comment 14 by sheriffbot@chromium.org, Dec 9 2017

Labels: -Merge-Request-64 Hotlist-Merge-Approved Merge-Approved-64
Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Comment 15 by bugdroid1@chromium.org, Dec 10 2017

Labels: -merge-approved-64 merge-merged-3282
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94

commit f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94
Author: Dominick Ng <dominickn@chromium.org>
Date: Sun Dec 10 19:39:43 2017

Do not elide non-URL display origins in permission prompts.

http://crrev.com/c/768312 addresses a URL spoofing risk in permission
prompts by eliding display origins in prompts from the HEAD. This means
that the most significant part of the origin will be displayed if the
entire origin is too long. http://crrev.com/c/677983 replaces the
extension URL with the extension title when extensions request web
permissions. These two CLs mean that extensions with long names have
their titles elided, which is undesirable.

This CL addresses the issue by not eliding the display origin if it
isn't a URL. This requires a minor API change to
PermissionPrompt::GetDisplayOrigin, making it return a small struct
containing the display origin string and a bool indicating whether or
not the string is a URL. The struct is neccesary to ensure that the bool
state is calculated at the same time as the display origin.

BUG= 790958 
TBR=tapted@chromium.org

Change-Id: Icdf37feae4448f1fdd7044c7bbe690989f118023
Reviewed-on: https://chromium-review.googlesource.com/807606
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#522012}(cherry picked from commit 693c964b23fbc82049b2a2d795ecabe40a8ff017)
Reviewed-on: https://chromium-review.googlesource.com/818361
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#114}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/permissions/permission_request_manager.cc
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/permissions/permission_request_manager.h
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/ui/cocoa/permission_bubble/permission_bubble_controller_unittest.mm
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/ui/permission_bubble/permission_bubble_browser_test_util.cc
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/ui/permission_bubble/permission_bubble_browser_test_util.h
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/ui/permission_bubble/permission_prompt.h
[modify] https://crrev.com/f6ff0334b10c3d563f06f9dc0c6d53592cf4ec94/chrome/browser/ui/views/permission_bubble/permission_prompt_impl.cc

Status: Fixed (was: Started)
Fixed in c#9 and merged to M64 in c#15.
Labels: TE-Verified-M64 TE-Verified-64.0.3282.24
Verified this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.6 using chrome latest dev #64.0.3282.24 by following steps mentioned in the original comment and observed the fix is working as intended, hence marking it as TE-Verified label for M64.
790958.png
14.2 KB View Download
Labels: TE-Verified-64.0.3282.134
Verified this issue on Chrome OS using latest beta 64.0.3282.134/10176.65.0 on Kip, Reks, Daisy with the steps mentioned in Comment#0 and issue is fixed. 

Thanks!
790958.png
72.7 KB View Download

Sign in to add a comment