To avoid the unnecessary conversion between `EditorDOMPoint` and
`EditorRawDOMPoint`, it should be a template method which can take/return either
`EditorDOMPoint` or `EditorRawDOMPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D143880
The implicit copy constructors and `operator=` makes it harder to realize
that implicit conversion wastes the runtime cost. Therefore, this patch
replaces them with a template method to convert the `EditorDOMPointBase` type.
Differential Revision: https://phabricator.services.mozilla.com/D143878
Some OS's are configured such that the top-left edge isn't at 0,0 (which browser_resizeVideo.js
assumed). This makes this test more resilient to such configurations by sampling the top-left
edge coordinates before the test runs.
Differential Revision: https://phabricator.services.mozilla.com/D144206
There is a known issue: if we change overflow property of the
scroll-container, we may have to update the scroll-linked animations of
its descendants. This may be very tricky, so I filled Bug 1765211 for it.
Differential Revision: https://phabricator.services.mozilla.com/D143420
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
* Add a new block ping. I called it "block" to be consistent with internal
naming in urlbar/quick suggest, but let me know if you'd prefer "dismiss"
* Add a `iab_category` property to suggestion objects returned from
UrlbarQuickSuggest (i.e., remote settings. Merino will separately need to
include this in its suggestions too)
* Add a new `sponsoredIabCategory` payload property to quick suggest results so
we can record `iab_category` in the ping
* Modify existing tests to include `iab_category` in mock sponsored suggestions
and `sponsoredIabCategory` in the expected payloads
* Replace the several QuickSuggestTestUtils functions for checking pings with a
single function that makes sure only the specified pings are recorded and
nothing more
Depends on D143331
Differential Revision: https://phabricator.services.mozilla.com/D143674
Scanning for client certificates involves looking through each slot in each
PKCS#11 module. There may be many certificates that don't have corresponding
private keys in the NSS softoken, so it's more efficient to search for private
keys and then find any matching certificates. This reasoning also applies to
the NSS builtin roots module, which is the change this patch makes.
Differential Revision: https://phabricator.services.mozilla.com/D143859
InvalidateNonClientRegion mixed up these constants. They seem to always map to the same value on Windows so this doesn't change any behavior.
Depends on D143389
Differential Revision: https://phabricator.services.mozilla.com/D143390
Bug 618353 introduced padding in the non-client area at the top of the Windows widget that compensates for a bug in Windows that causes DwmDefWindowProc to ignore mouse events (and, by extension, window buttons) on maximized windows. The padding is then un-added when we define the client region for WM_NCCALCSIZE, making it functionally a no-op.
That predates Windows 10. On Windows 10+, this "fix" exposes a new Windows bug where we sometimes get undrawn regions on adjacent monitors. Windows is supposed to clip the regions of the maximized window that extend to other monitors but the undrawn regions are the result when it doesn't.
We don't need the fix from bug 618353 on Windows 10+ -- we use non-native window buttons and therefore don't run into the Windows bug. This patch limits the padding to Windows 7/8.1.
Differential Revision: https://phabricator.services.mozilla.com/D143389
Masayuki Nakano
Gerald Squelart
Cristian Tuns
Daniel Holbert
Morgan Reschenberg
Noemi Erli
Matthew Gregan
Mike Conley
Niklas Baumgardner
Andrew McCreight
Boris Chiou
Tom Ritter
Tim Giles
Mozilla Releng Treescript
Steve Fink
az
Drew Willcoxon
Greg Tatum
Dana Keeler
David Parks
Dan Mosedale
Max