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
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--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
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
It makes more sense to declare the preference changes in the root
React component, as other components (aboutdebugging, netmonitor, ...)
already do it.
Since we don't want to unmount the App component (which means we
won't fire any componentWillUnmount), we're turning the observer
into a weak referenced one so we don't leak.
Differential Revision: https://phabricator.services.mozilla.com/D31591
--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
`isInherited` is a callback function that checks if a given CSS property is inherited. It is misleadingly commented as a cache of inherited properties (which perhaps it is on the InspectorUtils implementation, but on the consumer side it is just a function).
The actual call is done by InspectorUtils.isPropertyInherited. There is no need to pass the handler to CssLogic or to CssPropertyInfo since InspectorUtils is available in the same context as the definition of the consumers.
There is no other use case where a custom handler is passed to check for inherited properties in so it is safe to remove this as an argument and just use InspectorUtils.isPropertyInherited where needed. This cleans up the code slightly.
Differential Revision: https://phabricator.services.mozilla.com/D32016
--HG--
extra : moz-landing-system : lando
Before sending back the stacktrace, we remove all the
devtools internal frames using removeFramesAboveDebuggerEval.
A test (that was failing without the fix) is added to ensure
this works as expected.
The test revealed some issues in webconsole-connection-proxy
(mostly trying to access webConsoleUI while closing the toolbox),
which we fix in the patch as well.
Differential Revision: https://phabricator.services.mozilla.com/D31249
--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
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Depends on: D31986
### Summary
- [X] Extra margin between paragraphs (about 14px, or whatever 1em is)
- [X] Same amount of padding on all sides - match left spacing. Looks like we need 4px less on the side with the arrow, 2px less on the other side.
- [X] Fully opaque, white-colored background
- [X] Drop shadow should be half as dark (I think this is the MacOS doubled dropshadow issue - it should match the meatball menu's shadow)
- [X] Less space between ending icons and CSS - seems like we can just remove margin-inline-start: 5px
- [X] I think florens may have a better info icon that will be more legible at this small size
!!I just created a new one!!
- [X] Warning icon should be smaller now to match the size of the info icon :)
It was an illusion but I have made it slightly smaller and changed the background position to make it look closer to the same size.
- [X] Seems like it would be helpful if you could select the tooltip text
- Whole tooltip 1px to the right and 2px lower !!I have moved this out to bug 1552146!!
Differential Revision: https://phabricator.services.mozilla.com/D31292
--HG--
extra : moz-landing-system : lando
Changes:
- Applied colors from Victorias mockups.
- Removed `margin-inline-start` from the icon to move it closer to the property value.
Differential Revision: https://phabricator.services.mozilla.com/D31986
--HG--
extra : moz-landing-system : lando
We want the warningGroup to be displayed if at least one of its
children will be visible.
We also want all the children if the warningGroup should be
visible.
This requires a few changes in the message reducers, mainly
in the getVisibility function. But we also modify
maybeSortVisibleMessages to place the messages in warningGroups
at the expected positions.
A complete mochitest is added to ensure the output always has
the expected messages in the expected order.
Differential Revision: https://phabricator.services.mozilla.com/D31220
--HG--
extra : moz-landing-system : lando
The code is adapted to work with the SearchBox, which means
we can get rid of an event listener in webconsole-ui.js.
Also, we take this as an opportunity to remove the element
refs as they were only used in tests, where we can more easily
use query selectors to get those elements.
Some changes were needed in SearchBox's `onChange` function since
`setState` is asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D31762
--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
- Fixes the references to the correct event handler & InspectorFront after a previous mass refactoring in Bug 1529364.
- Augments a test to ensure the clipboard content is correct executing the context menu action to copy a link.
Differential Revision: https://phabricator.services.mozilla.com/D31765
--HG--
extra : moz-landing-system : lando
Rather than having a separate preference for showing the deprecation message, we should reuse the aboutdebugging new pref
Differential Revision: https://phabricator.services.mozilla.com/D31964
--HG--
extra : moz-landing-system : lando
