The function was setting extra classes on both
the summary and the detail, running extra checks
to not remove the base classes.
It's only called from one place, and we only care
about adding classes to the summary element, which
we have access to directly.
We're switching to classList.(add|remove) , which
allows us to get rid of the SplitView method.
Differential Revision: https://phabricator.services.mozilla.com/D144427
Only the detail element was needed in the callback, so we remove all the other
unnecessary parameters.
This allows us to also remove the `data` option.
Differential Revision: https://phabricator.services.mozilla.com/D144268
Since there's nothing asynchronous happening before the item gets added to the
list, the consumer can directly use the properties of the object returned by
'appendTemplatedItem'.
Differential Revision: https://phabricator.services.mozilla.com/D144267
While adding this new html page for breakable lines,
I revisit how we load same-url.sjs and use this iframe document instead.
This feel more natural than dynamically injecting a document-builder iframe.
Also I promote breakable lines and positions tests to become features tests.
And it looks like adding the iframe target slow things down for the quick open.
So I tuned the related assertion to avoid intermittents.
Last but not least, this patch highlights two limitations for iframe html debugging:
* only the first inline script is "breakable" (others are ignored)
* on reload, no content is displayed at all (this is new to me)
Differential Revision: https://phabricator.services.mozilla.com/D143989
We usually need three mutations to reach the final state of addProperty and usually the 2nd and 3rd come in the same batch.
Meaning that simply waiting for receivedMutations >= 2 works in most cases.
But the intermittent screenshots show that the markup view was not updated yet with the correct content meaning it either didn't receive or processed the last
mutation.
Let's try to wait for the proper mutation instead of using an arbitrary number. Hopefully this fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D144181
These tests are failing intermittently as, I think, the label gets localized
asynchronously.
So instead of checking the computed translated string, we only check that the
attribute for the item name is properly set.
Differential Revision: https://phabricator.services.mozilla.com/D144163
I tried various approaches around the session restore, but this isn't reliable.
Using an environment variable is much easier and also help making the path global
for the whole instance in case we close and reopen it.
Differential Revision: https://phabricator.services.mozilla.com/D143695
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
