LSBUtils closes a file descriptor twice, once with fclose and then again with
close. It also does this on a background thread, during startup, which means
it tends to race with main thread code which opens files.
This patch fixes that, and also removes a work-around for the issue in the
MemMapSnapshot code.
MozReview-Commit-ID: JdDHt9ayFEl
--HG--
extra : rebase_source : 2000ede41108d6312734d8df7db98272b33528fa
extra : amend_source : 1443a596fab3e3126a22d44787adaf5e12e4587c
Similar to lines (see previous patch), floats from next-in-flow or overflow
frames have probably not been marked dirty (as ReflowInput hasn't dealt with
them when it was constructed), so we need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first
floats from the previous column they will not be reflowed as needed.
MozReview-Commit-ID: KKrwtzeQMrI
--HG--
extra : rebase_source : 2b1abb27e9a6ef248a90254b8b56c05207ae25e6
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
--HG--
extra : rebase_source : 0198b291a1b50441188e050dd5bcb2c06694df81
The front end code can't always guarantee to give us an allow/cancel response
to a permission request. In particular in these cases:
* if we close a tab while showing a doorhanger, or
* if we navigate a tab while showing a doorhanger, or
* if the permission prompt requested in a background tab and never shown.
Handling all of these cases is problematic; we don't get events for all of
these where it's easy and cheap to determine that we should cancel the
permission request.
Canceling the permission request is important in the autoplay-media permission
request case as there's objects waiting on the resolution of the permission
request, and they leak in ASan builds while running chrome tests if the Gecko
size of the permission request doesn't get a notification telling it to stop
waiting.
But we can however rely on the doorhanger code to drop its reference to the
nsIContentPermissionRequest object that we pass to it when the doorhanger goes
away. So we can cancel the permission request in our
nsIContentPermissionRequest's implementation's destructor in order to easily
catch all the above cases.
In order to do that, we need to split AutoplayRequest into two; one part being
the implementation of nsIContentPermissionRequest (AutoplayPermissionRequest),
and the other part being the code to own the PromiseHolder and manage the
permission request (AutoplayPermissionManager).
AutoplayPermissionRequest keeps a weak reference to AutoplayPermissionManager,
so that it can tell the AutoplayPermissionManager to reject the request promise
when it's destroyed.
This fixes the ASan leak for which I got backed out from earlier in this bug,
and also fixes the cases above.
MozReview-Commit-ID: KoVkgIqDleW
--HG--
rename : dom/html/AutoplayRequest.cpp => dom/html/AutoplayPermissionManager.cpp
rename : dom/html/AutoplayRequest.h => dom/html/AutoplayPermissionManager.h
extra : rebase_source : dbca520a93d8c416f6d64c2da027630181bb5910
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : rebase_source : d4ba3b6a0ae3d46cf797fd6aaf4502d7a74f49c9
extra : absorb_source : e8b2648578a880d43a5a3a075e60ce1433c737ce
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : rebase_source : 93cad19e27d3aaf5d4cad358cdebd6d80b76f668
extra : absorb_source : 06cb8911c92b66f8863b5e184d88b923cdbd6adc
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : rebase_source : 054f4dcd534b41da889304c3c6d3365d56e8edda
extra : absorb_source : de81199e174f2d3604c803a5c016ba2f3baf3558
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : rebase_source : 4a7e9611efe5b554309df18f7b18ba9c807b72b2
extra : absorb_source : 185442bd69d616c2d2512df954dde7d1b54f2c30
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : rebase_source : 833abea0620f75410f9922e5d4b5cf36b84e9e50
extra : absorb_source : 89690c674120eb99ad25804408b1c3864c7b1fc8
So panels provided by extensions with IDs that contain words like "inspector"
don't break.
Include test in existing panel creation test.
MozReview-Commit-ID: JerMCaKRgkl
--HG--
extra : rebase_source : 56c0262597c4070c7e16b32ebf824ef1fdd1fd8d
Add an anonymous XUL tooltip node to toplevel non-XUL windows. Setup a
nsXULTooltipListener on non-XUL nsXULWindows. Make nsXULTooltipListener
always use the default tooltip in the non-XUL case.
MozReview-Commit-ID: Koe5m8PwMQM
--HG--
extra : rebase_source : 242180e957758b51c589452e35deadac5ab06d9e
The doc string for the "working_directory_clean" function states:
> By default, untracked and ignored files are not considered.
But the git implementation for this function used to run:
git status --porcelain
Which *does* consider untracked files by default. Instead, we need to run:
git status --porcelain --untracked-files=no
Differential Revision: https://phabricator.services.mozilla.com/D2134
--HG--
extra : moz-landing-system : lando
By separating the platform-specific code that finds enterprise roots to load
into its own file, we can make it easier to both add support for other
platforms and maintain the implementations going forward.
Differential Revision: https://phabricator.services.mozilla.com/D2103
--HG--
extra : moz-landing-system : lando
Some callers of PLDHashTable::Search() use const_cast, some others are not
const methods due to non-const PLDHashTable::Search().
This patch removes const_cast from the former and mark some methods of the
latter const.
MozReview-Commit-ID: C8ayoi7mXc1
--HG--
extra : rebase_source : 2cba0339756e3278ba6e5f0e8a11e68217a61d34
PLDHashTable::Search() does not modify any members. So, this method and
methods called by it should be marked as const.
MozReview-Commit-ID: 6g4jrYK1j9E
--HG--
extra : rebase_source : eda6c50c538fec0e8c09cb2ba629735eea6ec711
Added a data member to nsIPresShell to store the visual viewport offset. APZ
will update the visual viewport offset in the presShell for root scroll frames
on every repaint request.
MozReview-Commit-ID: Ksou43hrE6H
--HG--
extra : rebase_source : 812c88efc7556c4bff2a62834cfaaec6e6945093
This prevents accidental changes to package-lock.json when ESLint's setup runs 'npm install'.
Also revert the recent accidental changes to package-lock.json.
MozReview-Commit-ID: 21ebhOlQcMv
Differential Revision: https://phabricator.services.mozilla.com/D2118
--HG--
extra : moz-landing-system : lando
This patch:
* Exposes a global Sync change counter on `nsINavBookmarksService`.
This is similar to SQLite's `total_changes()`, but just for changes
to bookmarks that affect Sync, and accounts for changes from multiple
threads and connections.
* Adds a SQL function to bump the counter, and extends the
`moz_bookmarks` triggers to call it.
* Moves merging outside the transaction in the bookmarks mirror, and
checks that the counters match before applying.
Differential Revision: https://phabricator.services.mozilla.com/D2004
--HG--
extra : moz-landing-system : lando
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : rebase_source : bf986b6008123661547949f615c8416403321835
extra : absorb_source : e86aae959325a9c3198e0259468a47a656739278
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : rebase_source : 28e8c6075bacf5f610058227a9731aeadb50f320
extra : absorb_source : f63602a163ed19fb65e26640319750fdd9b92ad1
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : rebase_source : f5de7462438e33cf4983be3fcef3c781c25ec492
extra : absorb_source : 9f9861546fc0b11333e575bb3c164dfe07575d99
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : rebase_source : e7cb96dd52380f2ed2fbd79b4e157e4efab65cb0
extra : absorb_source : ed95ed85388875353458eb65e41727e606ebf097
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : rebase_source : 6a32f03c37622093c67e7ee7a0e935d1e63c4fc8
Kris Maglione
Gerald Squelart
Chris Pearce
Luca Greco
Ian Moody
Alexis Beingessner
Brendan Dahl
Andrew Halberstadt
Nazım Can Altınova
Erica Wright
Mike Conley
David Keeler
Byron Campen [:bwc]
Ting-Yu Lin
ahillier
Masayuki Nakano
Tanushree Podder
Gurzau Raul
Mike de Boer
Mark Banner
Lina Cambridge
Gabriel Luong
Andrea Marchesini
Ryan Hunt
Kartikaya Gupta
Emilio Cobos Álvarez
Ryan VanderMeulen