The issue was that if a user typed a legitimate letter,
then, quickly after (i.e. before the autocompletion results
are here) hit Enter or Tab, the resulting input value would
be erroneous.
This is because we retrieve the value to insert from the
autocomplete popup, which at that time, is out-of-date, for
this brief moment.
The fix consists in updating the preLabel property of the
autocomplete popup items in order to get the proper
completion if the user ever hit enter, tab or arrow right.
We also take this as an opportunity to have a mechanism
to be able to cancel a registered update.
Differential Revision: https://phabricator.services.mozilla.com/D52376
--HG--
extra : moz-landing-system : lando
As Chrome has removed support for the HPKP (HTTP Public Key Pinning) header,
continuing to support it in Firefox is a compatibility risk. This patch adds
the preference "security.cert_pinning.hpkp.enabled" and sets it to false by
default. As such, the platform will no longer process the HPKP header nor
consult any cached HPKP information for certificate pins.
Preloaded (statically-compiled) pins are still enabled in Firefox by default.
This patch also disables dynamically setting pins via our remote security
settings infrastructure, as it uses the same backend and represents similar
compatibility risk.
Differential Revision: https://phabricator.services.mozilla.com/D52773
--HG--
extra : moz-landing-system : lando
Depends on D52560
- Adds a test to check that the steps for [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944) no longer cause an issue.
- Introduces a new `updateDeclaration()` helper in `devtools/client/inspector/rules/test/shared.js` to simplify updating property names and values in one step.
- Updates `toggleDeclaration()` to remove unused `inspector` parameter; updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D52561
--HG--
extra : moz-landing-system : lando
The fix for [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) created a situation in the [`Rule.onDeclarationsChanged()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/inspector/rules/models/rule.js#869-887) whereby the `isUsed` state of client-side declarations was made to point to a fixed `isUsed` state received from the server, thus losing sync with the latest state of the `StyleRuleActor`. Until another "declarations-update" event was fired from the `StyleRuleActor`, the rule's declarations' `isUsed` flag would point to the state with which they were overwritten on the last event handler call.
As a reminder, the root cause of [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) was the inability force a "refresh" of the `StyleRuleFront` so it picked-up the latest `isUsed` state for its declarations when they depend on other declarations from other rules (ex: `justify-content: center` depends on `display:flex`). Therefore, the "declarations-updated" event was introduced with a payload of changed declarations to overwrite the client-side ones. It was convoluted, but it worked.
However, while investigating the cause of this newer bug [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944), I discovered an unusual but perhaps expected side-effect: when dispatching an event over the protocol with a payload of the `StyleRuleActor`, its corresponding `StyleRuleFront` on the client would "refresh" automatically (meaning that, looking up state on the previous front reference would point to the latest state from the actor) . The client doesn't even need to use this payload to replace its previous front reference. Surprisingly, the client doesn't even need to explicitly listen to the event which carries the `StyleRuleActor`/`StyleRuleFront` reference. So long as a previous reference of the front exists on the client, it will point to the updated state of the actor. I haven't been able to identify whether this is a known and expected behavior, so I'm pinging @jdescottes and @ochameau to weigh in on the validity of these findings.
Relying on this behavior, the fix for both [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) and [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) involves simply emitting an event, "rule-updated", with the `StyleRuleActor` instance as payload whenever its internal state changes meaningfully so the corresponding front updates. The client will pick-up the latest `isUsed` state of declarations from its reference to the `StyleRuleFront`.
---
Another way to check this behavior and hypothesis is to do the following:
- In [`StyleRuleActor.setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1704) replace `return this` with `return null`; (this will no longer return the `StyleRuleActor` over the protocol; it's not explicitly used on the client anyway).
- In the spec, replace the [`setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/shared/specs/styles.js#222) return value with `RetVal("nullable:domstylerule")` so the protocol doesn't throw an error when getting the `null` from the actor.
- Make a build.
- Then, open the Inspector -> Rules View and change the value of a valid declaration, say: `display: block`, to something invalid, like `display: booo`. Notice that the declaration is no longer marked invalid with a warning sign. That's because the declaration's [`isValid`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1447) flag is set on the actor but it no longer syncs with the client which uses the corresponding front to render the declaration after the change. Not returning the `StyleRuleActor` over the protocol breaks this sync actor-front sync.
Differential Revision: https://phabricator.services.mozilla.com/D52560
--HG--
extra : moz-landing-system : lando
The positioning of the arrow was correct, but due to the way the arrow was rotated, the visual center of the arrow did not match the center of the arrow box
Backing out the JS change here, CSS patch later in the queue
Differential Revision: https://phabricator.services.mozilla.com/D52668
--HG--
extra : moz-landing-system : lando
It's being used in the client and server, and so is a shared file.
Differential Revision: https://phabricator.services.mozilla.com/D52247
--HG--
rename : devtools/server/performance-new/gecko-profiler-interface.js => devtools/shared/performance-new/gecko-profiler-interface.js
rename : devtools/server/performance-new/moz.build => devtools/shared/performance-new/moz.build
extra : moz-landing-system : lando
To test this feature, check the "JSTracer" feature, and the user should be
prompted with a message bar to restart the browser. This will then set the
proper environment variable. Unfortunately, currently the user can still do
this even if a feature is not available in the build. See Bug 1585659.
Differential Revision: https://phabricator.services.mozilla.com/D50085
--HG--
extra : moz-landing-system : lando
Let's set javascript.options.asyncstack in the test to
have the async stacktrace displayed.
Differential Revision: https://phabricator.services.mozilla.com/D52697
--HG--
extra : moz-landing-system : lando
In the devtools-browser.css file the min-height is set to 29px to the class .devtools-toolboc-bottom-iframe
Differential Revision: https://phabricator.services.mozilla.com/D52115
--HG--
extra : moz-landing-system : lando
Also removed the outdated comment referring to the tests of the old aboutdebugging which are no longer in the source control.
Seems like this was the only leftover comment of the sort.
Differential Revision: https://phabricator.services.mozilla.com/D52528
--HG--
extra : moz-landing-system : lando
The function is only used in tests, which is a bit concerning
as we should test the actual function being used (evaluateJSAsync).
Differential Revision: https://phabricator.services.mozilla.com/D52331
--HG--
extra : moz-landing-system : lando
The devtools highlighter is broken with browser.xhtml when scroll frames
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D52104
--HG--
extra : moz-landing-system : lando
The function is only used in tests, which is a bit concerning
as we should test the actual function being used (evaluateJSAsync).
Differential Revision: https://phabricator.services.mozilla.com/D52331
--HG--
extra : moz-landing-system : lando
It's not obvious to me what the culprit is, but it may be because
of the clearOutput call somehow.
Let's see if this fix the intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D52321
--HG--
extra : moz-landing-system : lando
The tests are rewritten so we only have one test per
stub type. The stubs can be re-generated by passing
the --setenv WEBCONSOLE_STUBS_UPDATE=true arg when running
mach test.
We take this as an opportunity to not store the Messages
directly, but we generate them programmatically, which would
still reveal a bug as most of the test import messages.
Since we're doing that, some messages aren't localized, so
we need to add them to the L10N fixtures we have (which is
revamped a bit as getStr was getting too complex).
Differential Revision: https://phabricator.services.mozilla.com/D51596
--HG--
extra : moz-landing-system : lando
The devtools highlighter is broken with browser.xhtml when scroll frames
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D52104
--HG--
extra : moz-landing-system : lando
This situation can happen if a locale does not set a value for a localized devtools shortcut, ie writes
toolbox.elementPicker.key=
(with nothing after the = sign)
Differential Revision: https://phabricator.services.mozilla.com/D52099
--HG--
extra : moz-landing-system : lando
Using next-line is less error prone for refactorings than wrapping methods with enable/disable blocks.
Differential Revision: https://phabricator.services.mozilla.com/D51782
--HG--
extra : moz-landing-system : lando
The nullish coalescing operator was added last week in Spidermonkey.
It looks like there isn't anything to do to support it on the console
side, so we only add a test for the autocompletion after it, to make
sure we don't regress this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D51632
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
In the Browser Toolbox, we fetch all types of targets, including frames and processes.
But the main process target, which is the top level target for the Browser Toolbox,
is also returned by listProcesses and so is reported as duplicated.
Differential Revision: https://phabricator.services.mozilla.com/D51630
--HG--
extra : moz-landing-system : lando
The existing checks were also enabling additional target tracking of the TargetList
for the Browser Content Toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D51783
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
The issue was in commands.js evaluateJSAsync function where
we were trying to use an undefined parameter.
The regression wasn't spotted earlier because we only have
mocha test for CSS warning, and they don't assert this
codepath.
A mochitest is added on this patch to ensure CSS Warnings
can be expanded, that they display the impacted elements
as expected, and that clicking on the icon selects the
expected element in the inspector.
Differential Revision: https://phabricator.services.mozilla.com/D51627
--HG--
extra : moz-landing-system : lando
This method is very asynchronous, called on reflows and throttled. Which means it has a high chance of intermittently failing after destroy.
Differential Revision: https://phabricator.services.mozilla.com/D51663
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
When creating grid and display badges in the markup view, ensure they listen only to their corresponding highlighter events.
Differential Revision: https://phabricator.services.mozilla.com/D51137
--HG--
extra : moz-landing-system : lando
@gl can you take a look at the DevTools test added here?
@nika @mconley I used this.browsingContext.docShell.isContent here to rule out chrome-privileged documents. Do you know if there is better way to check if the current document is chrome-privileged or not?
Differential Revision: https://phabricator.services.mozilla.com/D51320
--HG--
extra : moz-landing-system : lando
This component will help build and maintain the list of all the Targets.
Making it easier to:
* listen for all the targets: TargetList.watchTargets/unwatchTargets,
* iterate over all the existing ones: TargetList.getAllTargets,
* get all the TargetScoped fronts of all the targets: TargetList.getAllFronts.
Differential Revision: https://phabricator.services.mozilla.com/D48857
--HG--
extra : moz-landing-system : lando
Wait for the messages to be displayed, and requestLongerTimeout,
as test failures logs seem to indicate that slower machine take
more than 30s to run the test.
Differential Revision: https://phabricator.services.mozilla.com/D51562
--HG--
extra : moz-landing-system : lando
This makes it possible for the menus to not be constrained
to the panel boundaries if they are taller than the panel
itself (which could be the case for the simulate menu as
it has lots of items).
We need to style the button with a link role in the toolbox
CSS so they don't look like real buttons.
Differential Revision: https://phabricator.services.mozilla.com/D50461
--HG--
extra : moz-landing-system : lando
Finally, let's move the actual IO away from the main thread.
This means there are now 3 ways of looking for plugins:
1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable
on the main thread.
2. loading plugins from LoadPlugins. This will:
a) first check prefs and report the flash plugin based on that information,
if the prefs indicate it exists (using the callback provided by
nsPluginHost).
b) then hopefully dispatch to a background thread, where it will read
pluginreg.dat, scan the appropriate folders on disk, and see if
anything changed. Once done, it sets mFinishedFinding to true and
re-dispatches itself to the main thread.
c) then on the main thread, it reports any changes to nsPluginHost.
3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main
thread.
Note: if ReloadPlugins is called, we intiially do (1), but if we find
changes, we clear out the set of known plugins and then run LoadPlugins
again (meaning we go through 2 (or 3 if 2(b) fails)). This is how
reloading plugins worked prior to my changes and I've attempted not to
change it.
In order for this to work, there are some other changes in this commit:
- the sandbox prefs are being read "early" and cached for flash vs
"everything else". We can't access prefs on non-main threads without
using StaticPrefs, which doesn't seem worth it here.
- some of the plugin tag classes are moved to threadsafe refcounting.
This is a bit unfortunate, but because they're instantiated on a non-
mainthread, and then later used on the main thread, despite the
fact that the architecture means nothing tries to touch them from
more than one thread at once, without threadsafe refcounting we hit
asserts in debug mode if we add references to them back on the main thread.
- we add shutdown blocking for pluginfinding. We don't really want to
be halfway through finding plugins and then trying to shut them down,
or re-instantiating plugins after they've been unloaded.
- we keep a reference to the "pending" pluginfinder instance while
doing lookups away from the main thread (ie (2)), to avoid re-entrancy or
trying to write to pluginreg while we're reading it somewhere else,
etc. If there's an attempt to do more plugin finding while this is
ongoing, we flip mDoReloadOnceFindingFinished and do a reload once
our initial lookups are complete.
Depends on D48331
Differential Revision: https://phabricator.services.mozilla.com/D48332
--HG--
extra : moz-landing-system : lando
Finally, let's move the actual IO away from the main thread.
This means there are now 3 ways of looking for plugins:
1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable
on the main thread.
2. loading plugins from LoadPlugins. This will:
a) first check prefs and report the flash plugin based on that information,
if the prefs indicate it exists (using the callback provided by
nsPluginHost).
b) then hopefully dispatch to a background thread, where it will read
pluginreg.dat, scan the appropriate folders on disk, and see if
anything changed. Once done, it sets mFinishedFinding to true and
re-dispatches itself to the main thread.
c) then on the main thread, it reports any changes to nsPluginHost.
3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main
thread.
Note: if ReloadPlugins is called, we intiially do (1), but if we find
changes, we clear out the set of known plugins and then run LoadPlugins
again (meaning we go through 2 (or 3 if 2(b) fails)). This is how
reloading plugins worked prior to my changes and I've attempted not to
change it.
In order for this to work, there are some other changes in this commit:
- the sandbox prefs are being read "early" and cached for flash vs
"everything else". We can't access prefs on non-main threads without
using StaticPrefs, which doesn't seem worth it here.
- some of the plugin tag classes are moved to threadsafe refcounting.
This is a bit unfortunate, but because they're instantiated on a non-
mainthread, and then later used on the main thread, despite the
fact that the architecture means nothing tries to touch them from
more than one thread at once, without threadsafe refcounting we hit
asserts in debug mode if we add references to them back on the main thread.
- we add shutdown blocking for pluginfinding. We don't really want to
be halfway through finding plugins and then trying to shut them down,
or re-instantiating plugins after they've been unloaded.
- we keep a reference to the "pending" pluginfinder instance while
doing lookups away from the main thread (ie (2)), to avoid re-entrancy or
trying to write to pluginreg while we're reading it somewhere else,
etc. If there's an attempt to do more plugin finding while this is
ongoing, we flip mDoReloadOnceFindingFinished and do a reload once
our initial lookups are complete.
Depends on D48331
Differential Revision: https://phabricator.services.mozilla.com/D48332
--HG--
extra : moz-landing-system : lando
This revision refactors RDM's touch simulator to use modern touch web APIs where possible.
Differential Revision: https://phabricator.services.mozilla.com/D50147
--HG--
extra : moz-landing-system : lando
Since closing D50559, we're not using CSS Grid for the browser's container layout (see D48778 for context). This means positioning the device settings modal using CSS grid areas won't work.
An alternative to this is to contain the RDM toolbar inside the browser stack now that it uses CSS Grid. We can then use absolute positioning to have the RDM toolbar always positioning on top of the browser element and adjust its size when the device settings is opened.
Differential Revision: https://phabricator.services.mozilla.com/D51102
--HG--
extra : moz-landing-system : lando
A new parameter is added, and it expect an array
of filter objects (which contain a pattern and
a label properties), which are going to be used
by the save file dialog.
Depends on D51070
Differential Revision: https://phabricator.services.mozilla.com/D51078
--HG--
extra : moz-landing-system : lando
This test is setup to run both with and without the pref
"devtools.responsive.browserUI.enabled" set. Ideally, we can find a
way to refactor this structure into something that can be put into
devtools/client/responsive/test/browser/head.js, and other helper
functions in that file can be modified to work with the pref on or
off.
Differential Revision: https://phabricator.services.mozilla.com/D51022
--HG--
extra : moz-landing-system : lando
Depends on D51054
Summary of the changes here:
- move DOMHelpers.jsm to dom-helpers.js
- remove all unused methods
- converted to a static helper to avoid instanciating DOMHelpers objects for no reason
- updated call sites accordingly
Differential Revision: https://phabricator.services.mozilla.com/D51065
--HG--
rename : devtools/shared/DOMHelpers.jsm => devtools/shared/dom-helpers.js
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
Depends on D51054
This will help catch some issues related to server files importing client files.
Note that we still don't validate:
- devtools/shared: at the moment devtools/shared still contains client only files which
naturally import other client files, so linting here is not an option before we clean
this up
- require calls using variables eg require(MY_MODULE_URI). Maybe we should prevent this via
another linting rule
Differential Revision: https://phabricator.services.mozilla.com/D50466
--HG--
extra : moz-landing-system : lando
1.Show sources and thread name after a thread is set to root
2.Show sources under chrome://
3.Show extension name and icon if an extension directory is set to root
{F1665109}
I'm building a better understanding of sources, sourcesTree and their utils. There could be better solutions than the ones I thought of. I'll appreciate feedback or discussions!
Differential Revision: https://phabricator.services.mozilla.com/D50438
--HG--
extra : moz-landing-system : lando
Ctrl+O (Cmd+O on OSX) will load file content into the console input.
Ctrl+S (Cmd+S on OSX) will show the file dialog for the user
to save the console input content into a file.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D51070
--HG--
extra : moz-landing-system : lando
Depends on D51053
eslint validation was more relaxed in the previous location of this helper, we need to fix some violations.
Differential Revision: https://phabricator.services.mozilla.com/D51054
--HG--
extra : moz-landing-system : lando
Since I started using this helper in devtools/server/ (Node actor), the file needs to move outside of devtools/client
Differential Revision: https://phabricator.services.mozilla.com/D51053
--HG--
rename : devtools/client/shared/DOMHelpers.jsm => devtools/shared/DOMHelpers.jsm
extra : moz-landing-system : lando
A test is added to ensure isClassConstructor has the expected
value for ES6 class grips.
Differential Revision: https://phabricator.services.mozilla.com/D50962
--HG--
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
This will help catch some issues related to server files importing client files.
Note that we still don't validate:
- devtools/shared: at the moment devtools/shared still contains client only files which
naturally import other client files, so linting here is not an option before we clean
this up
- require calls using variables eg require(MY_MODULE_URI). Maybe we should prevent this via
another linting rule
Differential Revision: https://phabricator.services.mozilla.com/D50466
--HG--
extra : moz-landing-system : lando
Now the `togglePrettyPrint` and `selectPrettyLocation` together handle the mapping.
mochitest is added.
Differential Revision: https://phabricator.services.mozilla.com/D50568
--HG--
extra : moz-landing-system : lando
We try to lazy load all the things we know we might
not need directly when opening the console.
Differential Revision: https://phabricator.services.mozilla.com/D50800
--HG--
extra : moz-landing-system : lando
Depends on D50605
All the traits removed here are not checked anywhere in the codebase.
There is more cleanup to do around old traits that are no longer relevant for backward compatibility, but that might still be used for feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D50616
--HG--
extra : moz-landing-system : lando
Depends on D49303
Some methods from css-logic were extracted from the devtools codebase to be used by context-menu files.
This was only needed in order to compute the css-selectors for Inspect Element.
If we use ContentDOMReference instead, those helpers can move back in the devtools codebase
(leaving them in css-selector.js fails the all-files-referenced test for some reason as well)
Differential Revision: https://phabricator.services.mozilla.com/D49330
--HG--
rename : toolkit/modules/tests/chrome/test_findCssSelector.html => devtools/shared/tests/mochitest/test_css-logic-findCssSelector.html
extra : moz-landing-system : lando
Daniel Varga
Nicolas Chevobbe
Gurzau Raul
Neil Deakin
Kirk Steuber
Brian Grinstead
Tim Nguyen
Julian Descottes
Dana Keeler
Razvan Caliman
Narcis Beleuzu
Micah Tigley
Greg Tatum
Harshil Agrawal
Belén Albeza
Brian Hackett
Dorel Luca
Brendan Dahl
Markus Stange
Jason Laster
Daisuke Akatsuka
Mihai Alexandru Michis
Michael Hoffmann
Noemi Erli
Matt Woodrow
Alexandre Poirot
Andreea Pavel
Coroiu Cristina
Anny Gakhokidze
Ricky Stewart
Brad Werth
Junior Hsu
David Walsh
wartmanm
Richard O. Gregory
Itiel
jaril
Gijs Kruitbosch
Ciure Andrei
Florens Verschelde
chujun
Sorin Davidoi
Cosmin Sabou
Alexander J. Vincent
Anshul
Kashav Madan
Gabriel Luong
Oana Pop Rus
zhaogang
Jan Odvarko
Michael Ratcliffe
Emilio Cobos Álvarez