Open Bug 1148555 Opened 9 years ago Updated 2 years ago

Click to highlight button should work in Browser Toolbox

Categories

(DevTools :: Inspector, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: ntim, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [btpp-backlog])

Either it should be disabled, either it should force the red outline.
Can you explain the steps in more detail here?  I do get the red highlighter outline when using the pick button from BT.
Flags: needinfo?(ntim.bugs)
Check attachment 8566440 [details] (from the blocking bug), to see which highlight button I'm talking about.
Flags: needinfo?(ntim.bugs)
You're right Tim, this doesn't work from the Browser Toolbox, because the SelectorHighlighter doesn't work for XUL windows.

In fact, it could work in XUL windows, if it detected the type of window, and used the SimpleOutlineHighlighter instead when the window was XUL.
It would just need to have an if (isXUL(this.tabActor)) somewhere here:
http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/highlighter.js#1904

However, we have a mechanism in place where any extra highlighter (meaning, any highlighter that's not the main one used in the inspector to show nodes when hovering over elements in the marku-view) is known as a "custom highlighter".
And for simplicity reasons, we made it that custom highlighters can only work in non-XUL windows:
http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/highlighter.js#414
That's because we made the assumption that all custom highlighters would need to inject content into the canvasFrame, which doesn't exist in XUL windows.
This assumption is mostly true, except for the SelectorHighlighter where we could, as said above, fall back to using the SimpleOutlineHighlighter which doesn't require the canvasFrame.

My advice is that changing this mechanism to benefit from the outline fallback would be much more complex than the feature is worth in the Browser Toolbox.

So I'd vote for disabling the icons in the rule-view.
The problem to be solved with this is that knowing if the SelectorHighlighter can work on the current target requires to actually try and instantiate it. For now this is done lazily.
So the icon is first added to the UI:
http://mxr.mozilla.org/mozilla-central/source/browser/devtools/styleinspector/rule-view.js#1992
And only when clicked, we try and get the highlighter:
http://mxr.mozilla.org/mozilla-central/source/browser/devtools/styleinspector/rule-view.js#1275

One way to fix this is to add the icon later, after having tried to instantiate the highlighter once. This would make the rule-view just a little bit slower the first time it's shown.
Inspector bugs triage. Filter on CLIMBING SHOES.
P3 since it only impacts the browser toolbox.
Priority: -- → P3
Whiteboard: [btpp-backlog]
Product: Firefox → DevTools
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.