The following viewers have an "Inspect in New Window" command/context item:
dom, jsObject, accessibleProps, accessibleTree
There are use cases where "Inspect in New Window" would be useful in these viewers (i.e., they should have such an item, but don't):
styleRules, stylesheets, xblBindings
There are probably more.
We should just put this item in the global Edit menu. For those viewers which already include this item in their context menus, we should add a keyboard shortcut for it.

Attachment #480468 -
Attachment description: consolidate Inspect in New Window entities from dom.dtd and inspector.dtd, by moving them into editing.dtd and replacing viewer-specific menuitems with one that uses the new entity in a common overlay → phase 2 - consolidate Inspect in New Window entities from dom.dtd and inspector.dtd, by moving them into editing.dtd and replacing viewer-specific menuitems with one that uses the new entity in a common overlay

Comment on attachment 480468[details][diff][review]
phase 2 - consolidate Inspect in New Window entities from dom.dtd and inspector.dtd, by moving them into editing.dtd and replacing viewer-specific menuitems with one that uses the new entity in a common overlay
No obvious issues with the patch, but cancelling review as per comment #2.

Comment on attachment 480473[details][diff][review]
phase 7 - make accessibleRelations viewer currentIndex-clean and wire up its cmdEditInspectInNewWindow transaction
>+AccessibleTargetsView.prototype.getSelectedDOMNode =
>+ function getSelectedDOMNode()
>+{
>+ var targetsView = document.getElementById("olAccessibleTargets").view;
Isn't that the same as "this"?
>+ var targetsView =
>+ document.getElementById("olAccessibleTargets").view.wrappedJSObject;
Is there no way to get at the mTargetsView property?

(In reply to comment #13)
> >+ var targetsView =
> >+ document.getElementById("olAccessibleTargets").view.wrappedJSObject;
> Is there no way to get at the mTargetsView property?
I was trying to respect the "private" status of that field. I guess it doesn't matter.

(In reply to comment #17)
> (In reply to comment #13)
> > >+ var targetsView =
> > >+ document.getElementById("olAccessibleTargets").view.wrappedJSObject;
> > Is there no way to get at the mTargetsView property?
> I was trying to respect the "private" status of that field. I guess it doesn't
> matter.
I just noticed that some of the other viewers have a way of getting the selected object (thus encapsulating the access to the "private" view).

(In reply to comment #19)
> (In reply to comment #17)
...
> > I was trying to respect the "private" status of that field. I guess it doesn't
> > matter.
> I just noticed that some of the other viewers have a way of getting the
> selected object (thus encapsulating the access to the "private" view).
Is that the same as "I just noticed that's what you were doing. It's okay to put it back."? Or is it "I just noticed some of the other viewers were doing some other thing that differs from the original patch did, but still accomplishes what you were going for there. Maybe you should do that thing too."?

(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > > I was trying to respect the "private" status of that field. I guess it doesn't
> > > matter.
> > I just noticed that some of the other viewers have a way of getting the
> > selected object (thus encapsulating the access to the "private" view).
> Is that the same as "I just noticed that's what you were doing. It's okay to
> put it back."? Or is it "I just noticed some of the other viewers were doing
> some other thing that differs from the original patch did, but still
> accomplishes what you were going for there. Maybe you should do that thing
> too."?
The latter. For instance, the DOM viewer has a selectedNode property, while the accessible tree viewer has a getSelectedAccessible method.

(In reply to comment #20)
> If it's possible for sel to be null, is it worth checking in isCommandEnabled?
No, because there are only two ways for sel (now mSelectedItem in attachment 485529[details][diff][review]) to be null:
1) getSelectedItem returns null because selection count == 1. This is the check that isCommandEnabled performs now.
2) getSelectedItem returns null because tree.contentView.getItemAtIndex returns null. This isn't possible. It will always return a DOM node or throw an exception.

(In reply to comment #26)
> (In reply to comment #20)
> > If it's possible for sel to be null, is it worth checking in isCommandEnabled?
> No, because
Actually I was thinking of something else that turned out to be a bad idea.
(Well an inconsistent idea at least.)