This effectively removes the devtools overhead while profiling... as
long as the toolbox isn't opened as well of course.
This also removes the performance panel from the Browser Toolbox and the
Browser Content Toolbox where it shouldn't have been in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D6904
--HG--
extra : moz-landing-system : lando
We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Depends on D6925
Differential Revision: https://phabricator.services.mozilla.com/D6926
--HG--
extra : moz-landing-system : lando
1. Allow passing a selector to waitForMessage helper function:
This will allow to wait for specific message (warning, error, result, …).
This patch also fixes 2 tests that were already passing an erroneous selector
to waitForMessage.
2. Add an executeAndWaitForMessage function:
This will make a lot of our tests much easier to read. The function takes
an input, an expected output and an optional selector, execute the input
and resolves when a message matching the provided text (and selector
if passed) is displayed in the output.
Depends on D6903
Differential Revision: https://phabricator.services.mozilla.com/D6925
--HG--
extra : moz-landing-system : lando
This patch turns the current top-level handling, which relies on
the console API to print the result of the await expression, into
something natively handled by the server.
First, we don't add a .then handler to the generated async iife by
the mapper. We also removes the case we added in the JsTerm to *not*
print the result for top-level await expression.
In order to make the server capable of handling generated async iife
caused by the mapper, we send to evaluateJsAsync the `mapped` object
that `mapExpression` returns. This way, the server can check if an
expression was originally a top-level await.
If it is the case, we get the promise from the async iife and wait for
it to settle. If it resolves, we simply return the result, as a grip,
to the client. If it rejects, we return a special packet indicating to
not print anything to the client. The error will be reported by the
engine as `uncaught exception: …`.
We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Differential Revision: https://phabricator.services.mozilla.com/D6903
--HG--
extra : moz-landing-system : lando
Added trace extra parameters to be printed alongside console.trace() output.
Differential Revision: https://phabricator.services.mozilla.com/D7051
--HG--
extra : moz-landing-system : lando
Summary:
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Reviewers: ochameau
Reviewed By: ochameau
Bug #: 1473513
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : rebase_source : 09a1c8eac3cbb5856a5e3e61a1c0540efe32e5bd
- Various telemetry methods now need an object to be passed in in order to keep them seperate e.g. if the inspector is opened in tab 1 a timer is started. If an inspector is opened in tab 2 the same timer is restarted. Closing tab 2 would then erase the timing event invalidating the timer in tab 1.
- We no longer need to preface telemetry calls with category "devtools.main" because this is the only category we will be using.
- There are some changes to `devtools/client/debugger/new/dist/vendors.js` and `devtools/client/debugger/new/src/utils/telemetry.js` that need to be ported to the debugger at the same time as landing this.
Differential Revision: https://phabricator.services.mozilla.com/D6137
--HG--
extra : moz-landing-system : lando
TabTarget.attach is being called from the toolbox, before opening the tools,
so we do not have to call it from panel's open functions, nor code that is opening
a toolbox right after.
MozReview-Commit-ID: 77TZFbvOaFt
Differential Revision: https://phabricator.services.mozilla.com/D6668
--HG--
extra : moz-landing-system : lando
This patch will remove setContest(), and change the following things instead of this:
* Use HTMLTooltip.panel.appendChild() instead of HTMLTooltip.setContent().
* Add HTMLTooltip.setContetnSize() to specify the panel size if need this.
Differential Revision: https://phabricator.services.mozilla.com/D7044
--HG--
extra : moz-landing-system : lando
SwatchBaseEditorTooltip specify the "topcentor bototmleft" to second parameter
of HTMLTooltip.show(). However, this parameter will ignore since show() function
require the second parameter as the object, not the string.
Bug 1307481 comment 42 has pointed out this parameter.
Differential Revision: https://phabricator.services.mozilla.com/D7043
--HG--
extra : moz-landing-system : lando
This patch adds the ability to open the autocomplete popup when
typing an opening bracket (i.e. `[`]) in the console input.
This impacts a significant amount of function where we assumed
that the only way to get a completion was to use a dot.
We uses the rename `anylyzeInputString` function to get the
completion part from an input, as well as if the user is performing
an element access (i.e., using the bracket).
We then send that information to the webconsole actor, which send
it to the client.
This allows us to rely on a single parse of the input and gives us
access to this information everywhere we need to, be it on the client
or on the server.
We allow the user to type property name without quotes, and we add
them when the user accept an autocompletion.
We also automatically add a closing bracket (i.e. `]`), when it's needed.
Some test are added. On the server side to make sure the actor's autocomplete
function returns what's expected.
We take that as an opportunity to add test for commands.
On the client side, tests are added to ensure the different behavior works
as expected (check the completion text and the input after accepting
the completion when the user entered some letters, or not, with or without
quotes, with different quotes, hitting the autocomplete cache, …).
A test which accesses the autocomplete cache was modified since the shape
of the cache changed to include the last matchProp as well as the
isElementAccess boolean.
Differential Revision: https://phabricator.services.mozilla.com/D6128
--HG--
extra : moz-landing-system : lando
Functions using 'defer' for promises are being switched to the 'new Promise' syntax. This is for changes in devtools/server/tests/mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D6618
--HG--
extra : moz-landing-system : lando
When opening a web console and a browser console, we instantiate two NetworkMonitor
instances in the same process and they need independant states.
Differential Revision: https://phabricator.services.mozilla.com/D6054
--HG--
extra : moz-landing-system : lando
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : moz-landing-system : lando
- Refactor the highlighter shown/hidden event handlers from MarkupElementContainer in ElementEditor.
We do this because we want to be a bit more lazy when we set these on/off highlighters to only when
there is only a display badge and appropriate display type.
- This fixes a flickering bug cause by the event handlers when you click on the display badges in the markup view.
STR:
1. Have 2 grids shown on the markup view.
2. Toggle on one of them
3. Toggle the other one.
4. See that the active state toggles on, off and on.
We want to toggle the active state manually instead of waiting for the highlighter event handler
to toggle its active state when we click on the display badge. This is because waiting for
the highlight event handler to toggle the active state will cause a brief delay from showing
the active state when the user clicked on the display badge. To fix this, we added a way
to start/stop the highlighter event handlers.
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
Summary:
When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4542
MozReview-Commit-ID: IDPJVkAPbTs
Summary:
Fetching any target is now asynchronous. But RDM setup/destroy codepath is very fragile
and introduce many low level exception when trying to restore the original browser element
if any timing changes.
So this patch prevents trying to fetch the target object if a toolbox isn't already opened.
The target object is being used only for Telemetry purpose for now.
Depends On D4538
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4540
MozReview-Commit-ID: 2QDUNqentMP
Summary:
We are not passing a tab here. It only works by chance!
Depends On D4535
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4536
MozReview-Commit-ID: K0ztxPM2N6A
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
Summary:
When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4542
MozReview-Commit-ID: IDPJVkAPbTs
Summary:
Fetching any target is now asynchronous. But RDM setup/destroy codepath is very fragile
and introduce many low level exception when trying to restore the original browser element
if any timing changes.
So this patch prevents trying to fetch the target object if a toolbox isn't already opened.
The target object is being used only for Telemetry purpose for now.
Depends On D4538
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4540
MozReview-Commit-ID: 2QDUNqentMP
Summary:
We are not passing a tab here. It only works by chance!
Depends On D4535
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4536
MozReview-Commit-ID: K0ztxPM2N6A
This patch makes the parser-worker available at the toolbox level.
This way, the console does not have to rely on the debugger being
open to map top-level await expression.
In order to make the worker works in the toolbox, some changes
are required (passing a window object, checking inToolbox differently).
We take this as an opportunity to *not* display the async iife result,
a promise, in the console. This is made by checking if the input was
mapped, and if so, ignoring the result we get from the server.
A couple tests are added to ensure the basic usage works as expected.
This patch should be considered as a v0 for top-level await evaluation
as there are things that are not perfect here. Since we rely on console.log
the result are treated differently from other evaluation results:
- the style is different
- the result gets added to the log cache (when restarting the console,
the results will still be displayed, but not the commands).
- the results can be filtered, although evaluation results should not
- `$_` after a top-level await evaluation returns the Promise created
by the async iife, not the result that was displayed in the console.
All those should be addressed in Bug 1410820.
Differential Revision: https://phabricator.services.mozilla.com/D6038
--HG--
extra : moz-landing-system : lando
We will eventually call showEmpty() when an element is selected if there are no rules.
This improves the perceive performance of the rules view because it doesn't have
a flicker of the empty text to the css rules.
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
Summary:
When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4542
MozReview-Commit-ID: IDPJVkAPbTs
Summary:
Fetching any target is now asynchronous. But RDM setup/destroy codepath is very fragile
and introduce many low level exception when trying to restore the original browser element
if any timing changes.
So this patch prevents trying to fetch the target object if a toolbox isn't already opened.
The target object is being used only for Telemetry purpose for now.
Depends On D4538
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4540
MozReview-Commit-ID: 2QDUNqentMP
Summary:
We are not passing a tab here. It only works by chance!
Depends On D4535
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D4536
MozReview-Commit-ID: K0ztxPM2N6A
And remove the ADBScanner once the extension is uninstalled.
When RuntimeScanners.add is called for ADBScanner, RuntimeScanner calls
ADBScanner.enable(), thus ADB.start() is called. Meanwhile WebIDE installs the
devtools adb extension if the extension hasn't installed yet. So if the
ADB.start() is called before the installation finishes, ADB.start() fails.
Differential Revision: https://phabricator.services.mozilla.com/D6466
--HG--
extra : moz-landing-system : lando
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Differential Revision: https://phabricator.services.mozilla.com/D6162
--HG--
extra : moz-landing-system : lando
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Differential Revision: https://phabricator.services.mozilla.com/D6161
--HG--
extra : moz-landing-system : lando
When switching to async, it is important to catch exception or register a rejection handler
so that errors keep being logged.
So in this patch I'm catching exception in a couple of important codepath.
Depends On D4541
Differential Revision: https://phabricator.services.mozilla.com/D4542
--HG--
extra : moz-landing-system : lando
Fetching any target is now asynchronous. But RDM setup/destroy codepath is very fragile
and introduce many low level exception when trying to restore the original browser element
if any timing changes.
So this patch prevents trying to fetch the target object if a toolbox isn't already opened.
The target object is being used only for Telemetry purpose for now.
Depends On D4538
Differential Revision: https://phabricator.services.mozilla.com/D4540
--HG--
extra : moz-landing-system : lando
We are not passing a tab here. It only works by chance!
Depends On D4535
Differential Revision: https://phabricator.services.mozilla.com/D4536
--HG--
extra : moz-landing-system : lando
This patch will:
- Call the children as function when rendering if MenuButton's children property is the function.
- Add the callback which is called when the focused item changed.
Differential Revision: https://phabricator.services.mozilla.com/D6352
--HG--
extra : moz-landing-system : lando
This patch will move the global functions of ToolboxToolbar to its local
function. As a result of this changes, each function can refer 'props' from
'this' scope.
Differential Revision: https://phabricator.services.mozilla.com/D4631
--HG--
extra : moz-landing-system : lando