New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 7
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 904457: Subsequent clicks on non-http links in a DevTools extension do not work

Reported by, Nov 12

Issue description

UserAgent: 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 -
- 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 -

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:
Labels: Needs-Triage-M72

Comment 2 by, 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

Comment 3 by, Nov 13

Labels: Triaged-ET Needs-Feedback
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:
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.

1.1 MB View Download

Comment 4 by, Nov 13

viswa.karala@, open devtools on any page, then switch to "devtools-links-bug" sub-tab in devtools.

Comment 5 by, Nov 13

Components: -Platform>DevTools Blink>HTML>CustomHandlers
Could you repro this w/o devtools on a regular extension?

Comment 6 by, Nov 13

re #5, nope, normal extension page doesn't exhibit the bug.
1.2 KB Download

Comment 7 by, Nov 16

Components: Platform>DevTools

Comment 8 by, 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:


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?

Comment 9 by, Dec 2

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot

Comment 10 by, Dec 4

Labels: Needs-Feedback
Can you please check if you have reports disabled
Enable them and provide server crash ids? Thanks!

Comment 11 by, Dec 4

Crash ids from my last comment should now be uploaded.

Comment 12 by, Dec 4

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot

Comment 13 by, Dec 4

Can you please share the server ids. They are 16 character long hex strings. You can find them on chrome://crashes page.

Comment 14 by, Dec 4

Labels: Needs-Feedback

Comment 15 by, Jan 7

Status: WontFix (was: Unconfirmed)
Mac triage: WontFix - we can't debug this without server-side crash IDs; see #13.

Comment 16 by, Jan 7

Why WontFix if the crashing is not the actual reported issue?
You even have a CL bisected in #2.

Comment 17 by, Jan 7

I've posted crash ids in #8 (, though the crash might not even be related to the original issue.

Comment 18 by, 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.

Comment 19 by, 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