On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
The previous commit disabled the remote agent by flipping the
remote.enabled preference to false. That prevented the remote
agent from initialising or being included in the --help message.
This patch implies --enable-cdp in the default Firefox build on Firefox
Nightly. Firefox for Android is not supported. This will cause
builds to include the remote agent component that lives under remote/.
Since the remote agent is disabled by default, users will first
have to set the remote.enabled preference to true in order to use it.
If you wish to explicitly opt out of including the remote agent
when building Firefox, you may do so by using the --disable-cdp
build flag in your mozconfig:
ac_add_options --disable-cdp
Differential Revision: https://phabricator.services.mozilla.com/D27540
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
This change allows GeckoView embedders to respond to
`runtime.sendNativeMessage` and `runtime.connectNative` sent from
WebExtensions.
These APIs are available behind the new privileged-only permission
`geckoViewAddons` and are used by GeckoView apps to communicate between content
and the app.
Depends On D22621
Differential Revision: https://phabricator.services.mozilla.com/D22622
--HG--
extra : moz-landing-system : lando
This provides a flipped data structure based on the provided inheritedAttributes,
which looks like:
Object<selector, attrs_to_inherit_comma_separated>
To one that looks like:
Object<attr, Array<Array<selector, attr_to_inherit>>
This should improve performance because:
1) We only fetch element at connectedCallback that actually will have attributes inherited.
2) When an attribute changes we can quickly inherit only that one.
Differential Revision: https://phabricator.services.mozilla.com/D27801
--HG--
extra : moz-landing-system : lando
Adding telemetry for the amount of traffic transfer over the captive portal. Also moving some telemetry for trackers to the same place where our old telemetry is, so that they are all on the same place.
Differential Revision: https://phabricator.services.mozilla.com/D27375
--HG--
extra : moz-landing-system : lando
Remove eval() from updates.js
Refactor code to make mapping of pageids to js-objects obsolete
Remove now unnecessary object attributes from wizard pages in updates.xul
Differential Revision: https://phabricator.services.mozilla.com/D25921
--HG--
extra : moz-landing-system : lando
Configure the lmdb-rkv-sys Rust crate to use a smaller MDB_IDL_LOGN size in order to reduce allocations when opening an LMDB environment in read-write mode.
@glandium I adopted the configuration strategy you suggested of creating a "feature" for each reasonable value for the MDB_IDL_LOGN macro. Fortunately, the range of reasonable values is fairly small.
@nanj Based on your evalution in https://github.com/mozilla/lmdb/pull/2, a value of "9" for this macro should aggressively reduce the allocations while still supporting our existing use cases. But I'm open to increasing it, if you think a higher initial value would be preferable.
Differential Revision: https://phabricator.services.mozilla.com/D27559
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
These Histograms were added:
UPDATE_CAN_USE_BITS_EXTERNAL
UPDATE_CAN_USE_BITS_NOTIFY
Used for telemetry indicating whether or not BITS can be used by this system. If BITS cannot be used, the probe will contain data indicating why not.
UPDATE_BITS_RESULT_COMPLETE
UPDATE_BITS_RESULT_PARTIAL
Used for telemetry indicating whether the BITS update download succeeded. If it failed, the probe will contain data indicating how it failed.
This scalar was added:
update.bitshresult
Used to indicate the hresult returned, if any, when a BITS download fails.
Differential Revision: https://phabricator.services.mozilla.com/D25163
--HG--
extra : moz-landing-system : lando
nsUpdateService should use BITS for download. If the BITS download fails, it will fallback to the existing download mechanism (nsIIncrementalDownload).
Differential Revision: https://phabricator.services.mozilla.com/D25162
--HG--
extra : moz-landing-system : lando
This patch introduces an asynchronous XPCOM interface for the bits client added in Bug 1523417
Differential Revision: https://phabricator.services.mozilla.com/D25161
--HG--
extra : moz-landing-system : lando
* Use Services.(ppmm|cpmm).sharedData to make isMasterPasswordSet value available to the content process
* We don't handle runtime enable/disable of MP
Differential Revision: https://phabricator.services.mozilla.com/D26939
--HG--
extra : moz-landing-system : lando
This should not have any major behaviour changes, with the following exceptions:
1. The method for receiving messages from IPC is called `receiveMessage` rather
than `recvAsyncMessage`. This is more consistent with existing code, so
should be OK.
2. Exceptions will be correctly reported when thrown within a callback.
Differential Revision: https://phabricator.services.mozilla.com/D26547
--HG--
extra : moz-landing-system : lando
We need to handle autofilling the first result separately from autofilling results in general (which happens in UrlbarInput.setValueFromResult), so add a new UrlbarInput.autofillFirstResult method. The controller calls it instead of setValueFromResult. I ported the logic from nsAutoCompleteController, as described in the bug.
Other changes are related to the new test for this.
As part of this work, I was interested in learning how awesomebar handles browser_autoFill_typed.js, so I added it to the legacy tests, with a small tweak in the test for awesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D26852
--HG--
extra : moz-landing-system : lando
This also stops the PictureInPictureToggleChild from tracking videos with controls for now.
Depends on D26777
Differential Revision: https://phabricator.services.mozilla.com/D26778
--HG--
extra : moz-landing-system : lando
Remove the tree._columnsDirty property which is causing problems for column reordering in a fresh profile.
Differential Revision: https://phabricator.services.mozilla.com/D25507
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
This also stops the PictureInPictureToggleChild from tracking videos with controls for now.
Differential Revision: https://phabricator.services.mozilla.com/D26778
--HG--
extra : moz-landing-system : lando
This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
Password manager should not offer to save credit card numbers in certain straight-forward cases.
Differential Revision: https://phabricator.services.mozilla.com/D25485
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
This includes improvements to the Linux exception handler that will provide
crash addresse for a number of signals by reading the NT_SIGINFO structure and
quites warnings in a number of files. This also removes an unused header.
Differential Revision: https://phabricator.services.mozilla.com/D26488
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
nsBrowserStatusFilter is updated to not filter out STATE_IS_REDIRECTED_DOCUMENT.
The test here is adding a way to have a "login form" do a post to a server script, which then does a 303 redirect. This mimics what some services, including LinkedIn do during this stage.
Differential Revision: https://phabricator.services.mozilla.com/D26969
--HG--
extra : moz-landing-system : lando
After calling Lookup API per table, Safe Browsing outputs too many debug
message for a single URL lookup. Refine the current output.
Differential Revision: https://phabricator.services.mozilla.com/D27066
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
randomly choose 1% users and their 0.14% page view to measure content blocking.
Differential Revision: https://phabricator.services.mozilla.com/D26130
--HG--
extra : moz-landing-system : lando
We don't need an additional array just for byte reordering, replace
it with in-place processing.
Testcase are modified because the LookupCacheV4::Build API now clears the
input parameter.
Differential Revision: https://phabricator.services.mozilla.com/D26861
--HG--
extra : moz-landing-system : lando
Here is the flow how prefixes are handled during an V4 update:
1. Prefixes are received from Safe Browsing update, stored in ProtocolBuffer
2. Copy the prefixes from ProtocolBuffer to TableUpdate structure
3. Prefixes in TableUpdate are merged with local prefixes (stored in LookupCacheV4)
4. Merged prefixes are processes by PrefixSet to generate the in-memory prefix
set data structure (MakePrefixSet).
In this patch, we free the prefixes stored in TableUpdate right after step3.
This reduces the peak memory used during an update (peak happens in step 4).
Differential Revision: https://phabricator.services.mozilla.com/D26860
--HG--
extra : moz-landing-system : lando
In particular, this enables Marionette in local Fennec builds, which
were the only place it wasn't enabled by default. (Automation builds
all enabled Marionette.) That default is getting in the way of the
Performance Team (and others!) testing GeckoView-based products
easily.
Differential Revision: https://phabricator.services.mozilla.com/D26815
--HG--
extra : moz-landing-system : lando
We also take account those values in the case of `Find in page`.
The corresponding web platform tests will be coming from this PR.
https://github.com/web-platform-tests/wpt/pull/8575
Though some of them will not be passed, the failure reason is not related
to this change, I will take a look when the PR gets merged into mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D25915
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
* Use Services.(ppmm|cpmm).sharedData to make isMasterPasswordSet value available to the content process
* We don't handle runtime enable/disable of MP
Differential Revision: https://phabricator.services.mozilla.com/D26939
--HG--
extra : moz-landing-system : lando
If MOZ_INSTRUMENT_CUSTOM_ELEMENTS is set in the environment, then modify Custom Elements
to wrap each function and property lookup to keep a count and running time. Then print out
tables for each element at startup. Tables can be re-printed with `MozElements.printInstrumentation()`.
Differential Revision: https://phabricator.services.mozilla.com/D24953
--HG--
extra : moz-landing-system : lando
Removed FX_PREFERENCES_OPENED_VIA probe as it expired in 63.Origin parameter for openPreferences has also been removed.
Differential Revision: https://phabricator.services.mozilla.com/D26795
--HG--
extra : moz-landing-system : lando
Bug 1478124 and bug 1524687 converted many things to static xpcom
component registration, but somehow left the corresponding C++
initialization.
Differential Revision: https://phabricator.services.mozilla.com/D26697
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
The RemoteAgent.js script has (temporarily) changed name to
remote/command-line-handler.js, and the chrome component remote.jar
was not included during packaging. This patch fixes both these things.
Differential Revision: https://phabricator.services.mozilla.com/D26591
--HG--
extra : moz-landing-system : lando
After replacing precise line information from .debug_line with coarse
line information from DW_AT_call_{file,line}, it's very likely that
adjacent line records actually refer to identical file and line
numbers. Such adjacent records are not really useful and take up more
space than they should in the symbol file. We might as well merge them
and save ourselves some space.
Differential Revision: https://phabricator.services.mozilla.com/D25473
--HG--
extra : moz-landing-system : lando
DW_TAG_subprogram DIEs sometimes have child DW_TAG_lexical_block DIEs
which in turn contain child DW_TAG_inlined_subroutine DIEs that we woud
like to look at. If we skip the DW_TAG_inlined_subroutine DIEs, we miss
important information. We therefore need to look through the
DW_TAG_lexical_block DIEs to find the DIEs that we are interested in.
Depends on D25471
Differential Revision: https://phabricator.services.mozilla.com/D25472
--HG--
extra : moz-landing-system : lando
We record the file and line that these subroutines were inlined from.
We'll use that information to provide more coarse-grained line
information in the next patch.
Depends on D25469
Differential Revision: https://phabricator.services.mozilla.com/D25470
--HG--
extra : moz-landing-system : lando
The DW_AT_call_file attributes that we eventually want to parse from
DW_TAG_inlined_subroutine DIEs refer to the file name table stored in
the .debug_line section. To resolve those DW_AT_call_file attributes,
we need access to that table after parsing of the appropriate
.debug_line bits is done. This patch adds support for extracting that
information from the .debug_line parsing process.
Differential Revision: https://phabricator.services.mozilla.com/D25469
--HG--
extra : moz-landing-system : lando
Fixes the tokenizer to recognize file:/// urls, plus adds a second layer of
protection, so that if URI fixup thinks the typed string may be an url, we don't
fetch suggestions for it.
Differential Revision: https://phabricator.services.mozilla.com/D26282
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
Avoid using Rkv::Manager, which calls std::fs::canonicalize, triggering bug 1531887 in Firefox on Android.
Differential Revision: https://phabricator.services.mozilla.com/D26605
--HG--
extra : moz-landing-system : lando