We weren't actually returning any value.
The only case when we return something is when the RDP method throws and return
an object response with an "error" attribute.
I imagine this has been refactored incorectly from old style actor to protocol.js.
We should throw in case of errors if we want to transfer a RDP message with "error" attribute.
Differential Revision: https://phabricator.services.mozilla.com/D66132
--HG--
extra : moz-landing-system : lando
For now, this is only an equivalent of the existing listAllWorkerTargets.
But thanks to it using the TargetList API to listen to processes,
it can fetch only the workers from the newly-created processes
or only for the process which have their worker list updated.
Follow-up would be necessary to:
* optionally listen for SW in the content toolbox codepath
* expose SW Registrations?
Differential Revision: https://phabricator.services.mozilla.com/D63854
--HG--
extra : moz-landing-system : lando
Store and expose thread types in constants, and use those.
Only loop once through the threads.
Differential Revision: https://phabricator.services.mozilla.com/D65966
--HG--
extra : moz-landing-system : lando
This patch changes the color of the evaluation context selector button
when another context than Top is selected.
This hopefully will help the user to see they're in a different context
than the regular one, which can be helpful since the context can be
changed by actions in the toolbox, and not only from the user explicitely
selecting another context.
Differential Revision: https://phabricator.services.mozilla.com/D65963
--HG--
extra : moz-landing-system : lando
When a thread is selected, either via the context list,
or through the toolbox actions, we dispatch a new action
that will do another instant evaluation so any results
we get matches the selected context.
Differential Revision: https://phabricator.services.mozilla.com/D65741
--HG--
extra : moz-landing-system : lando
For test_protocol_stack we now generate a different function name like
onConnect/>. This happens because the test doesn't execute with strict mode
anymore, which would inhibit lazy parsing. With lazy parsing we get
different function naming ..
option("strict") will throw now.
Differential Revision: https://phabricator.services.mozilla.com/D65833
--HG--
extra : moz-landing-system : lando
It's possible to trigger a call to `destroy` in RDM immediately after opening it. If this happens then there's the chance UI hasn't finished connecting to the DevTools server, which is where we create a new TargetList to support target-switching in RDM. Since this list is unavailable when `destroy` is called, we get the issue being reported for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D66307
--HG--
extra : moz-landing-system : lando
This regression fix does not include a test, but I'll try and follow-up with one.
I'd prefer to get this fixed sooner rather than later. I attempted to write a test
for the shortcuts before, and I failed due to some kind of race condition.
Differential Revision: https://phabricator.services.mozilla.com/D66236
--HG--
extra : moz-landing-system : lando
Note that this patch also updates the setReactFriendlyInputValue function in
head.js, as it was not working for selects.
Differential Revision: https://phabricator.services.mozilla.com/D65151
--HG--
extra : moz-landing-system : lando
This race condition is really only exposed in automated testing, but it
was making the DevTools performance-new mochitests intermittent.
The race looks like this:
* stopProfilerAndDiscardProfiler() request
* perf actor process the request
* The gecko profiler sends an event notifying that the profiler stopped
* DevTools updates the UI upon receiving the event
* The test suite sees the UI update, and triggers a close of DevTools
* Error: Connection closed, pending request
* stopProfilerAndDiscardProfiler still hasn't sent the response yet
This patch fixes it by not throwing an error if the panel is already destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D65150
--HG--
extra : moz-landing-system : lando
The browser chrome tests previously only tested the performance-new client
from a unit testing perspective. I originally wrote them this way so that
they would be fast, and not flaky, as the client actually runs the profiler
and full browser infrastructure. However, these tests haven't been really
great at catching bugs, and the tests break pretty easy to due implementation
changes for the client.
The new browser tests have been proving fast, reliable, and great at catching
regressions. This patch moves all of the about:profiling related tests to be
exclusively mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D65149
--HG--
extra : moz-landing-system : lando
Currently the preferences for remote profiling are stored on the debuggee. This leads
to a negative user experience, as oftentimes phones do not persist the preferences.
This patch changes the strategy to store one set of preferences for local profiling,
and a second set of preferences for remote profiling.
Differential Revision: https://phabricator.services.mozilla.com/D65148
--HG--
extra : moz-landing-system : lando
DevTools and about:profiling will both use them, so place them in a shared utils
folder, and put the type definition in a shared location.
Differential Revision: https://phabricator.services.mozilla.com/D65145
--HG--
extra : moz-landing-system : lando
Micah Tigley
Alexandre Poirot
Hubert Boma Manilla
Nicolas Chevobbe
Dorel Luca
Tom Schuster
Daniel Varga
Farooq AR
Greg Tatum
Jason Laster
Noemi Erli
Bryan Kok
Belén Albeza
Kriti Singh
Uday
Mihai Alexandru Michis
Mark Banner
Boris Zbarsky