We already have a fallback for items that aren't in a worker scope, we should have the same for ones that are. This means we don't need single maps (foo.js -> foo) in modules.json, and also we can identify more as explicit variables, so that no-unused-vars can detect them.
Differential Revision: https://phabricator.services.mozilla.com/D13299
--HG--
extra : moz-landing-system : lando
This also adds a console test to make sure we don't regress
this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13762
--HG--
extra : moz-landing-system : lando
This also adds a console test to make sure we don't regress
this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13762
--HG--
extra : moz-landing-system : lando
We used to re-render the component each time the sourcemapService
would give us a result for a single frame.
Combined with the frame grouping system, this could trigger
weird re-layout and might confuse user.
What's done in this patch is that when mounting, if a sourcemapService
is passed, we don't render anything, and start a race between
a delay of 300ms and the sourcemap results for *all* the frames.
If we don't have the original frames within 300ms, we render the
bundled frames. But, whenever we have the sourcemap results, we
trigger a re-render of the component.
This gives some room for the sourcemapService to fetch map files
without re-ordering things on the screen.
A test case is added to ensure we have the expected renders
when the sourcemap service takes more time than the inital delay.
We already have a case where the sourcemap service resuls are
received before the initial delay.
We also take this as an opportunity to fix minor CSS issues.
Differential Revision: https://phabricator.services.mozilla.com/D12037
--HG--
extra : moz-landing-system : lando
This patch only removes condition for the preference,
since removing the preference would require more important
code changes that might not be good to land during the
soft freeze.
Differential Revision: https://phabricator.services.mozilla.com/D13857
--HG--
extra : moz-landing-system : lando
This change cleans up a lot of the getCurrentDisplay's logic which was unnecessarily
complex, it seems.
It also extracts the logic to walk up the DOM to find flex/grid containers to a
reusable functions.
Finally, this new extracted function is now used in the walker to determine if a text
node can be inlined in its parent element or not.
Differential Revision: https://phabricator.services.mozilla.com/D13677
--HG--
extra : moz-landing-system : lando
When a declaration is disabled, it is tracked as removed in the Changes panel.
When deleting a disabled declaration, we take care not track it as removed again.
Includes stricter checks when matching previously tracked added and removed declarations.
Differential Revision: https://phabricator.services.mozilla.com/D13616
--HG--
extra : moz-landing-system : lando
This removes the instrumentation to test the basic telemetry for the Changes panel (open count, time opened).
Differential Revision: https://phabricator.services.mozilla.com/D13691
--HG--
extra : moz-landing-system : lando
This means that for the File URI content process, we end up closing RDM if the page
navigates. This appears to be an acceptable trade-off, as this is the behaviour we've
been shipping since bug 1453519 landed (Firefox 61).
Differential Revision: https://phabricator.services.mozilla.com/D13331
--HG--
extra : moz-landing-system : lando
Until we implement intentional persistence of changes between page refreshes, the Changes actor should clear its stack of changes to avoid polluting the next DevTools session.
Differential Revision: https://phabricator.services.mozilla.com/D13618
--HG--
extra : moz-landing-system : lando
Flex elements can be both containers and items at the same time. When they get selected in the inspector
the sidebar shows both the container accordion and the item accordion.
This changeset makes sure the container accordion is displayed before the item accordion only when
the element is selected from the markup-view.
Differential Revision: https://phabricator.services.mozilla.com/D13416
--HG--
extra : moz-landing-system : lando
Depends on D13257
I think webextensions + console is already thoroughly tested in
devtools/client/aboutdebugging/test/browser_addons_debug_webextension_*.js
Luca, are there features that we might be missing after removing this?
Differential Revision: https://phabricator.services.mozilla.com/D13258
--HG--
extra : moz-landing-system : lando
Adds entries to Histograms.json, Scalars.yaml and Events.yaml to
account for the Changes panel when measuring time spent with the panel
in view and opening count. This leverages pre-existing instrumentation
used for other Inspector sidebar panels.
Differential Revision: https://phabricator.services.mozilla.com/D13085
--HG--
extra : moz-landing-system : lando
The browser_addons_debug_bootstrapped addon is completely removed because it is already
covered for webextensions with browser_addons_debug_webextensions.js
Other have either been migrated to use webextensions.
Differential Revision: https://phabricator.services.mozilla.com/D13255
--HG--
extra : moz-landing-system : lando
This is all the style-system work needed for this.
This implements the concept of legacy shorthands, teaches tests to understand
it, and adds a few more tests for these properties in particular.
The WPT even caught a few WebKit / Blink bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=906336https://bugs.webkit.org/show_bug.cgi?id=191803
This doesn't change the layout behavior for page-break-before: always, since
it'd stop breaking in multicol and such. Similarly, break-before / break-after:
column and page still behave the same, I'll file followups for those given
comment 22.
Differential Revision: https://phabricator.services.mozilla.com/D12211
--HG--
extra : moz-landing-system : lando
This also adds a telemetry count for the grid highlighter being turned on by the
markup view, which was not in place when we added the telemetry for the grid
highlighter.
Storage events are fired either directly after getting response from synchronous SetItem call or through observers. When a new onstorage event listener is added, we sycnhronously register an observer in the parent process. There's always only one observer actor per content process.
PBackgroundLSDatabase is now managed by a new PBackgroundLSObject protocol. PBackgroundLSObject is needed to eliminate the need to pass the principal info and document URI everytime a write operation occurs.
Preparation of an observer shares some states with preparation of a datastore, so common stuff now lives in LSRequestBase and preparation of a datastore now implements a nested state machine.
This patch was enhanced by asuth to drop observers only when the last storage listener is removed.
EventListenerRemoved is invoked on any removal, not just the final removal, so we need to make sure it's the final removal before dropping observer.
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
In Bug 1462394, we moved the autocomplete data handling
out of the JsTerm to the Redux store. In the process, we
regress some cases like `await n`, which should display
`navigator`, but isn't anymore when the user types the
whole sequence. Ctrl+Space would still show the popup,
which indicates that the issue is not on the server-side.
This issue is caused because our new code decides that
we should hit the cache when typing the `n`, and there's
nothing in the cache.
Previously, we were clearing the cache as soon as the input
last string wasn't alphanumeric, which we don't anymore.
To fix that, instead of relying on the last string of the
input (which could be wrong in cases like `x.["hello `), we
clear the cache when the autocomplete service returns a null
`matches` property.
In the JsPropertyProvider, we use to return null whenever
there isn't any search done (incorrect input, empty match prop, …).
So it seems like a good idea to bust the cache when the
server returns null.
This requires some changes to the autocomplete service, as well
as some in jsPropertyProvider (e.g. to handle `await `).
Tests are added both on the client and the frontend to make sure
we don't regress this (those tests fail without the actual fix).
Differential Revision: https://phabricator.services.mozilla.com/D13231
--HG--
extra : moz-landing-system : lando
