In the context of the browser toolbox, the ParentProcessTarget Actor watches
all top level window's docshells. But as it registers DOMWindowCreated/pageshow/pagehide
listeners against the docshell's window (because there is no parent chromeEventListener),
it has to ensure re-registering these listeners on navigation.
Differential Revision: https://phabricator.services.mozilla.com/D54193
--HG--
extra : moz-landing-system : lando
* Update the extensionStorage actor to enable some writing to extension storage.local through the Storage panel client.
* All values in the client are displayed as strings, so the actor must stringify them before sending them to the client and parse them when receiving changes from the client. For this reason, there is currently limited write support.
* Item values that are JSONifiable (numbers, strings, booleans, object literals, arrays and null) can be edited from the Storage panel.
* Object literals and arrays are only editable if their values are JSONifiable, with a maximum nested depth of 2 (e.g. an object with a nested object is editable, provided the nested object contains only primitive values). Object literals' keys must also be strings to be editable.
* Non-JSONifiable values cannot be edited, and will be represented by "{}" in most cases in the panel, though some non-JSONifiable values (undefined, Date, and BigInt) will be displayed as more readable strings.
* Some modifications are a little more complex, requiring an IndexedDB transaction. This will be handled in a separate patch.
* Item names cannot be edited from the Storage panel.
* New items cannot be added from the Storage panel.
* Any item can be removed.
* All items can be removed at once.
* In-line comments referencing Bugs 1542038 and 1542039 indicate places where the implementation may differ for local storage versus the other storage areas in the actor.
* The parseItemValue method used in the client was moved to a shared directory, so that the actor could parse string values from the client in its editItem method.
Differential Revision: https://phabricator.services.mozilla.com/D34416
--HG--
rename : devtools/client/shared/vendor/JSON5_LICENSE => devtools/shared/storage/vendor/JSON5_LICENSE
rename : devtools/client/shared/vendor/JSON5_UPGRADING.md => devtools/shared/storage/vendor/JSON5_UPGRADING.md
rename : devtools/client/shared/vendor/json5.js => devtools/shared/storage/vendor/json5.js
rename : devtools/client/shared/vendor/stringvalidator/UPDATING.md => devtools/shared/storage/vendor/stringvalidator/UPDATING.md
rename : devtools/client/shared/vendor/stringvalidator/moz.build => devtools/shared/storage/vendor/stringvalidator/moz.build
rename : devtools/client/shared/vendor/stringvalidator/tests/unit/head_stringvalidator.js => devtools/shared/storage/vendor/stringvalidator/tests/unit/head_stringvalidator.js
rename : devtools/client/shared/vendor/stringvalidator/tests/unit/test_sanitizers.js => devtools/shared/storage/vendor/stringvalidator/tests/unit/test_sanitizers.js
rename : devtools/client/shared/vendor/stringvalidator/tests/unit/test_validators.js => devtools/shared/storage/vendor/stringvalidator/tests/unit/test_validators.js
rename : devtools/client/shared/vendor/stringvalidator/tests/unit/xpcshell.ini => devtools/shared/storage/vendor/stringvalidator/tests/unit/xpcshell.ini
rename : devtools/client/shared/vendor/stringvalidator/util/assert.js => devtools/shared/storage/vendor/stringvalidator/util/assert.js
rename : devtools/client/shared/vendor/stringvalidator/util/moz.build => devtools/shared/storage/vendor/stringvalidator/util/moz.build
rename : devtools/client/shared/vendor/stringvalidator/validator.js => devtools/shared/storage/vendor/stringvalidator/validator.js
extra : moz-landing-system : lando
This allows us to not have to reach for the server
again from the client to get all the data we need
to render the table.
We still need to keep the old function to handle
connections to older servers. We'll use Bug 1597955
in Firefox 74 to clean the bits we don't need anymore.
A test is added to ensure the bug is fixed and we don't
regress; stubs are updated.
Differential Revision: https://phabricator.services.mozilla.com/D53962
--HG--
extra : moz-landing-system : lando
In order to render a table, we first check that console.table is
called with data that can be displayed in a table. Until now, we
were missing all the typed arrays.
This revealed some smaller issues:
- BigInt64Array were not marked as typed arrays on the server.
- Generating the repeatId for a message containing BigInts would
throw because BigInts can't be serialized.
We add test cases for all the typed array, and we take this opportunity
to add a test case to ensure object insides table cells can be expanded.
Differential Revision: https://phabricator.services.mozilla.com/D53155
--HG--
extra : moz-landing-system : lando
This removes the concept of shadowAnonymous, which doesn't make a lot of sense,
and re-enables the shadow dom tests which were disabled when we removed the old
style system (as stylo didn't supported shadow DOM yet by then).
This is a change in behavior as you can now remove nodes from shadow DOM (no
reason you weren't able to, before).
Differential Revision: https://phabricator.services.mozilla.com/D53340
--HG--
extra : moz-landing-system : lando
From Harald's comment, it seems there're more events to add, hence making a service worker section.
I didn't find a related test in server. Let me know if I miss any!
{F1687381}
Differential Revision: https://phabricator.services.mozilla.com/D52297
--HG--
extra : moz-landing-system : lando
The fix for [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) created a situation in the [`Rule.onDeclarationsChanged()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/inspector/rules/models/rule.js#869-887) whereby the `isUsed` state of client-side declarations was made to point to a fixed `isUsed` state received from the server, thus losing sync with the latest state of the `StyleRuleActor`. Until another "declarations-update" event was fired from the `StyleRuleActor`, the rule's declarations' `isUsed` flag would point to the state with which they were overwritten on the last event handler call.
As a reminder, the root cause of [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) was the inability force a "refresh" of the `StyleRuleFront` so it picked-up the latest `isUsed` state for its declarations when they depend on other declarations from other rules (ex: `justify-content: center` depends on `display:flex`). Therefore, the "declarations-updated" event was introduced with a payload of changed declarations to overwrite the client-side ones. It was convoluted, but it worked.
However, while investigating the cause of this newer bug [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944), I discovered an unusual but perhaps expected side-effect: when dispatching an event over the protocol with a payload of the `StyleRuleActor`, its corresponding `StyleRuleFront` on the client would "refresh" automatically (meaning that, looking up state on the previous front reference would point to the latest state from the actor) . The client doesn't even need to use this payload to replace its previous front reference. Surprisingly, the client doesn't even need to explicitly listen to the event which carries the `StyleRuleActor`/`StyleRuleFront` reference. So long as a previous reference of the front exists on the client, it will point to the updated state of the actor. I haven't been able to identify whether this is a known and expected behavior, so I'm pinging @jdescottes and @ochameau to weigh in on the validity of these findings.
Relying on this behavior, the fix for both [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) and [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) involves simply emitting an event, "rule-updated", with the `StyleRuleActor` instance as payload whenever its internal state changes meaningfully so the corresponding front updates. The client will pick-up the latest `isUsed` state of declarations from its reference to the `StyleRuleFront`.
---
Another way to check this behavior and hypothesis is to do the following:
- In [`StyleRuleActor.setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1704) replace `return this` with `return null`; (this will no longer return the `StyleRuleActor` over the protocol; it's not explicitly used on the client anyway).
- In the spec, replace the [`setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/shared/specs/styles.js#222) return value with `RetVal("nullable:domstylerule")` so the protocol doesn't throw an error when getting the `null` from the actor.
- Make a build.
- Then, open the Inspector -> Rules View and change the value of a valid declaration, say: `display: block`, to something invalid, like `display: booo`. Notice that the declaration is no longer marked invalid with a warning sign. That's because the declaration's [`isValid`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1447) flag is set on the actor but it no longer syncs with the client which uses the corresponding front to render the declaration after the change. Not returning the `StyleRuleActor` over the protocol breaks this sync actor-front sync.
Differential Revision: https://phabricator.services.mozilla.com/D52560
--HG--
extra : moz-landing-system : lando
It's being used in the client and server, and so is a shared file.
Differential Revision: https://phabricator.services.mozilla.com/D52247
--HG--
rename : devtools/server/performance-new/gecko-profiler-interface.js => devtools/shared/performance-new/gecko-profiler-interface.js
rename : devtools/server/performance-new/moz.build => devtools/shared/performance-new/moz.build
extra : moz-landing-system : lando
The function is only used in tests, which is a bit concerning
as we should test the actual function being used (evaluateJSAsync).
Differential Revision: https://phabricator.services.mozilla.com/D52331
--HG--
extra : moz-landing-system : lando
Alexandre Poirot
Emilio Cobos Álvarez
jaril
Nazım Can Altınova
Mihai Alexandru Michis
Yura Zenevich
Michael Ratcliffe
Bianca Danforth
Nicolas Chevobbe
Geoff Lankow
Jason Laster
Ehsan Akhgari
Brad Werth
wartmanm
Cyferouss
Andreea Pavel
Micah Tigley
chujun
Brian Hackett
Noemi Erli
Kirk Steuber
Brian Grinstead
Julian Descottes
Razvan Caliman
Narcis Beleuzu
Greg Tatum
Tim Nguyen
Dorel Luca