Issue metadata
Sign in to add a comment
|
Regression: Unwanted text continuation is seen on permission bubble of screencastify extension |
||||||||||||||||||||||||
Issue descriptionChrome 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
,
Dec 4 2017
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 .
,
Dec 4 2017
+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 ).
,
Dec 4 2017
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?
,
Dec 5 2017
I might put together the fix proposed in c#3 to unblock beta, and longer term we can explore a different solution. WDYT?
,
Dec 5 2017
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..
,
Dec 5 2017
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.
,
Dec 6 2017
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.
,
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
,
Dec 7 2017
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!
,
Dec 7 2017
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.
,
Dec 8 2017
Understood. We're getting close for making the Merge for CrOS... Fingers crossed. Thanks again.
,
Dec 8 2017
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.
,
Dec 9 2017
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
,
Dec 10 2017
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
,
Dec 10 2017
Fixed in c#9 and merged to M64 in c#15.
,
Dec 12 2017
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.
,
Jan 31 2018
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! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tapted@chromium.org
, Dec 4 2017Labels: Needs-Bisect
Owner: ----
Status: Untriaged (was: Assigned)