This cache might keep destroyed windowUtils helpers in some scenarios involving navigations with a process change.
The regular getter is slightly slower, but the performance hit should not be noticeable.
Differential Revision: https://phabricator.services.mozilla.com/D220785
This changes the `--x = red` tooltip content into just `red`.
We still keep the `--x is not set` as I'm unsure what the alternative could be
(and given it would probably still need localized string, as we can use `unset`,
which is an actual valid value)
Tests are updated to include the new tooltip content.
devtools/client/inspector/rules/test/browser_rules_preview-tooltips-sizes.js is
further tweaked to cover a frequent intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D219138
This fixes src loads to be consistent with srcset/picture loads, modulo
the special synchronous case in the spec
(https://html.spec.whatwg.org/#update-the-image-data step 7), which
requires src loads to be sync if the image is available.
We now avoid triggering the load from the parser consistently for src /
srcset / picture, and unify the codepath with BindToTree. That should
avoid some useless task allocations.
Only the sync load code-path needs a script runner (mostly to deal with
anonymous content like the video poster <img> and such, but it also
helps not trigger sync loads at unexpected times like on adoption).
About the HTMLImageElement::Complete() getter change, we need to also
return false if there's an existing load task. That is the proposal in
https://github.com/whatwg/html/issues/4884, and prevents some failures
in the-img-element/{update-src-complete,img.complete}.html WPTs. It
technically changes our behavior on .srcset changes, but it makes it
consistent with .src changes and other browsers, so seems fine.
There are a couple regressions in CSP tests and the networkEvent stubs,
but these are really a pre-existing issue. What happens is that, since
the loads are now async, CSP can't figure out the script that triggered
the load anymore. I need to look if there's an easy way to propagate
that information in the image load tasks, but this is trivially
reproducible by changing these tests to use srcset rather than src.
The rest of the test changes are as expected: either new passes, or
expected test changes from this.
Differential Revision: https://phabricator.services.mozilla.com/D215519
Also moving the LOG_METHODS from actors to specs so that the frontend
can import them from devtools/shared instead of devtools/server.
Differential Revision: https://phabricator.services.mozilla.com/D215085
Also moving the LOG_METHODS from actors to specs so that the frontend
can import them from devtools/shared instead of devtools/server.
Differential Revision: https://phabricator.services.mozilla.com/D215085
When tracking tokens, we weren't handling the case of unterminated,
single-char quote.
Test cases are added to cover the fix.
Differential Revision: https://phabricator.services.mozilla.com/D214917
Reusing the existing implementation of onResourceAvailable/Updated/Destroyed
was forcing to duplicate and instantiate useless data, which caused visible performance regression.
I'm forking them. Once Fx129 is the default release, we should then be able to simply drop
the onResourceAvailable/Updated/Destroyed methods. Until them, we should remind ourself to maintain the two
distinct codepath. Hopefully, we don't do many changes on this core codebase.
Differential Revision: https://phabricator.services.mozilla.com/D214325
We expect the console to be opened *before* toggling the tracing on the server side
and so, the ResourceCommand cache isn't useful, while it being costly with so many resources to cache.
Differential Revision: https://phabricator.services.mozilla.com/D213612
Using arrays speeds up the serialization and transmission of traces between the server and the client
as it goes through JS Actors/IPC by serializing the JSON RDP packets.
This also allows to better align with the profiler data format.
Differential Revision: https://phabricator.services.mozilla.com/D212807
Turn the icon into a proper button, add a title to it
and properly manage its aria-pressed attribute.
We no longer set the active class, and instead rely
on the aria-pressed attribute in the CSS and in tests.
Differential Revision: https://phabricator.services.mozilla.com/D213032
This helps accumulate RDP packets related to resources being available/updated/destroyed
and emit less and larger RDP packets instead or more and smaller.
This appears to reduce the overhead of DevTools transport and JSWindowActor layers.
The issue in browser_markup_events_toggle.js is interesting.
It highlights that a resource notified before a call to WatcherActor.watchResources,
may be emitted during the call to watchResources.
This makes ignoreExistingResources flag a bit brittle as that resource should be
considered as an existing/past one.
We should probably flush past resource and probably introduce a more explicit
way of handling "existing" resources on the server side.
The fix in document-events.js relates to failures in browser_net_offline_mode.js.
This test was passing thanks to late dom-complete event emitted on the previous WindowGlobal.
Surprisingly, when reloading the page in offline mode, the previous, already existing WindowGlobal
triggered the WebProgressListener and we were emitting dom-complete event.
Because of throttling, this resource is no longer transfered to the client as the related target
actor is already destroyed on reload.
But at the end, the issue was the missing dom-interactive and dom-complete events for the error page.
Regarding browser_net_ws-sse-persist-columns.js, it looks like this test was properly waiting
for the WebSocket table to update. We were really lucky it was working without frequent intermittent!
Similarly to the client side, DOCUMENT_EVENT's will-navigate is special
and has to be emitted synchronously in order to prevent clearing things out of order.
This is also true for NETWORK_EVENT_STACKTRACE which is expected to be received
*before* related NETWORK_EVENT. NETWORK_EVENT_STACKTRACE is fired from the content
process while NETWORK_EVENT is fired from the parent process.
For now, it is easier to synchronously emit those resources rather than trying
to do cross process coordination.
We may revisit this choice once we start doing throttling from the parent process
and may be once D143409 lands.
About browser_resources_clear_resources.js, it is surprising it wasn't already failing.
Differential Revision: https://phabricator.services.mozilla.com/D197772
This takes care of displaying `@starting-style` rules in the Rules view.
A test is added to cover this, as well as a test case to make sure those
starting style rules are not impacting the computed panel.
Depends on D210363
Differential Revision: https://phabricator.services.mozilla.com/D209329
Alexandre Poirot