MD Settings: Blocked protocol handlers don't show up in content settings. |
||||
Issue descriptionThis is a regression compared to the old Options UI. Repro steps 1) Visit the documentation page at https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers#Example. 2) Open the Devtools console, and paste the following navigator.registerProtocolHandler( "web+burger", "developer.mozilla.org/burger/%s", "Burger handler"); 3) Click "Block" on the popup bubble. 4) Go to chrome://settings/handlers Expected: There should be an entry indicating that a "blocked" protocol handler exists (see screenshot). Actual: Nothing shows up.
,
Jan 4 2018
@wethestill@gmail.com: I can only reproduce for "blocked". If I click allow the handler shows up in the UI. Also after further investigating the code, it seems that the C++ is sending the information to the UI at [1], but the UI TODO at [2] has not yet been addressed. [1] https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/settings/protocol_handlers_handler.cc?l=130 [2] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/site_settings/protocol_handlers.js?l=152 @tbuckley, bettes: Do we have mocks/ideas for how to surface blocked protocol handlers?
,
Jan 19 2018
,
Feb 9 2018
,
Feb 15 2018
Note: This is being considered on CL: https://crrev.com/c/911809. aee@: Could you post screenshots of this on the bug here? I'm happy for this to land, but I'm not 100% clear that we need it. I'm also a bit confused with the current behaviour because it doesn't match my notes from September 2017. I did a full analysis of the protocol handler UX last year, and my notes include this: > Choosing Block, clicking X, or pressing Esc to dismiss the dialog, places the site > in the "ignored protocol handlers" list. The site will never again be allowed to > show a modal popup. Subsequent calls to register in this page load will be ignored, > but after the next page load, the "without user gesture" flow will be used (even > on user gesture). So I was going to say, we should not really need UX for the user to "unblock" a blocked protocol handler, because if they change their mind and want to approve it, they just need to go through the flow again, and then click the "double-diamond" registration button (in the Omnibox), as you would with a site that calls registerProtocolHandler on startup, like Gmail. However, it seems to have changed, because when I tried the web+burger example from this bug report, I don't get a double-diamond icon. It's just blocked forever. This seems like a regression. If we fixed that, would people still feel we need an unblocking UX?
,
Feb 15 2018
> This seems like a regression. If we fixed that, would people still feel we need an unblocking UX? I vote yes, such that we are being consistent with other "site settings" permissions (most of which allow unblocking from Settings). For example see attached screenshot where a user can un-block a location permission both from the Omnibox as well as from the site settings Settings UI.
,
Feb 16 2018
Here is what https://chromium-review.googlesource.com/c/chromium/src/+/911809 looks like with blocked protocol handlers.
,
Feb 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1567ada96f7f3117a218f75ce5a6b7a342f23cfa commit 1567ada96f7f3117a218f75ce5a6b7a342f23cfa Author: Esmael El-Moslimany <aee@chromium.org> Date: Thu Feb 22 04:07:07 2018 Settings: List blocked protocols on chrome://settings/handlers Blocked protocols were not be listed on chrome://settings/handlers. Adding a "Blocked" section which listed all the ignored handlers and allows removal through a menu. R=dpapad@chromium.org, scottchen@chromium.org Bug: 744717 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I0cddc0bf60dcf405ae42224e16d4de199728025a Reviewed-on: https://chromium-review.googlesource.com/911809 Reviewed-by: Matt Giuca <mgiuca@chromium.org> Reviewed-by: Scott Chen <scottchen@chromium.org> Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org> Commit-Queue: Esmael El-Moslimany <aee@chromium.org> Cr-Commit-Position: refs/heads/master@{#538344} [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/custom_handlers/protocol_handler_registry.cc [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/custom_handlers/protocol_handler_registry_unittest.cc [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/resources/settings/site_settings/protocol_handlers.html [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/resources/settings/site_settings/protocol_handlers.js [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/resources/settings/site_settings/site_settings_prefs_browser_proxy.js [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/ui/webui/settings/protocol_handlers_handler.cc [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/browser/ui/webui/settings/protocol_handlers_handler.h [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/test/data/webui/settings/protocol_handlers_tests.js [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/test/data/webui/settings/test_site_settings_prefs_browser_proxy.js [modify] https://crrev.com/1567ada96f7f3117a218f75ce5a6b7a342f23cfa/chrome/test/data/webui/test_browser_proxy.js
,
Feb 26 2018
Is this issue fixed now?
,
Feb 26 2018
It looks good in master. marking as fixed, thx |
||||
►
Sign in to add a comment |
||||
Comment 1 by wethest...@gmail.com
, Jan 2 2018