1578174 - Use CSS warning target and window to retrieve impacted elements

Status: RESOLVED FIXED

(DevTools :: Console, defect, P1)

Description

[Nicolas Chevobbe [:nchevobbe]]

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.

Comment 1

[Chris Peterson [:cpeterson]]

Tracking DevTools bugs for Fission Nightly (M6) milestone

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

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.

Comment 3

[Chris Peterson [:cpeterson]]

Tentatively moving P1 Fission M6 bugs to M6a.

Comment 4

[Chris Peterson [:cpeterson]]

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

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1578174 - Use target and window from which a CSS warning was emitted to get the list of impacted elements. r=rcaliman.

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.

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1578174 - Add ensureCSSErrorReportingEnabled method in ContentProcessTargetActor. r=ochameau.

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.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/27ecfb5fce7d
Use target and window from which a CSS warning was emitted to get the list of impacted elements. r=rcaliman,ochameau.

Comment 9

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/27ecfb5fce7d