WIP for metaclass concept
The best place to start is the test, it outlines what the API looks like.
Differential Revision: https://phabricator.services.mozilla.com/D37253
--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
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
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
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
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 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
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
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
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