requestAnimationFrame runs _before_ reflow, so you actually need too to
guarantee that a reflow has happened.
I was getting intermittents in devtools/client/responsive/test/browser/browser_window_sizing.js
without this with the rest of the patches in this bug.
Also while at it fix the comparison to be less prone to floating point
errors, like a lot of the other zoom code in browser/.
Differential Revision: https://phabricator.services.mozilla.com/D72062
This is cheaper than calling Element::GetGridFragments as it does not need to
to construct an entire array of results. Most uses of GetGridFragments in the
devtools are only testing for the existence of grid fragments, and can be
changed to this cheaper method instead.
Differential Revision: https://phabricator.services.mozilla.com/D71674
Depends on D70071
After changes in D70071, the `CSSProperties` object is retrieved from the `CSSPropertiesFront`. The `initCssProperties()` method is no longer required. It is only used in tests.
This patch removes the leftover callsites for `initCssProperties()` from tests and the method implementation itself.
Differential Revision: https://phabricator.services.mozilla.com/D71560
The `initCssProperties()` helper is used to augment the CSS database of properties received from the server with additional local data. The returned `CSSProperties` object is cached by DevToolsClient instance so it can be returned quickly on subsequent requests.
Requesting the database from the server and its augmentation can be done in the `CSSPropertiesFront`'s [Front.initialize()](https://searchfox.org/mozilla-central/rev/a707541ff423ade0d81cef6488e6ecfa09273886/devtools/shared/protocol/Front.js#115-117) which is already async. This ensures that by the time the `CSSPropertiesFront` is returned, the `CSSProperties` object is ready to use with data reconciled.
Fronts are already [cached per target](https://searchfox.org/mozilla-central/rev/a707541ff423ade0d81cef6488e6ecfa09273886/devtools/client/fronts/targets/target-mixin.js#185-192). A duplicate `target.getFront("cssProperties")` will return the previously instantiated `CSSPropertiesFront` with the augmented database.
Getting the `CSSProperties` object is something done only for the top-level target in the Inspector and the Style Editor. Thanks to the behavior of `target.getFront()`, this already acts as a cache, thus negating both tasks done by the `initCssProperties()` helper.
Differential Revision: https://phabricator.services.mozilla.com/D70071
Note that it seems unpredictable when we receive the favicon request in the
network monitor, for example, on a Linux machine, the favicon request for a
static link element after the stylesheet link element in
html_cause-test-page.html it happens after the XHR request was received. So
instead of using a static link favicon element, we add a favicon link
dynamically in tests. Unfortunately there is no handy way to tell a favicon
request has done in contents, so we use LinkHandlerParent utility here.
Also note that the favicon request is triggered in FaviconLoader.jsm, which
means the call stack should NOT be shown (bug 1280266). For now, we
intentionally specify the stack and use todo for the case.
Differential Revision: https://phabricator.services.mozilla.com/D70572
Favicon requests happen in 'resource:///modules/FaviconLoader.jsm', so we need
the full URL to match sorted results in tests.
Differential Revision: https://phabricator.services.mozilla.com/D70664
This is blocking Gecko View debugging at the moment, so I would like to land a simple fix and work on a more long term solution in 1631020
Differential Revision: https://phabricator.services.mozilla.com/D71363
The `request-blocking-enable-bar` has no `display: flex` and a
fixed height with overflow hidden. As a result of this, the add
button that shoulf have been placed next to the enable option
was pushed down out of view.
As a result, the add button was hidden for quite some time.
Based on the discussion in the bug report, it was decided to
remove the button altogether because a simple enter does the job
and user didn't seem to notice it missing thus proving it didn't
hinder the user experience.`
Differential Revision: https://phabricator.services.mozilla.com/D71269
Invalid sameSite cookie attributes generate console warning messages in the
wrong 'generic' category. In this patch, we put them under the 'sameSite'
category. We also rename the 'generic' category to 'oversize' because all the
remaining messages are about invalid cookie sizes.
Differential Revision: https://phabricator.services.mozilla.com/D70795
The changes that are being removed now were introduced as a Fission-compatible approach in Bug 1572651, but were made obsolete by the fact that `setupInParent()` will not get a Fission-compatible replacement under the hood.
The replacement box model highlighter is implemented in Bug 1598307.
Most of the changes are removed aside from `server/actors/highlighters/box-model-renderer.js` which is the subset of code from `server/actors/highlighters/boxmodel.js` that handles only the rendering of the highlighter markup. This is reused in the upcoming replacement (see D54022).
Differential Revision: https://phabricator.services.mozilla.com/D69833
Remove PRE for rendering large content, to take advantage of
virtualization in codemirror.
Differential Revision: https://phabricator.services.mozilla.com/D68729
--HG--
extra : moz-landing-system : lando
This will allow user to actually inspect the properties of an error object,
which isn't possible at the moment.
This is because we apply a custom format on error, to only print the error
message and the stacktrace, as that's probably what the user is looking for.
But in some cases, it might still be valuable to be able to check the object
properties.
In order to do that, we add a new "customFormat" prop in Reps and ObjectInspector,
which need to be explicitely set if the consumers do want the custom format.
In the console, it will always be the case, except when the object is
in a console.dir call.
This will also open the door to have a way to switch between the custom format
and the regular view in the future.
Jest tests are modified to take this new prop into account, and the existing
console.dir mochitest is modified to add a specific case about error objects.
Differential Revision: https://phabricator.services.mozilla.com/D70392
--HG--
extra : moz-landing-system : lando
The toggle style was overridden in netmonitor for
no obvious reason, as the base styles take care of
everything we need.
Differential Revision: https://phabricator.services.mozilla.com/D71028
--HG--
extra : moz-landing-system : lando
When the pref is not set to true, we should not display the input,
but also the editor toolbar, the instant evaluation result and
the editor resizer.
The existing test is modified to ensure we cover all these elements.
Differential Revision: https://phabricator.services.mozilla.com/D70843
--HG--
extra : moz-landing-system : lando
Escape dollar sign for curl on windows,to fix a security issue
where commands such as $(cmd.exe) can be executed.
Differential Revision: https://phabricator.services.mozilla.com/D69776
--HG--
extra : moz-landing-system : lando
With the new architecture, it might happen that a message (and the ObjectFronts
it holds), are still displayed in the Browser Console / Browser Toolbox Console,
even if the target of those object fronts was destroyed.
In such case, when the user would legimitely try to clear the console, we'd try
to release the fronts that were already destroyed, which would throw an exception
and leave the console in a bad state.
This patch simply check that the fronts are still alive when we try to release
them, and adds a test (that was failing without that patch, with fission ON) for
the Browser Console.
Differential Revision: https://phabricator.services.mozilla.com/D70398
--HG--
extra : moz-landing-system : lando
When the pref is not set to true, we should not display the input,
but also the editor toolbar, the instant evaluation result and
the editor resizer.
The existing test is modified to ensure we cover all these elements.
Differential Revision: https://phabricator.services.mozilla.com/D70843
--HG--
extra : moz-landing-system : lando
This code is used to determine the sizes of the top-level windows. However the
code doesn't cause quite desirable behavior (see the bug, and comment 15).
This patch does two things:
* Unifies the html / xul code-paths. This shouldn't change behavior (because
GetXULMinSize returns the fixed min-* property if present anyways), but
makes the patch a bit simpler.
* Makes the min-width of the XUL window be the pref size instead of the
min-size (for the cases where you have no explicit min-width). This looks a
bit counter intuitive, but it's the only way to guarantee that the content
will be shown. This matches the sizing algorithm that dialogs use by default
(via calling window.sizeToContent()), while allowing to undersize the window
via a fixed min-width property.
This in turn makes sizeToContent() work "by default" on XUL windows, avoiding
having to make JS listen to everything that possibly could change the layout of
the document (like resolution changes).
Differential Revision: https://phabricator.services.mozilla.com/D70209
--HG--
extra : moz-landing-system : lando
Depends on D69544
Since selected is read on the descriptor form, there is no need to include it in the listTabs response.
Differential Revision: https://phabricator.services.mozilla.com/D69545
--HG--
extra : moz-landing-system : lando
Depends on D69543
There are no actual call sites for selected, but we have a test checking the feature.
Alternatively we could get rid of the feature.
Differential Revision: https://phabricator.services.mozilla.com/D69544
--HG--
extra : moz-landing-system : lando