Subsequent clicks on non-http links in a DevTools extension do not work
Reported by
itsgoi...@luzer.sk,
Nov 12
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15 Steps to reproduce the problem: - install the minimal example extension - https://github.com/itsgoingd/chrome-devtools-links-bug - click on the mailto link - default mail app opens as expected - click on the mailto link again - nothing happens What is the expected behavior? What went wrong? I'm working on a DevTools extension that includes a panel with links to open files in editor using the editor's url handler, eg. `subl://open?url=file:///whatever` to open a file in Sublime Text. First time clicking on the link works correctly, but subsequent clicks on the same or other non-http links on the page have no effect. This also affects the native `mailto:` url handler. I've found out following "workarounds": - switching to a different tab in Chrome and back will make the links work (just for a single click, then they break again) - undocking (and optionally re-docking) dev tools makes the links work (even for subsequent clicks) I've made a minimal DevTools extension demonstrating this behavior here - https://github.com/itsgoingd/chrome-devtools-links-bug Did this work before? N/A Chrome version: 72.0.3608.0 (Official Build) canary (64-bit) Channel: canary OS Version: OS X 10.14.1 Flash Version:
,
Nov 13
Repro note: after the mail app opens simply minimize or close it so that no additional keys or clicks are sent into the original devtools window. Bisected to r286301 "Revert of Fix the handling of user gestures for external protocol handler dialogs" Landed in 38.0.2108.0
,
Nov 13
Tried testing the issue on chrome reported version# 72.0.3608.0 using Mac 10.14 with steps mentioned below: 1) Launched chrome reported version and navigated to URL: https://github.com/itsgoingd/chrome-devtools-links-bug 2) Downloaded the zip file, extracted it and loaded the file into chrome://extensions 3) Clicked on extension icon, but didn't observed any link like 'maito' Observations: Also tested the issue by logging into gmail with valid credentials, but didn't observed anything related to it. @Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it in better way. Thanks!
,
Nov 13
viswa.karala@, open devtools on any page, then switch to "devtools-links-bug" sub-tab in devtools.
,
Nov 13
Could you repro this w/o devtools on a regular extension?
,
Nov 13
re #5, nope, normal extension page doesn't exhibit the bug.
,
Nov 16
,
Dec 2
In my "real" use-case this leads to even worse behavior where Chrome sometimes completely crashes when clicking on these links. I haven't been able to reproduce this in the sample extension, the "real" extension is a fairly complex angular app so it might be just a coincidence, but just in case here are a few crash ids: 6097f9ad-cf4e-453e-bfd6-129dc7cfbae3 4969c0a0-eaae-47f0-8b6f-64f8869078fb 4fd51e78-6c3b-465f-a6e6-a60f1c0ec74d e6fd8ca3-46a8-41e9-b907-79bb0085317a 159953f0-6ce8-4dbd-b78e-82d1c3c42b1d db92f6e9-5617-4f53-a620-93f5a998941c 04b118c1-6a7d-40bd-8350-23fef6cf658b Though they all say "upload requested by user, not yet uploaded", not sure when they will be uploaded or how do I force them to be uploaded?
,
Dec 2
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
,
Dec 4
Can you please check if you have reports disabled https://support.google.com/chrome/answer/96817 Enable them and provide server crash ids? Thanks!
,
Dec 4
Crash ids from my last comment should now be uploaded.
,
Dec 4
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
,
Dec 4
Can you please share the server ids. They are 16 character long hex strings. You can find them on chrome://crashes page.
,
Dec 4
,
Jan 7
Mac triage: WontFix - we can't debug this without server-side crash IDs; see #13.
,
Jan 7
Why WontFix if the crashing is not the actual reported issue? You even have a CL bisected in #2.
,
Jan 7
I've posted crash ids in #8 (https://bugs.chromium.org/p/chromium/issues/detail?id=904457#c8), though the crash might not even be related to the original issue.
,
Jan 7
Those are local IDs which cannot be used here. Anyway, if the issue won't be reopened in a few days, resubmit it.
,
Jan 7
Oops, my bad. Reproduced the crash again in the latest Canary, simply clicking on the atom:// link in the sample extension in #1. Uploaded Crash Report ID 9f17f24be9895759 (Local Context: 25f95d67-0c79-46f4-b4a0-d6658d7eea46) |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Nov 13