Closed Bug 1578174 Opened 1 year ago Closed 4 months ago

Use CSS warning target and window to retrieve impacted elements


(DevTools :: Console, defect, P1)



(Fission Milestone:M6c, firefox78 fixed)

Firefox 78
Fission Milestone M6c
Tracking Status
firefox78 --- fixed


(Reporter: nchevobbe, Assigned: nchevobbe)


(Blocks 1 open bug)


(Whiteboard: dt-fission-m2-mvp)


(1 file, 1 obsolete file)

Steps to reproduce

  1. Navigate to data:text/html,<meta charset=utf8><script>console.log("okay")</script><style>i {color: blouge;}</style><i>i</i><i>i</i>
  2. Open the Omniscient Browser Toolbox
  3. Enable the CSS filter if it wasn't yet
  4. Find the following message: Expected color but found ‘blouge’.
  5. Expand it

Expected results

There's a NodeList displayed the user can expand, and that holds 2 <i> elements

Actual results

The NodeList is empty.

Whiteboard: dt-fission-reserve → dt-fission-m2-mvp
Priority: P3 → P2

Tracking DevTools bugs for Fission Nightly (M6) milestone

Fission Milestone: --- → M6
Assignee: nobody → nchevobbe
Priority: P2 → P1

So I have a patch that retrieves the correct front, and evaluate document.querySelectorAll(selector) expression.
Problem is that for content process the console scope is a sandbox, which means document is undefined.

I'm not sure how to move forward from there.
My first idea would be to not directly do an evaluation, but have a dedicated webConsoleActor method, that would retrieve all the documents for the target, and then retrieve the matching elements.

My second thought would be to not do anything browser toolbox specific, and wait for the console to be able to attach to frame targets instead, where we would have access to the document from the corresponding webconsole actor.

Tentatively moving P1 Fission M6 bugs to M6a.

Fission Milestone: M6 → M6a

Tracking dt-fission-m2-mvp bugs for Fission Nightly milestone (M6c)

Fission Milestone: M6a → M6c

In order to retrieve the list of impacted element for a given CSS warning,
we are evaluating a document.querySelector expression,
using the cssSelector we get from the error itself.

But if the warning message comes from an iframe, we are not retrieving the
impacted elements, only items from the top-level document.

By storing the target actor id a message is emitted from directly in the message
itself, we can retrieve the target front, and use it to do the evaluation against
the right target.

This is not enough though, as non-remote frame don't have a dedicated target,
and we'll be back at square one, using the top-level document to do the evaluation.
In order to fix that, we're passing the innerWindowID to the evaluateJSAsync method,
so it can be used on the server to retrieve the window instance we need.

A test is added to ensure this feature works as expected for iframes, and it
passes with or without fission enabled.

Duplicate of this bug: 1549749

The method copies what is already done in BrowsingContextTargetActor,
except that we loop through the available windows in order to access
their docshells.
We take this as an opportunity to turn the existing method into a oneway
protocoljs request, as we don't return anything from it; it will emit
the errors when the stylesheets are parsed.

Summary: Expanded CSS Warnings in Omniscient Browser Toolbox does not show impacted elements → Use CSS warning target and window to retrieve impacted elements
Attachment #9150370 - Attachment is obsolete: true
Pushed by
Use target and window from which a CSS warning was emitted to get the list of impacted elements. r=rcaliman,ochameau.
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78
You need to log in before you can comment on or make changes to this bug.