When dispatching a JS Object, this won't be dispatching an async action.
Dropping the await will better highlight the synchronous dispatch calls.
Note that when we do
```
dispatch({
[PROMISE]: ...,
...
});
```
The promise middleware kicks in and the action becomes async.
So await is still relevant in front of these dispatches.
Differential Revision: https://phabricator.services.mozilla.com/D143143
I especially highlight the special behavior where the frontend tries
to keep selecting original source if we were already selecting an original source
and do the same when we were on a generated source.
Differential Revision: https://phabricator.services.mozilla.com/D143142
When selecting another thread/target, we shouldn't need to re-fetch frames/scopes.
This should always be done when paused() action is fired and data be stored and kept in the reducer.
But... this happen to be cancelled in middle of the processing when two thread pause concurrently.
This is experience by browser_dbg-windowless-workers.js.
Differential Revision: https://phabricator.services.mozilla.com/D143141
Instead, make the behavior consistent across all <length-percentage>
values (by truncating instead of rounding). This is the already-existing
behavior for calc() and percentages, but with this patch we also apply
it to plain length-flavored <length-percentage> values (this is needed
to avoid regressing things like bug 989802).
Regular <length>s keep rounding, to preserve existing behavior. We can
consider changing that in a follow-up if need be.
Differential Revision: https://phabricator.services.mozilla.com/D143857
You can run:
```
$ MOZ_BROWSER_TOOLBOX_PROFILER_STARTUP=1 ./mach run --jsdebugger
```
This will open a first browser toolbox for which we will record its startup.
Then, open a second browser toolbox, and open the recorded profile from its performance panel.
Differential Revision: https://phabricator.services.mozilla.com/D143567
This will help debug browser toolbox performance.
The performance panel displayed in the first browser toolbox is a bit pointless,
you better have to use the toolbar icon so that you avoid having all DevTools noise.
This enabling is actually mostly meant for the second browser toolbox you can open,
which will debug the first browser toolbox.
In this second browser toolbox, you will be able to record the first browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D143566
And pass a toolbox instead of only the toplevel target.
It helps identify the browser toolbox and easily enable/disable tools for it.
Differential Revision: https://phabricator.services.mozilla.com/D143628
This mostly just moves code around, to minimize potential behavior
changes. There are some cleanups that we should try to do long term
(this "have an array with n different counts" is pretty weird).
But for now this should unblock people.
The destination struct (nsStyleUIReset) was chosen mainly because it's
small and non-inherited, and it doesn't seem like a worse place than
nsStyleDisplay.
Differential Revision: https://phabricator.services.mozilla.com/D144183
This has been enabled for a while and should be considered the new default behavior.
Also removing (now) unused selectors/actions.
Differential Revision: https://phabricator.services.mozilla.com/D143999
This was already happening due to an erroneous typeof check.
Luckikly this is actually what we want (and what Chrome is doing FWIW).
Differential Revision: https://phabricator.services.mozilla.com/D144139
This patch fixes 2 crashes, for different reasons and improves/ adds tests to cover the issues
- The raw view of the `Request headers for upload stream` crashes when there
is only one header sent. This is covered by the scenario
```
[
"content-type: application/x-www-form-urlencoded\r",
"\r",
"\r",
"foo=bar&baz=123"
]
```
- The Request side panel crashes when there is no form data body content added to the payload sent.
This is covered in the test by the scenario
```
[
"content-type: application/x-www-form-urlencoded\r",
"\r",
"\r",
]
```
Differential Revision: https://phabricator.services.mozilla.com/D143339
I had to tune the versionized http helper to pass the right headers,
while still ensuring that http cache is kept disabled.
Differential Revision: https://phabricator.services.mozilla.com/D142348
I wasn't able to retrieve the original STR this condition was preventing, but
removing it and using various highlighters (box model, flex, grid, …) in the browser
toolbox, targetting various documents, I didnt' see any error.
Most importantly, it allowed to show highlighters where it wasn't possible before
(e.g. grid highlighter for webconsole document).
TRY don't show any breakage either.
Differential Revision: https://phabricator.services.mozilla.com/D143571
Both the dtd and properties files strings are moved to the existing storage.ftl.
A migration file was added to keep the localized strings.
Some of the strings were migrated to a declarative approach, setting `data-l10n-id` and
`data-l10n-args` attributes on elements. But in other cases, this was not easily doable.
To accomodate with the asynchronicity of `formatValue`, we translate all the strings that
don't have dynamic parameters during the initialization of the panel, and store them in
a Map for easy retrieval.
We also took this opportunity to cleanup the strings key names and have them all prefixed
with `storage-*`. Some functions where refactored so it should be easier to search the
code for a specific l10n string.
Finally, the `table.headers.indexedDB.*` strings weren't migrated as they were never read
in the UI (they are referenced in `NON_L10N_STRINGS`, which bypass localization).
Differential Revision: https://phabricator.services.mozilla.com/D143012
Normalising `NaN` comparator results to `0` was added in ES6, but the two
numeric comparator functions were never updated to include this change.
Differential Revision: https://phabricator.services.mozilla.com/D143337
Eugh - my attempts to validate that every SmartTrace had been expanded were
just hackish and incorrect. What appears to have been happening was a race
between the Promise.race in SmartTrace.js and the IntersectionObserver callback
after setting the output's scrollTop to 0 in the test. If the Promise.race is
fast enough, it executes right after the test yields execution after setting
scrollTop, causing it to run before the IntersectionObserver callback is able
to disable scroll pinning. Setting the default initialRenderDelay to 1 instead
of 100 is enough to get this to happen reliably for me.
I don't think we need any changes other than the change to this test, because I
don't expect this to be a problem that really shows up in practice, and it
would be easily remedied by the user simply continuing to scroll.
Differential Revision: https://phabricator.services.mozilla.com/D143433
