Fundamentally, we won't be able to open dev tools for a closed renderer.  We'll need to update the UI when an error is no longer inspectable, have the UI query whether an error is inspectable before showing the button, or handle the failure and indicate to the user that the renderer no longer exists.

What did the prior UI do in this case?

The old UI also seems to throw the same error (just tried). So this is an improvement we can make compared to the old UI, but not strictly needed for parity.

Grouping all error-console related bugs into a hotlist, so that we can better keep track of them.

Note that if you reload the extensions page, the button will correctly be disabled, because when the error is fetched from the back-end, it has a "canInspect: false" property.


But in the case that you
   1) have the extension page open,
   2) trigger an error in a new tab 
   3) then close that tab
I don't think there's currently a way to know to hide the button when the context tab gets closed, because once the error comes into the page with "canInspect: true", closing the tab doesn't send an update to the error that changes canInspect to false. In other words, canInspect always stays true until you reload the extensions page.

A few solutions I can think of:

1) Push - 
Edit the handler to send a webUI event with the updated error info (but this would require observing the context tab to know when it gets closed, if possible).

2) Pull - 
Re-fetch the errors in the background on an Interval to get the most updated canInspect value.

3) Lazy - 
Just wait until the user clicks the button, catch the error, and disable the button then. Then throw a toast saying "view no longer exist" or something.

(1 is most ideal and most difficult, 3 is least ideal and least difficult).

Thoughts?

 Issue 836405  has been merged into this issue.

Copy-pasting from the duped issue.

-----

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.)

-----

(looks similar to Scott's proposals, though he added a "lazy" suggestion, and I added a "remove it" suggestion)

Any opinions, folks?

Thanks for presenting the alternatives. Removing the "view in developer console" button SGTM (in general, not just for M68), given the trade-offs described above.

Sounds good.  I'll take this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1aa78e0111c32de48ed588a71f7faa4cb83d043f

commit 1aa78e0111c32de48ed588a71f7faa4cb83d043f
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Wed May 23 04:28:24 2018

[Extensions WebUI] Remove the "Open in Dev Tools" button on errors

Extension errors have associated renderers, and we half-supported
opening developer tools to that error. Unfortunately, we didn't do this
very well - we didn't watch for renderer destruction or navigation,
either of which invalidate the ability to inspect.

Given the complexity of properly monitoring these, and the limited
utility this feature offered, remove this aspect of the error console.
The stack trace, context, and error should be sufficient to help the
developer track it down.

Bug:  769978 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ie0ae3d07448dc82af97315189313a9fd969b5b14
Reviewed-on: https://chromium-review.googlesource.com/1069564
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560941}
[modify] https://crrev.com/1aa78e0111c32de48ed588a71f7faa4cb83d043f/chrome/app/md_extensions_strings.grdp
[modify] https://crrev.com/1aa78e0111c32de48ed588a71f7faa4cb83d043f/chrome/browser/resources/md_extensions/error_page.html
[modify] https://crrev.com/1aa78e0111c32de48ed588a71f7faa4cb83d043f/chrome/browser/resources/md_extensions/error_page.js
[modify] https://crrev.com/1aa78e0111c32de48ed588a71f7faa4cb83d043f/chrome/browser/resources/md_extensions/service.js
[modify] https://crrev.com/1aa78e0111c32de48ed588a71f7faa4cb83d043f/chrome/browser/ui/webui/extensions/extensions_ui.cc
[modify] https://crrev.com/1aa78e0111c32de48ed588a71f7faa4cb83d043f/chrome/test/data/webui/extensions/extension_error_page_test.js