NS_ERROR_DOM_TYPE_ERR is not much better, but this at least allows us to get
rid of NS_ERROR_TYPE_ERR completely...
Differential Revision: https://phabricator.services.mozilla.com/D46485
--HG--
extra : moz-landing-system : lando
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Our Client.id values were being normalized from "{uuid}" to "uuid", but not
our FetchEvent.clientId values. Because nsID::Parse accepts both forms,
this was not being caught by any tests.
Although there are ServiceWorker WPT tests that verify consistency of
returned Client.id values across multiple matchAll invocations (ex:
client-id.https.html), there are no tests that compare Client.id with
FetchEvent.clientId. All the tests largely use Clients.get() to verify
correctness/round-tripping. I looked into adding WPT tests, but we
quickly run into the test logistics problem where it's preferable to
avoid adding tests that involve effectively global state.
So, this patch:
- Changes Clients::Get() to explicitly treat client id's that start with a
"{" as invalid. This causes existing FetchEvent.clientId-related WPT
tests to fail, as we would hope.
- Duplicates the client id normalization logic that strips {} for the
FetchEvent.clientId to its point of origin in
ContinueDispatchFetchEventRunnable::Run.
- Augments our dom/serviceworkers/test/test_match_all_client_properties.html
test, which has been enforcing {}-less UUIDs for a while, to also test
FetchEvent.clientId to verify it conforms. I added some comments to the
test files too.
--HG--
extra : rebase_source : dd6d07ea880eb2c3115d8810ea246b4469ad5f96
