- Expose FetchEvent.resultingClientId on non-subresource, non-"report"-destination requests.
- Delay Clients.get(FetchEvent.resultingClientId) resolution until the resulting client is execution ready.
- Add WPTs to test for existence of resultingClientId and Clients.get promise resolution values.
Differential Revision: https://phabricator.services.mozilla.com/D5333
--HG--
extra : moz-landing-system : lando
The component is wrapping the `Frames` component from the debugger
in order to have access to frames grouping.
It also handles sourcemaps, since the debugger component
does not by itself.
Tests are added to ensure the component behaves as expected.
Depends on D11602
Differential Revision: https://phabricator.services.mozilla.com/D11603
--HG--
extra : moz-landing-system : lando
This will allow the "copy message" context menu
entry to work as expected for console messages
with a stacktrace (exception, error message, console.trace, …)
Differential Revision: https://phabricator.services.mozilla.com/D11602
--HG--
extra : moz-landing-system : lando
In order to send send attributes in BatchData we will need to convert
them to an array. Here we factor out the private function that does that
and put it in nsAccUtils.
Differential Revision: https://phabricator.services.mozilla.com/D11211
--HG--
extra : moz-landing-system : lando
This patch moves all the logic we currently have
baked-in JsTerm to handle the autocompletion data:
- deciding to fetch from the server or the cache
- handling concurrent requests
- managing the cache.
This is now done through dedicated Redux actions and reducers.
In the JsTerm, where the autocompletePopup still lives, we
handle those data changes in componentWillReceiveProps.
Some tests were modified in order to pass with these changes.
Differential Revision: https://phabricator.services.mozilla.com/D11454
--HG--
extra : moz-landing-system : lando
Previous to bug 1453751 favicons were loaded from the network by a <xul:image>
tag with validate="never". This caused us to always use any cached version if
possible. Bug 1453751 used a normal load type causing us to revalidate with the
server for each request. This switches the loader to using the cache if possible.
Differential Revision: https://phabricator.services.mozilla.com/D11402
--HG--
extra : moz-landing-system : lando
In some cases, the setTimeoutIfNeeded function can
be called before the store is initialized, which is
causing an exception when we try to dispatch the
messages.
With this patch, we check if the store is not ready,
and re-schedule a timeout so messages can be handled
properly when the store is ready.
Differential Revision: https://phabricator.services.mozilla.com/D11044
--HG--
extra : moz-landing-system : lando
Currently, build telemetry submits at random, approximately
every 10 `mach` invocations. This choice was made arbitrarily,
with no real reason in mind for that level of frequency.
After speaking with some of the data engineers in #telemetry,
it seems we should be able to send pings to the telemetry
pipeline far more frequently than we realized. This commit
removes the telemetry submission logic and causes clients
to attempt to send pings for every mach invocation. Pings
are still saved to the outgoing directory, in case of a
failure or in the case of offline `mach` runs.
Differential Revision: https://phabricator.services.mozilla.com/D11279
--HG--
extra : moz-landing-system : lando
While attempting to improve the build telemetry submission
logic, I found a bug in the way telemetry submission
works. Essentially the submission script was failing to
import any of the required packages (specifically
`mozbuild.telemetry` in this case) as the method used to
modify path was incorrect and the script was running outside
of the virtualenv. The invocation is also sending stdout
and stderr to `/dev/null`, making this problem even less obvious.
When I fixed the path modifications, I realized that `mozbuild`
imports will require a long chain of other imports
(and transitively, more `sys.path` modifications)
such as `which`, `mach`, `mozautomation`, etc to complete.
When I tested the submission script, I did so by running
`mach python build/submit_telemetry_data.py`, which runs the
script in a virtualenv with all required packages installed.
That's likely part of the reasons I overlooked this issue in testing.
Rather than go through the process of importing every dependency
of `mozbuild`, this commit changes the invocation of the submission
script to go through `mach python`. Things seem to work as
expected with this change.
Differential Revision: https://phabricator.services.mozilla.com/D11278
--HG--
extra : moz-landing-system : lando
A subsequent commit will require similar logic to the
checks found in this command. Moving to mozbuild will
allow us to re-use the function instead of re-writing
similar logic.
Differential Revision: https://phabricator.services.mozilla.com/D11277
--HG--
extra : moz-landing-system : lando
X11.h defines a macro named "Bool", which can cause surprising compile errors due to include order.
Differential Revision: https://phabricator.services.mozilla.com/D11494
--HG--
extra : moz-landing-system : lando
