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

Issue 811036 link

Starred by 7 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

DevTools: expose element inspection API for devtools extensions

Reported by rummsan...@gmail.com, Feb 10 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
NA

What is the expected behavior?
ATM there is nothing in `chrome.devtools.*` extension API that allows extensions to make use Chrome's native DOM inspector (the thing toggled with `CTRL + SHIFT + C`).

As a consequence lot of devtools extensions have to implement in-house solutions, including but not limited to, React DevTools, Vue DevTools, Augury for Angular etc. where you click on a crosshair like icon -> pick an element and the respective extension shows information about the element.

I'm working on something similar and think it'd nice if there was something like `chrome.devtools.inspector.*` that allowed an extension to have it (programmatically) pick elements from page, without jumping to `Elements` panel.

What went wrong?
NA

Did this work before? N/A 

Chrome version: 63.0.3239.132  Channel: stable
OS Version: 10.0
Flash Version:
 
Labels: Needs-Triage-M63
Components: -Platform>DevTools Platform>DevTools>Platform
Summary: DevTools: expose element inspection API for devtools extensions (was: [Feature] Expose DOM inspector API to devtools extensions)
I thought there was a workaround right now for extensions to identify the currently selected element. If there is, wouldn't that work.

(Yes, a 1st class API would be nicer..)
Cc: paulir...@chromium.org sindhu.chelamcherla@chromium.org
@paulirish: Please let us know whether this is a Feature request or does this issue requires triaging from TE team? 

Thanks!
Labels: Triaged-ET Needs-Feedback
paulirish@ Request you to please respond to comment #3, which will help in further triaging of the issue.

Thanks..
@paulirish
> I thought there was a workaround right now for extensions to identify the currently selected element.

Well there is that `$0` workaround, but honestly an ugly one :(
Project Member

Comment 6 by sheriffbot@chromium.org, Feb 20 2018

Cc: susan.boorgula@chromium.org
Labels: -Needs-Feedback
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
Since it's been dormant for a while. I just wanted to say that I'm more than happy to begin hacking on this as long as someone can give a greenlight to this (with design goals in context)
Owner: caseq@chromium.org
caseq wdyt? want to propose an API for this and rummsandhu can try out a patch?
caseq@ A Gentle ping...
Request you to provide an update on this issue.

Thanks..
I'm willing to withdraw this request if https://bugs.chromium.org/p/chromium/issues/detail?id=834203 gets approved/implemented
Cc: phanindra.mandapaka@chromium.org
Labels: TE-NeedsTriageHelp
As per comment #09 and #10 we are unable to triage this issue.Hence adding 
TE-NeedsTriageHelp label to this issue for further  triage.

Thanks!
Just pinging for an update?

:(
Status: Assigned (was: Unconfirmed)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sign in to add a comment