Because ShouldIncludeEdge considers the |origin| node as well, it was possible for
the old code to 'miss' nodes and never write them to the core dump even though we
also wrote some edges with the node as referent.
Differential Revision: https://phabricator.services.mozilla.com/D37701
--HG--
extra : moz-landing-system : lando
ChromeUtils.import still support a second argument as it used to do
when it was Components.utils.import. But this is deprecated and we should
instead always use the returned value.
Differential Revision: https://phabricator.services.mozilla.com/D37708
--HG--
extra : moz-landing-system : lando
We weren't handling comments at all, which means that having
any in the console would probably make the autocomplete not
working.
This patch handles both inline and multiline javascript comments,
and adds test cases to ensure we don't regress.
Depends on D36573
Differential Revision: https://phabricator.services.mozilla.com/D37196
--HG--
extra : moz-landing-system : lando
We were using Array.from to get an array of all the characters, and
be able to slice parts of the strings to run some checks.
This had the disadvantage of being quite slow on very large strings,
at a point where we introduced a bail out mechanism into the function
to not block the content page.
This patch switches to `String.prototype[Symbol.iterator]` to loop
over all the character, and removes lots of array and string manipulations.
On the same, super-large, string, the function cost went from 6700ms to
less than 200ms.
Differential Revision: https://phabricator.services.mozilla.com/D36572
--HG--
extra : moz-landing-system : lando
Ensure source links for selectors in the Rules view and warning links in Web Console for minified CSS go to the right location in the Style Editor after applying automatic prettification.
This only works for linked stylesheets. [Bug 1169770](https://bugzilla.mozilla.org/show_bug.cgi?id=1169770) needs to be fixed first before this can work correctly on inline minified stylesheets.
This patch augments the `prettifyCSS()` method to generate the mappings necessary to generate a sourcemap from the original to the prettified source. It uses these mappings to translate the cursor position when invoking the Style Editor to be opened at a specific location.
The mappings from the minified to the prettified source are used only until the stylesheet is changed in the Style Editor. Upon editing the source in the Style Editor, the associated mappings are cleared because it's likely they have been rendered invalid.
The updated stylesheet will already be prettified so it bypasses the `prettifyCSS()` method, thus avoiding the need to re-generate mappings. New CSS warnings will be listed in the Web Console which point to the right location in the edited stylesheet (the old warnings no longer point to the right place, but that's an acceptable side-effect). The Rules view in the Inspector also lists selectors with the new positions within the edited stylesheet.
Differential Revision: https://phabricator.services.mozilla.com/D36585
--HG--
extra : moz-landing-system : lando
This implements the context menu items for the DOM mutation breakpoint.
In addition, there were some server changes to:
- Update the mutationBreakpoints form for the NodeActor
- Expose the mutationBreakpoints form
- Moved the setMutationBreakpoints method from the Node spec to Walker spec
since the Node spec only consisted of getter methods. It made more sense
that the setter went into the Walker spec to be more consistent with how
the Walker and Node spec have been arranged.
Unit tests will be followed up in Part 2 immediately.
Differential Revision: https://phabricator.services.mozilla.com/D36074
Add a context menu entry to export the console output to a file.
We group the 2 export entries into a submenu.
Differential Revision: https://phabricator.services.mozilla.com/D22158
--HG--
extra : moz-landing-system : lando
A test case is added to make sure this is fixed.
We also add the ability to not run a given test case in the color test.
Differential Revision: https://phabricator.services.mozilla.com/D35493
--HG--
extra : moz-landing-system : lando
The webConsoleFront and the threadClient front both used to depend on the debugger-client
to destroy them via registered clients. This is no longer the case, and this code can be deleted
Differential Revision: https://phabricator.services.mozilla.com/D32699
--HG--
extra : moz-landing-system : lando
In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.
Differential Revision: https://phabricator.services.mozilla.com/D32698
--HG--
extra : moz-landing-system : lando
The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.
Differential Revision: https://phabricator.services.mozilla.com/D32697
--HG--
extra : moz-landing-system : lando
This is part one of removing threadClient specifics out of the debuggerClient. We were
managing messages from the thread client in a special way -- this was the "Unsolicited Pauses"
object that we had before. This patch updates the threadClient to use Front style events. This
required updating the spec for the threadClient, and several of the methods. What has not been fully
migrated here is the "resumed" event, as this is much more complex. This is taken care of in the
next patch.
Differential Revision: https://phabricator.services.mozilla.com/D32695
--HG--
extra : moz-landing-system : lando
This is the first part of the threadClient refactor. It only moves the methods to the new
front. and does some basic fixes.
Differential Revision: https://phabricator.services.mozilla.com/D32692
--HG--
extra : moz-landing-system : lando
make sure we have a copy of thread client for old servers
Differential Revision: https://phabricator.services.mozilla.com/D34179
--HG--
rename : devtools/shared/client/thread-client.js => devtools/shared/client/deprecated-thread-client.js
extra : moz-landing-system : lando
The webConsoleFront and the threadClient front both used to depend on the debugger-client
to destroy them via registered clients. This is no longer the case, and this code can be deleted
Differential Revision: https://phabricator.services.mozilla.com/D32699
--HG--
extra : moz-landing-system : lando
In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.
Differential Revision: https://phabricator.services.mozilla.com/D32698
--HG--
extra : moz-landing-system : lando
The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.
Differential Revision: https://phabricator.services.mozilla.com/D32697
--HG--
extra : moz-landing-system : lando
This is part one of removing threadClient specifics out of the debuggerClient. We were
managing messages from the thread client in a special way -- this was the "Unsolicited Pauses"
object that we had before. This patch updates the threadClient to use Front style events. This
required updating the spec for the threadClient, and several of the methods. What has not been fully
migrated here is the "resumed" event, as this is much more complex. This is taken care of in the
next patch.
Differential Revision: https://phabricator.services.mozilla.com/D32695
--HG--
extra : moz-landing-system : lando
This is the first part of the threadClient refactor. It only moves the methods to the new
front. and does some basic fixes.
Differential Revision: https://phabricator.services.mozilla.com/D32692
--HG--
extra : moz-landing-system : lando
make sure we have a copy of thread client for old servers
Differential Revision: https://phabricator.services.mozilla.com/D34179
--HG--
rename : devtools/shared/client/thread-client.js => devtools/shared/client/deprecated-thread-client.js
extra : moz-landing-system : lando
Added proper plural form to editor.searchResults and sourceSearch.resultsSummary1. Updated the comments and IDs for the new strings as well. Replaced all instances of old string references with new string references.
Differential Revision: https://phabricator.services.mozilla.com/D32881
--HG--
extra : moz-landing-system : lando
Indicate in the infobar highlighter if the element is of kind grid or flex, and if it is a container or an item.
Differential Revision: https://phabricator.services.mozilla.com/D29964
--HG--
extra : moz-landing-system : lando
This is done so the user has a choice what kind of audit to run or what kind of audit type to filter the accessibility tree by
Differential Revision: https://phabricator.services.mozilla.com/D33183
--HG--
extra : moz-landing-system : lando
It can happen that the string we receive is quite large
and as a result takes a long time to analyze, freezing
the process.
This patch simply tracks for how long the for loop is running,
and bail out if it's greater than a given time (set to 2500 ms
for now).
This is mostly a safeguard, a future patch should try to improve
the performance of the function itself.
Differential Revision: https://phabricator.services.mozilla.com/D33791
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
Depends on D32867
Reference the shared list of pseudo-elements throughout the codebase:
- markup view context menu + test
- Rule editor
- box model highlighter
- node actor
- new Rules view
Differential Revision: https://phabricator.services.mozilla.com/D32868
--HG--
extra : moz-landing-system : lando
- Removes the hardcoded references from `index.xhtml` and `rules.js` and uses a centralized list of pseudo-classes to generate the checkboxes for the supported pseudo-class locks at runtime.
- Streamlines the handling for pseudo-class locks state. Fixes Bug 1536676 as a side-effect.
- Updates tests.
Differential Revision: https://phabricator.services.mozilla.com/D32867
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
They're not used internally either, so remove all ability to address them.
I haven't removed the implementation yet, as some of them are quite complex, and
I don't have a mac / windows build. We should do that when this hits release
though.
Differential Revision: https://phabricator.services.mozilla.com/D32488
--HG--
extra : moz-landing-system : lando
The performance profiler pop-up menu wants to be near DevTools, but work
without the complete DevTools initialization. This patch ensure that
any calls to lazyRequireGetter properly initialize the provider.
Differential Revision: https://phabricator.services.mozilla.com/D31628
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
This includes style system and layout update. I add 3 extra reftests
because the original tests use ray() function as the offset-path, but we
don't support it. It'd be better to add tests using a different type of
offset-path.
The spec issue about the serialization:
https://github.com/w3c/fxtf-drafts/issues/340
Differential Revision: https://phabricator.services.mozilla.com/D32212
--HG--
extra : moz-landing-system : lando
We want to go back to ESLint's default complexity level so that newly introduced code is checked for complexity.
At the same time, to make that work, we're excluding all of the more complex functions for now.
We should fix them: make them less complex, and remove the eslint-disable comment.
See bug 1553449 for more information about this.
Differential Revision: https://phabricator.services.mozilla.com/D32139
--HG--
extra : moz-landing-system : lando
We want to go back to ESLint's default complexity level so that newly introduced code is checked for complexity.
At the same time, to make that work, we're excluding all of the more complex functions for now.
We should fix them: make them less complex, and remove the eslint-disable comment.
See bug 1553449 for more information about this.
Differential Revision: https://phabricator.services.mozilla.com/D32139
--HG--
extra : moz-landing-system : lando
This patch gives the RDM UI the ability to update the screen orientation based on the orientation of the simulated device screen. It fixes the following issues:
- Initializing the orientation state of the selected device when RDM is opened.
- Updating orientation state when the rotate button in the RDM toolbar is pressed.
- Updating the orientation state when a new device is selected.
There are three actions creators that are responsible for notifying the ResponsiveUI manager, `changeDevice`, `restoreDeviceState`, and `rotateViewport`. In particular:
- `restoreDeviceState` is dispatched when the Responsive UI has finished initializing. If a previous RDM session had a device selected, then this action creator will also dispatch the `changeDevice` action to update the RDM UI to reflect the currently selected device.
- `changeDevice` is dispatched when a device is selected.
- `rotateViewport` is dispatched when the rotate button is clicked in the RDM toolbar.
When either of these actions is dispatched, we post a "viewport-orientation-change" message to the window that notifies the manager to update the screen orientation accordingly.
Finally, when RDM is closed, we need to ensure the original physical screen orientation is restored. We do this by calling the `setRDMPaneOrientation` on the docShell's document in the content frame script.
Differential Revision: https://phabricator.services.mozilla.com/D30440
--HG--
extra : moz-landing-system : lando
This patch adds telemetry instrumentation to count the number of times the RDM viewport properties are changed (dimensions and rotation). This count will be correlated with the panel open count and time spent open to refine the baseline for RDM usage and filter out accidental usage.
A new Redux middleware, `telemetryMiddleware`, is introduced to the RDM Redux store. This observes actions dispatched to the store. For `RESIZE_VIEWPORT` and `ROTATE_VIEWPORT` actions, it increases a numeric value for the new scalar telemetry probe, `"devtools.responsive.viewport_change_count"`.
Other actions may be observed in this middleware for future telemetry instrumentation of RDM.
The `RESIZE_VIEWPORT` action is a dispatched with a high frequency when dragging to resize. Therefore, we debounce logging for this action. To ensure the test can reliably test counting this action without adding needless complexity to account for the asynchronicity, the `debounce()` utility is extended with an `immediate` parameter to cause the very first call to be executed immediately before going into the debounce behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D31645
--HG--
extra : moz-landing-system : lando
Depends on D32016
The code comment is perhaps a leftover from a file duplication to extract shared methods to `shared/inspector/css-logic.js` from `server/actors/inspector/css-logic.js`.
The comment is confusing because there is no usage of any of the CssLogic terminology within the file.
Differential Revision: https://phabricator.services.mozilla.com/D32017
--HG--
extra : moz-landing-system : lando
This will save us some time from figuring out what's the best thing to do in
bug 1552587, so that other patches I have in flight (mainly bug 1552708) can
land, since we cannot add a single byte to nsStyleDisplay right now otherwise.
The code removed here is well isolated and not that complicated, so it seems to
me that should be easy to bring back should we have an emergency (and I commit
to doing that while preserving the nsStyleDisplay size limit if we need to :)).
Differential Revision: https://phabricator.services.mozilla.com/D32026
--HG--
extra : moz-landing-system : lando
This is the last part of this seris of patches to implement geometry property.
This particular patch just run `./mach devtools-css-db` to update db per instruction
at the beginning of devtools/shared/tests/unit/test_css-properties-db.js, and also a manual addition to the animation property db.
After this patch, the SVG geometry propery is implemented for <rect>, <circle>,
<ellipse> and <foreignObject>. We already implemented outer <svg>. Thus the
remainings are inner <svg> and <image>, which are kind of different to the
others, so they will be handled in some follow-ups. Note that these patches won't
impact old behavior of inner <svg> and <image>.
Differential Revision: https://phabricator.services.mozilla.com/D30808
--HG--
extra : moz-landing-system : lando
Note that the "loose | normal | strict" values are not yet parsed/implemented.
Differential Revision: https://phabricator.services.mozilla.com/D29817
--HG--
extra : moz-landing-system : lando
This preference is used both by the client and the server and cannot be stored in devtools/client
Also added default fallback values.
Differential Revision: https://phabricator.services.mozilla.com/D31404
--HG--
extra : moz-landing-system : lando
This is the last part of this seris of patches to implement geometry property.
This particular patch just run `./mach devtools-css-db` to update db per instruction
at the beginning of devtools/shared/tests/unit/test_css-properties-db.js, and also a manual addition to the animation property db.
After this patch, the SVG geometry propery is implemented for <rect>, <circle>,
<ellipse> and <foreignObject>. We already implemented outer <svg>. Thus the
remainings are inner <svg> and <image>, which are kind of different to the
others, so they will be handled in some follow-ups. Note that these patches won't
impact old behavior of inner <svg> and <image>.
Differential Revision: https://phabricator.services.mozilla.com/D30808
--HG--
extra : moz-landing-system : lando
Rather straighforward -- as per jryans recommendation, I have renamed the file to reflect
our naming conventions.
Differential Revision: https://phabricator.services.mozilla.com/D28641
--HG--
rename : devtools/shared/specs/script.js => devtools/shared/specs/thread.js
extra : moz-landing-system : lando
We need a complete specification in order to move forward with the front conversion. I
think this will also impact other parts of the refactoring, such as some of the thread specific code
in the debugger-client. This is a first pass, I did not go into detail about the return types.
Differential Revision: https://phabricator.services.mozilla.com/D28640
--HG--
extra : moz-landing-system : lando
Finally! the goal of all of this: removing three functions from threadClient that really belong as part of source client. PauseLongString is never used except in tests. ThreadLongString is only ever used by sourceClient. Same goes for the arrayBuffer method. This clears all of that out.
Differential Revision: https://phabricator.services.mozilla.com/D21715
--HG--
extra : moz-landing-system : lando
This introduces an ArrayBuffer front, so that we no longer need to go through the thread client to get an array buffer for the sourceFront (this is the only place it is used).
It also converts the arrayBufferActor to a protocol.js actor. I was running into an issue between them. I need to double check what this issue was. If these two refactors need to be split, I can do that, but for now it looks like it wasn’t that large of a change.
Differential Revision: https://phabricator.services.mozilla.com/D27878
--HG--
rename : devtools/shared/client/array-buffer-client.js => devtools/shared/fronts/array-buffer.js
extra : moz-landing-system : lando
After reviewing how the EnvironmentClient is used, it looks like the use of eventSource
might be some cruft from the past. Here is the try run:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=242251058&revision=df4bb52f188f79b8006e8c40401e5af2258493ce
with the exception of whatever is going on Window 7 (which appeares also on central), it looks like
things are working as expected. The environment client will eventually have the event emitter, once
it is moved to being a front.
adding @nchevobbe as a subscriber, as this touches a dependancy of the scratchpad.
Differential Revision: https://phabricator.services.mozilla.com/D28962
--HG--
extra : moz-landing-system : lando
The idea is to wait for ADB runtimes to be available before trying to render the initial route.
This way if we happen to find the runtime matching the current runtime, and if we still have a connected client for it, we can display the same runtime page.
Differential Revision: https://phabricator.services.mozilla.com/D28094
--HG--
extra : moz-landing-system : lando
