Shared knowledge of selected node in highlighter and web console

RESOLVED FIXED in Firefox 8

Status

()

Firefox
Developer Tools
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: rc, Assigned: past)

Tracking

unspecified
Firefox 8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [best: 1h, likely: 2h, worst: 1d][console][minotaur])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

6 years ago
We need to implement the $0 helper for the Web Console to gain access to the currently-selected node in the highlighter. This should also be available via the InspectorUI.selection property.
(Reporter)

Updated

6 years ago
Depends on: 642471
Whiteboard: [best: 1h, likely: 2h, worst: 1d][console]

Updated

6 years ago
Whiteboard: [best: 1h, likely: 2h, worst: 1d][console] → [best: 1h, likely: 2h, worst: 1d][console][minotaur]
(Reporter)

Updated

6 years ago
Priority: -- → P2
Summary: Shared knowledge of selected node in highlighter → Shared knowledge of selected node in highlighter and web console

Updated

6 years ago
Assignee: nobody → past
Created attachment 549057 [details] [diff] [review]
Not working idea

I thought that something like this patch would suffice, but for the life of me I can't find a way to get a reference to the InspectorUI object. The console logging calls are some of my attempts at this. How can I get a reference to something #included in browser.js from a jsm?
Status: NEW → ASSIGNED
(Reporter)

Comment 2

6 years ago
I had a similar "not working" idea earlier. If you do a search through HUDService.jsm, you should find a reference to gBrowser. InspectorUI is a property attached to gBrowser so if you can get to that, you'll get to InspectorUI.
Created attachment 549158 [details] [diff] [review]
Not working idea v2

(In reply to comment #2)
> I had a similar "not working" idea earlier. If you do a search through
> HUDService.jsm, you should find a reference to gBrowser. InspectorUI is a
> property attached to gBrowser so if you can get to that, you'll get to
> InspectorUI.

This doesn't seem to work either :-/
Attachment #549057 - Attachment is obsolete: true
Created attachment 549400 [details] [diff] [review]
Working version

It was so simple after all, only 7 LOC to get a bloody reference...
Attachment #549158 - Attachment is obsolete: true
Attachment #549400 - Flags: review?(rcampbell)
(Reporter)

Comment 5

6 years ago
Comment on attachment 549400 [details] [diff] [review]
Working version

+      let window = HUDService.currentContext().window;
+      let mw = window.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
+                     .getInterface(Components.interfaces.nsIWebNavigation)
+                     .QueryInterface(Components.interfaces.nsIDocShellTreeItem)
+                     .rootTreeItem
+                   .QueryInterface(Components.interfaces.nsIInterfaceRequestor)
+                     .getInterface(Components.interfaces.nsIDOMWindow);

wah, that' a lotta QI!

Note, you can use the Ci constant for Components.interfaces.

I'm not sure we need to access through the contentWindow. The hudReference has a chromeWindow property which is the XUL window. I think you can access the InspectorUI property directly.

Or HUDService.currentContext() returns the current browser window.

return HUDService.currentContext().InspectorUI.selection *might* work?
(Reporter)

Comment 6

6 years ago
yup, replacing all that with:

Object.defineProperty(aJSTerm.sandbox, "$0", {
    get: function() {
      let mw = HUDService.currentContext();
      try {
        return mw.InspectorUI.selection;
      }
      catch (ex) {
        aJSTerm.console.error(ex.message);
      }
    },
    enumerable: true,
    configurable: false
  });

works.
(Reporter)

Comment 7

6 years ago
Comment on attachment 549400 [details] [diff] [review]
Working version

r+ with the above change
Attachment #549400 - Flags: review?(rcampbell) → review+
Created attachment 549557 [details] [diff] [review]
[in-fx-team] Simpler working patch

Doh, thanks for that, it should help restore my faith in humanity, and Mozillians in particular...
Attachment #549400 - Attachment is obsolete: true
Whiteboard: [best: 1h, likely: 2h, worst: 1d][console][minotaur] → [best: 1h, likely: 2h, worst: 1d][console][minotaur][land-in-fx-team]
(Reporter)

Updated

6 years ago
Whiteboard: [best: 1h, likely: 2h, worst: 1d][console][minotaur][land-in-fx-team] → [best: 1h, likely: 2h, worst: 1d][console][minotaur][fixed-in-fx-team]
(Reporter)

Comment 9

6 years ago
Comment on attachment 549557 [details] [diff] [review]
[in-fx-team] Simpler working patch

http://hg.mozilla.org/integration/fx-team/rev/0d0395cb99ff
Attachment #549557 - Attachment description: Simpler working patch → [in-fx-team] Simpler working patch
(Reporter)

Updated

6 years ago
Target Milestone: --- → Firefox 8
http://hg.mozilla.org/mozilla-central/rev/0d0395cb99ff
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [best: 1h, likely: 2h, worst: 1d][console][minotaur][fixed-in-fx-team] → [best: 1h, likely: 2h, worst: 1d][console][minotaur]
Does this bug need a dev-doc-needed keyword, or should we wait for the Highlighter to be enabled first?
(Reporter)

Comment 12

6 years ago
(In reply to Panos Astithas [:past] from comment #11)
> Does this bug need a dev-doc-needed keyword, or should we wait for the
> Highlighter to be enabled first?

Yes, I think we should wait until this is turned on.
You need to log in before you can comment on or make changes to this bug.