cado007@ Thanks for the issue.

Request you to provide a sample extension where this issue can be reproduced which will help in further triaging of the issue.

Thanks..

Yes @susan.boorgula@chromium.org, , just use this attached extension in Dev mode.

1- Install the extension in dev mode 

2- Click on the button extension and the errors will appear in hrome://extensions

3- Click on the button to open the devtools and nothing happen except errors in the console.

Regard !

Deleted: AdvancedPageLanguageSwitcher.zip 225 KB

AdvancedPageLanguageSwitcher.zip 225 KB Download

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

That error occurred in the popup window, which doesn't exist anymore after the popup was closed. The same bug is present in Material Design chrome://extensions. As for a possible solution, I guess Chrome should either deactivate "View in devtools" action button when this error is selected or display a message somewhere that explains why it's impossible to open devtools for this error. 

"Chrome should either deactivate "View in devtools" action button when this error is selected or display a message somewhere that explains why it's impossible to open devtools for this error."

@woxxom@gmail.com  I agree with you, it was very confusing and it happen also like you said in with the polymer design.

Able to reproduce this issue on reported version 66.0.3359.117 and latest canary 68.0.3406.0 with extension given in comment#3. i.e; On clicking on view in developer tools nothing happens.

Observing Inconsistent behaviour as error is seen only on some builds. As issue is reproducible on latest builds marking as Untriaged. 

Thanks!

Able to repro.
Devlin, can you please take a look.

Looking at the code, this does seem pretty busted.  We check if the renderer is present at the time that we dispatch the event to the chrome://extensions page with the error details (including the id for the renderer), but we never monitor the renderer to make sure it sticks around.

Possible paths forward:
1. Have the developerPrivate API actually monitor frame creation, deletion, and navigation for any errors that are associated with extensions, and dispatch events to the front end accordingly, having it then update whether the error is inspectable.  This is the most technically correct approach, but is hard, and a very non-trivial amount of code to add.
2. Introduce a canInspect method on the developerPrivate API, and call that when the error is expanded.  This would get us 75% of the way there and is much simpler to implement, but there are still broken cases (the 25%).  Specifically, if the user has the same error open too long, the renderer may go away, and there may also be visible flashing of the button when querying if the view is inspectable.  Additionally, the navigation case is tricky to catch here (because if the renderer navigated to the same URL, it would be transparent at this time).
3. Remove the "Open in devtools" button.  Assume that the error console has done its job by recording the error, stack trace, URL, etc, and let the developer take it from there.

Honestly, I'm kind of leaning towards 3.  I don't know if this is a very valuable aspect of the error console, and I think it may be more effort than it's worth to get this part right.

dpapad@, do you have any thoughts?

(A pseudo-option 4 is to remove it for M68, when error console is going stable, and potentially add it back for a later release.  For us to do that, we'd have to agree that it is worth pursuing path 1 or 2 at a future date.)

This seems to be a duplicate IIUC. Merging the two bugs so we can continue the discussion in a single thread.