The source tree seems to be updated asynchronously after the source selection.
Also, the SourcesTree component wasn't correctly selecting and expanding the tree
when the selected source was immediately selected as it gets created in the source tree.
Differential Revision: https://phabricator.services.mozilla.com/D148838
In the console we might receive messages that need to be inserted at a specific
position in the output to respect the chronological order.
This is very visible when evaluating an expression in the console while we are
fetching cached messages, or when the expression is logging lots of messages, since
the evaluation result doesn't go through the ResourceCommand itself.
Since we were relying on the order of insertion in `mutableMessagesById` for the
order of messages in the output, we had no choice but clone the Map to insert
the new message at the specific position.
With lots of messages, this can be utterly slow, and is something people are experiencing.
To fix this, we're adding a new state property, `mutableMessagesOrder`, which holds
message ids in the chronological order. It's then used to compute `visibleMessages`.
As we don't have to clone the Map anymore, it makes reordering as fast as looking
for an index in the array and splicing it (which is fast).
We also take this opportunity to switch away from our `findIndex` usage; most often
than not, the messages will be reinserted at the end of the array, so we can loop
through it backward to find the index faster.
We still keep `mutableMessagesById` as a Map so lookup are fast, and we don't have
to deal with impacts we'd have if we'd switch to an object.
The existing node test helper to get a message at a specific index are migrated
to make use of `mutableMessagesOrder`, and a few test cases and assertions are
added to check that the new property is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D148658
The source tree seems to be updated asynchronously after the source selection.
Also, the SourcesTree component wasn't correctly selecting and expanding the tree
when the selected source was immediately selected as it gets created in the source tree.
Differential Revision: https://phabricator.services.mozilla.com/D148838
These two DevTools DOM panel tests are expecting the elements being inspected to be at a certain row index
which depends (likely due to alphabetic order) that InstallTrigger is listed as a global in the window
being inspected (it doesn't matter what the value is, the failure is triggered because when InstallTrigger
is completely hidden the elements expected by the tests are shift by one row position).
And so these two tests would be currently permafailing when "extensions.InstallTrigger.enabled" is set to `false`
(but they are completely uneffected when "extensions.InstallTriggerImpl.enabled" is set to `false`, because the
InstallTrigger global is still defined, just set to null instead of providing the API defined by the
InstallTriggerImpl interface).
This patch changes name of the global properties to which they are set to "A" and "B", to make sure those properties
are going to be in rows listed in the DOM panel before the two non-standard globals `InstallTrigger` and `SpecialPowers`
and so that the visibility of the InstallTrigger global (either disabled or still visible) doesn't affect the test case.
Differential Revision: https://phabricator.services.mozilla.com/D148975
Changing the pattern for toggling recording to ensure that pause/resumes actually
start or stops watching resources before the ui states gets updated.
Differential Revision: https://phabricator.services.mozilla.com/D148953
Depends on D148489
This allows to properly set the cssErrorReportingEnabled flag on its docShell.
While we are not interested in css errors for this fallback window, the windowglobal target actor
will automatically set the flag on new root browsing contexts only if the previous one had the flag
set. This way when we switch to a valid webextension document (eg a popup), the flag will be set
and CSS errors will be reported.
Differential Revision: https://phabricator.services.mozilla.com/D148836
This window does not share the regular extension principal so we cannot fetch
the addonId from the principal in the same way as we do for other documents.
Instead we append the addonId to the URL and provide a new helper in browser-context-helpers
to extract the addonId from a browsingContext.
This helper should work transparently from the parent process and the content process, and
should support browsing context for regular extension documents as well as browsing contexts
for fallback windows.
Differential Revision: https://phabricator.services.mozilla.com/D148489
We use to transform expression like `await obj` into
```
(async () => {
return await obj;
})()
``
So we were basically returning the expression, wrapped in an async iife, adding
a `return` statement before the last statement.
But in the case the last statement is an `AwaitExpression`, we can simply return
the argument, stripping the `await` keyword.
This fixes an issue when awaiting for an object with a `then` getter would execute
the getter twice.
A test case is added in mochitest, and unit test are updated to reflect the new
output.
Differential Revision: https://phabricator.services.mozilla.com/D148806
Since Network monitoring is switched of by default in the browser console, we need to
switch it on explicitly for the browser_console_context_menu_entries.js test.
Differential Revision: https://phabricator.services.mozilla.com/D148776
This helps compute it only once per source and help simplify the updateTree layer.
We no longer have to path thread/mainThreadHost everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D147780
We were using `isInvalidUrl` late in the process of updateTree layer to ignore sources
and prevent displaying them in the SourceTree.
But getDisplayedSources is dedicated to the SourceTree and can eagerly filter out the right sources
right away.
Also getDisplayedSourceIDs is already accepting only source with a URL,
so we don't have to recheck if the source is having a URL.
I extended mochitest test coverage to replace the removed jest tests.
Differential Revision: https://phabricator.services.mozilla.com/D147777
At the end, we weren't using the url but only the host.
And "debuggee" is pretty vague, let's clarify with "main thread".
Differential Revision: https://phabricator.services.mozilla.com/D147762
Before, only "shown source" would really expand the tree to show the source in tree,
whereas "highlight" would only highlight the folder that is opened
(in case the source isn't visible and folder isn't expanded).
But when we select a new shown source, we also update the selected location,
which also changes the highlight items.
It is significantly clearer to only have "selected source" and have the SourceTree
to automatically expand the tree and show the selected source.
(Also a sneaky call to .reverse() was mutating the `highlightedItems` props...)
Differential Revision: https://phabricator.services.mozilla.com/D147759
The safe mode dialog will be displayed instead of the browser toolbox when the previous browser
toolbox has been closed too brutaly. This happens every now and then.
Also, when you opened a URL from the browser toolbox, this will then trigger a transient
browser window that appears and immediately disappear when opening the browser toolbox
all next time you start it. It might be related to session restore, but it looks like it is not enough
to get rid of this blinking window.
Differential Revision: https://phabricator.services.mozilla.com/D148515
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
The multiprocess browser toolbox is on by default in BETA, so we
need to switch it on explicitly for the addon extensions to be listed.
Differential Revision: https://phabricator.services.mozilla.com/D148392
Highlights
- Network monitoring is turned off by default in browser console/ browser toolbox console on initial load.
- A new "Enable Network Monitoring" setting is added to enable users toggle on an off as they desire.
- The user setting is persisted across toolbox reopens.
Differential Revision: https://phabricator.services.mozilla.com/D145234
The devtools.browsertoolbox.fission should not be read on the server but should instead be provided to the server by the client.
The breakage can be reproduced if you try to debug a Firefox desktop with devtools.browsertoolbox.fission = false from a Firefox with devtools.browsertoolbox.fission
= true.
Differential Revision: https://phabricator.services.mozilla.com/D148129
Either of the two changes fixes the reported issue.
On the frontend side, we weren't listening to DevToolsClient/connection close.
So that there was no guarantee that the Browser Toolbox would close if the remote connection is lost.
We were actually depending on Launcher.close to be called (it is called correctly)
and complete `dbgProcess.kill()`, which apparently doesn't always work during shutdown.
It looks like `SubProcess.kill` was made slower and didn't always had time to complete
because on the server side, the Parent Process Target actor was trying
to switch from browser.xhtml to chrome://extensions/content/dummy.xhtml.
But this document is being destroyed and the target as well as all children
actors and watchers were still trying to debug stuff and were all throwing.
Correctly destroying the parent process target actor when browser.xhtml is closed
seems to allow SubProcess.kill to complete...
And thanks to client's closed listener, even if we stop killing the process,
the browser toolbox process will close by itself.
Differential Revision: https://phabricator.services.mozilla.com/D148128
Highlights
- Network monitoring is turned off by default in browser console/ browser toolbox console on initial load.
- A new "Enable Network Monitoring" setting is added to enable users toggle on an off as they desire.
- The user setting is persisted across toolbox reopens.
Differential Revision: https://phabricator.services.mozilla.com/D145234
We were instantiating one new Loader per DevToolsFrameChild instance.
This patch tries to share this loader with all the instances as well as share it
with the one used to load DevToolsServer when we are running in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D147257
When resources related to a given Target are notified via the Watcher actor,
we have to ensure waiting for the TargetFront to be fully initialized.
That's because code watching for resources expect the target front to be attached
and have its thread front already available.
Differential Revision: https://phabricator.services.mozilla.com/D143408
Wait for the cursor to be set.
We take this opportunity to inline the functions that were only called once,
as well as refactor a few things to make the test easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D147259
The selector is already sorting the breakpoints,
so there is no need to re-sort them in the component.
Also Array.sort(stringA-stringB) was misbehaving.
Then I'm using getSourcesMap in order to avoid calling getBreakpointList many times.
Otherwise getSourcesForBreakpoints has to receive the state object
in order to retrieve the source objects.
Differential Revision: https://phabricator.services.mozilla.com/D146426
breakableLines wasn't correctly memoized for sources other than the original ones.
This patch at least fix this for regular JS files sources, but the issue still
happens for HTML sources having more than one source actor.
Differential Revision: https://phabricator.services.mozilla.com/D147195
In the frontend we end up having special sources, related to many source actors.
These are the sources for HTML pages, which have one unique source object.
But each inline <script> tag will have its own source actor.
All these sources actors will be bound to this unique source for the HTML page.
Differential Revision: https://phabricator.services.mozilla.com/D144412
The characteristics of the throttling profile are not really accessible anywhere.
At least having them in the button title can help.
I started reorganizing throttling profiles as instances of a ThrottlingProfile base class, because
that should be useful when we implement custom profiles
Differential Revision: https://phabricator.services.mozilla.com/D147131
In the frontend we end up having special sources, related to many source actors.
These are the sources for HTML pages, which have one unique source object.
But each inline <script> tag will have its own source actor.
All these sources actors will be bound to this unique source for the HTML page.
Differential Revision: https://phabricator.services.mozilla.com/D144412
The selector is already sorting the breakpoints,
so there is no need to re-sort them in the component.
Also Array.sort(stringA-stringB) was misbehaving.
Then I'm using getSourcesMap in order to avoid calling getBreakpointList many times.
Otherwise getSourcesForBreakpoints has to receive the state object
in order to retrieve the source objects.
Differential Revision: https://phabricator.services.mozilla.com/D146426
We can immediately "attach" the descriptor as it gets instantiated.
So that the frontend no longer need to call this before doing anything around the worker.
I also renamed the descriptor front method "attach" method,
in order to better highlight how special it is.
Hopefully we can drop this once the worker targets are created by the server.
i.e. when we enable service side worker targets for the browser toolbox,
which includes supporting service workers.
Differential Revision: https://phabricator.services.mozilla.com/D146787
There's an issue in React 16 that only occurs when MessageChannel is available
which prevents the nodeJS process to exit.
MessageChannel support was added in Node 15, so when we try to update to Node 16,
it caused a problem in CI.
Differential Revision: https://phabricator.services.mozilla.com/D146906
We already have translation strings in `device.properties`, so we can use them.
String for `custom` type was missing, so we add it.
Assertions are added in test to check that we do have the expected labels in the UI.
Differential Revision: https://phabricator.services.mozilla.com/D146784
Two tests had to be changed.
The first test had to be changed because I removed redundant error message logging from requestStorageAccess and its network of helpers.
The second is because we were acting out-of-specification and stopping nested iframes from using the storage access API. I could have done this in a second bug, but I felt like doing it here made sense enough.
Depends on D146343
Differential Revision: https://phabricator.services.mozilla.com/D146344
In `viewSourceInStyleEditor`, we used to first load the styleeditor, and then
select the stylesheet and show the panel. This mean that when clicking on a location
from the rule view, there would be some delays before we show any feedback to the user.
Since the load promise for the panel only settles once we watched for all existing
stylesheets and loaded their content for each of them, it could take a while in
cases where we have lots of stylesheets, like in the BrowserToolbox.
So here we modify `viewSourceInStyleEditor` to directly select the styleeditor and
passing it a stylesheet that can be added right away, in case the panel wasn't
loaded yet, without waiting for the stylesheets to be watched.
We take this as an opportunity add a test when `viewSourceInStyleEditor` is called
with a stylesheet not used on the page, and check that it does open a view-source tab.
Differential Revision: https://phabricator.services.mozilla.com/D146540
Just testing that the editor and the new label work as expected since
these are the things that I could find broken in my reduced examples.
Differential Revision: https://phabricator.services.mozilla.com/D146688
This just intends to alleviate the more noticeable problem when the cache grows
too large by avoiding iterating through the array every time something changes.
There still remains the work of limiting the size of this based on what the UI
is capped at, but that can come later.
Differential Revision: https://phabricator.services.mozilla.com/D142279
I tried to pick thread groups that are part of GeckoView (Gecko), might be
common to GeckoView products (Nimbus), and the Android ecosystem (Kotlin
coroutines) instead of threads that are fenix-specific.
Differential Revision: https://phabricator.services.mozilla.com/D144753
The issue here is it seems like WebExtensionPolicy is not always available on the Cu global,
therefore failing when trying to get the extension policy name.
in this example when adding sources from the browser toolbox (i'm still not completely sure why)
The solution here is changing to using the ExtensionProcessScript which works for the web and browser
toolbox.
Also added a `console.warn` so we get some notification when this fails.
Differential Revision: https://phabricator.services.mozilla.com/D144787
The test was only waiting for addTab to resolve, waiting for the proper toolbox-ready event could reduce intermittent issues.
Differential Revision: https://phabricator.services.mozilla.com/D146530
If the walker actor was initialized, we assume the document is ready enough and a root node can be returned if available.
A new test was added for a slow loading document.
Differential Revision: https://phabricator.services.mozilla.com/D146464
This `global` variable is used for accessing Error prototypes, and they're
properties of the shared global (`globalThis`), not per-JSM global (`this`).
Differential Revision: https://phabricator.services.mozilla.com/D144131
This tries to fix a race issue where, on reload, the pause event fires way before the
related source is available. This is an issue the had the potential on happening at some point.
This fix is not super perfect but with the trottling of sources there is no guurantee that sources will
always be available before pause event fires.
This pattern is also used for source actors. waitForSourceActorToBeRegisteredInStore.
Differential Revision: https://phabricator.services.mozilla.com/D145925
The command requires having network resource command support,
which is still not enabled everywhere (e.g. non-multiprocess browser toolbox).
We simply remove the backward compat comment but leave the check on network
resource command support.
Differential Revision: https://phabricator.services.mozilla.com/D145890
This removes FlameGraph.js, Graphs.js, GraphsWorker.js, LineGraphWidget.js, MountainGraphWidget.js
and their related tests.
DevToolsWorker tests that were relying on GraphsWorker.js are updated to use a test-specific blob worker.
Differential Revision: https://phabricator.services.mozilla.com/D145462
We using Ctrl|Cmd+P as Ctrl|Cmd+F is used for a in-file search in
the CodeMirror instance.
We're tesing the keyboard shortcut in browser_style_editor_filter.js
by using it instead of manually calling input.focus and clearing it
programatically.
Differential Revision: https://phabricator.services.mozilla.com/D145057
For some reason, the new test added in the previous patch has an impact on this test:
when checking the disk cache, there's a `mochi.test:8888/tests.json` entry, and
since the test was only checking if there was an entry with the `mochi.test:8888` entry,
it was failing.
I wasn't able to understand why we have this entry in the cache, but it reveals
that the test check is a bit too broad, since what we cares about is simply to
know if the fetched stylesheet was added in the disk cache.
So here we're doing just that, checking that the fetched stylesheet wasn't added
to the disk cache.
Depends on D144723
Differential Revision: https://phabricator.services.mozilla.com/D145344
The patch adds a filter input in the xhtml file, which will filter the list
of stylesheets displayed on the left side, based on the stylesheet name.
If the active stylesheet is filtered-out, the first visible one gets selected.
If all the stylesheet are filtered-out, a label is displayed indicating that
the search doesn't match any stylesheet.
The splitview CSS already had rules for this behaviour, so we're reusing what's
already there, re-adding the placeholder for the "all filtered" message.
This had an impact on keyboard navigation; the list is sorted by `ordinal` property,
which drives a `MozBoxOrdinalGroup` style property (similar to `order` on a flex item).
The navigation used to simply get the active ordinal, and move to the next one.
Now, the "next" ordinal could be hidden, so we change the behavior to move the focus
to the next (or previous), visible item in the list.
A test is added to check that everything works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D144723
See the comment in the file explaining it. For a case of logging 100k numbers,
this dropped the time per number from 15 microseconds to 9 with the console
closed, and 55 microseconds to 38 with the console open. I think we could shave
off more with a native approach, but I don't know that it's worth it and it's
much more likely for that to introduce bugs.
Differential Revision: https://phabricator.services.mozilla.com/D143782
The patch adds a filter input in the xhtml file, which will filter the list
of stylesheets displayed on the left side, based on the stylesheet name.
If the active stylesheet is filtered-out, the first visible one gets selected.
If all the stylesheet are filtered-out, a label is displayed indicating that
the search doesn't match any stylesheet.
The splitview CSS already had rules for this behaviour, so we're reusing what's
already there, re-adding the placeholder for the "all filtered" message.
This had an impact on keyboard navigation; the list is sorted by `ordinal` property,
which drives a `MozBoxOrdinalGroup` style property (similar to `order` on a flex item).
The navigation used to simply get the active ordinal, and move to the next one.
Now, the "next" ordinal could be hidden, so we change the behavior to move the focus
to the next (or previous), visible item in the list.
A test is added to check that everything works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D144723
This patch also adds assertions for breakpoints on the server to the
breakpoints reload tests. This also asserts that the breakpoint is not removed
on the server when related source no longer exists after a reload
Differential Revision: https://phabricator.services.mozilla.com/D142545
This Rep hooks into the default display of objects and outputs a JsonML (http://www.jsonml.org) representation of them if custom formatters are enabled and a custom formatter is defined for them.
It handles headers and bodies of custom formatters. Bodies are handled asynchronously from their corresponding headers.
Because custom formatters allow a website to provide CSS styles to be used for formatting an object within the DevTools, those styles are filtered first to avoid breaking their layout.
It is currently only applied to the output of the Webconsole and within the variable value popup and the watch expressions within the Debugger.
***
Differential Revision: https://phabricator.services.mozilla.com/D140119
This patch also adds assertions for breakpoints on the server to the
breakpoints reload tests. This also asserts that the breakpoint is not removed
on the server when related source no longer exists after a reload
Differential Revision: https://phabricator.services.mozilla.com/D142545
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 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 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
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
This is a naive implementation where we re-create a ConsoleOutput
element, reusing the existing store, and passing a specific prop
so all the messages would be rendered.
In order to include stacktraces, we pass a `0` initial render delay to the
callsites of the `SmartTrace` component.
We take this as an opportunity to extend the test coverage of `SmartTrace` around
this feature.
Differential Revision: https://phabricator.services.mozilla.com/D142189
This is a naive implementation where we re-create a ConsoleOutput
element, reusing the existing store, and passing a specific prop
so all the messages would be rendered.
In order to include stacktraces, we pass a `0` initial render delay to the
callsites of the `SmartTrace` component.
We take this as an opportunity to extend the test coverage of `SmartTrace` around
this feature.
Differential Revision: https://phabricator.services.mozilla.com/D142189
Since we now have distinct list of Reps for callsites that
are handling native object and not grips, we can remove
the check to isGrip in the other reps.
This will allow us to not have to manage actors created
for getting the grip of an object inside the grip preview
(should be handled in Bug 1762553).
Differential Revision: https://phabricator.services.mozilla.com/D142659
We only need the frame actor ID.
It might be helpful to expose the frame front instead,
but at the end of the day, the server expects the frame actor ID.
Differential Revision: https://phabricator.services.mozilla.com/D143041
This should be ready to review. However, I will include a big caveat that I
tried to do things the Reacty way, and it felt really awkward. Notably, I used
a React functional component, because they seem to be recommended as the
Right Way to do things, but because of all the state we need to keep track of,
as well as just the props that we don't want to lexically access because then
they can be stale, it felt really wrong. Guidance is welcome.
However, the core logic should be ready for review, so focus on that, and let
me know if I need to move anything around to make it more palatable.
Depends on D138030
Differential Revision: https://phabricator.services.mozilla.com/D138031
This is just some clean up - looks like this was once used to more dynamically
map strings to types, but now all of the mappings are explicitly accessed via
string literals.
Differential Revision: https://phabricator.services.mozilla.com/D138030
This fixes the test included in the patch. However, it makes no guarantees to not
break other things without the virtualization patch, which changes this to observe
the bottom buffer element instead of the last message.
Differential Revision: https://phabricator.services.mozilla.com/D142362
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
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
I'm also improving waitForSourcesInSourceTree to timeout faster and have an helpful error message,
clearly highlight the unexpected or missing sources.
In source tree test, it looks like adding named eval slow things down for the quick open.
So I tuned the related assertion to avoid intermittents.
We were having intermediate updates showing up named eval instead of the source with query string.
Differential Revision: https://phabricator.services.mozilla.com/D142340
Remove httpi.css that was only used by the console, and load the individual
CSS files instead.
Remove widgets.css, which is a relic of the old console.
Remove textActions.ftl import, which doesn't seem to have any effect.
Differential Revision: https://phabricator.services.mozilla.com/D142658
This removes now unused rules (targetting element from the old webconsole), and
merge rules targetting similar elements.
Differential Revision: https://phabricator.services.mozilla.com/D142656
- `category` isn't being used for console messages, so we can remove it
- `chromeContext` is only helpful when it's true, so we can omit it when it is not
We take this as an opportunity to test more properties and more message types
in browser_resources_console_messages.js.
Differential Revision: https://phabricator.services.mozilla.com/D141599
Tetsuharu Ohzeki
Alexandre Poirot
Nicolas Chevobbe
criss
Tooru Fujisawa
Luca Greco
Hubert Boma Manilla
Julian Descottes
Michael Ratcliffe
colin_czb
Emilio Cobos Álvarez
Andrew McCreight
Molnar Sandor
Butkovits Atila
Iulian Moraru
Gabriele Svelto
Andreea Pavel
Cosmin Sabou
Tom Schuster
Cristian Tuns
Benjamin VanderSloot
Doug Thayer
Michael Comella
Mark Banner
Sebastian Hengst
Luke Swiderski
Norisz Fay
Greg Tatum
Feng Yu
Sebastian Zartner
Claudia
Raphael Ferrand
Marian-Vasile Laza
Noemi Erli
Tim Huang
André Bargull
Kagami Sascha Rosylight
Gerald Squelart
Frederik Braun