This check was introduced in bug 1811195, but was added outside of the
normal opening flow, meaning that failures after this check would not be
handled properly, leading to potential assertion failures or unhandled
content process creation failures.
This patch adds a clarifying comment to ensure that we don't add checks
to the wrong place in the future, and moves the check into
`ContentParent::CreateBrowser` such that it is handled in a similar way
to other content process creation failures.
In addition, extra logic was added to ensure `mInitialized` gets set on
TryRemoteBrowserInternal failure, as new checks have been added before
the `mInitialized` check, and this seems likely to happen more in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D197541
helper_zoomToFocusedInput_nested_position_fixed.html is a test case for bug
1627734 that zoomToFocusedInput doesn't reset the root scroll position to the top.
helper_zoomToFocusedInput_zoom_in_position_fixed.html is a test case that
zoomToFocusedInput zooms into an element in position:fixed subtree.
Differential Revision: https://phabricator.services.mozilla.com/D197281
This patch makes it so that we avoid blocking all features with the
blocklist, and instead continue to allow the safe subset proscribed by
GfxInfoBase::OnlyAllowFeatureOnKnownConfig. Any feature allowed in an
unknown configuration should be allowed in a blanket blocklist entry,
unless we know for a fact that we need to also block them.
Differential Revision: https://phabricator.services.mozilla.com/D197963
When the autofilled address is edited, the Address capture doorhanger appears with the fields that were changed being highlighted. This is not communicated to an assistive technology because it is marked up as `<span>` that has no programmatic meaning/role.
Differential Revision: https://phabricator.services.mozilla.com/D196967
This patch doesn't change behavior. It's just replacing a magic number `5` with
a constant whose value is automatically inferred based on the enum that it's
defined within. (The enum's other values are explicitly 0-based so that they
can serve as array indices, so it's natural to define a final sentinel
enum-value to represent the count of valid indices.)
Differential Revision: https://phabricator.services.mozilla.com/D197755
This patch doesn't change behavior.
The APIs that I'm changing here are all indexing into an array that only has 5
entries; it's a bit odd to be using a signed array-index for this, particularly
since the indices all originate from GetUnderlineStyleIndexForSelectionType()
which explicitly returns values 0 through 4 (as enum values).
I suspect we were using signed index because we were using an enum to represent
the values, which was signed-by-default. Let's just explicitly declare the
enum to use an unsigned underlying representation, and then change its
downstream integer variables/params to be unsigned as well.
Conveniently, this lets us simplify the assertions about the index being
in-range, since unsigned values are >=0 by definition.
Differential Revision: https://phabricator.services.mozilla.com/D197754
This patch doesn't change behavior.
We have a gecko convention that pointer-returning getters will only have "Get"
in the name if they might return nullptr (and the caller needs to check for
this).
This particular API doesn't ever return null, so it shouldn't have "Get" in its
name.
Differential Revision: https://phabricator.services.mozilla.com/D197753
This patch doesn't change behavior. It just replaces an "is-this-initialized"
bool with our more declarative Maybe<> struct which is uninitialized-by-default
(and brings along debug-build checks to ensure we don't use before
initializing).
Differential Revision: https://phabricator.services.mozilla.com/D197752
No other platform does this. This comes from bug 413277, but positioning
windows (in particular popups) partially offscreen is desirable in some
cases (e.g., when drawing non-native shadows).
We have protections in place to prevent content from doing things like
what caused this code to be added.
Remove a cocoa-specific test for this, and tweak another test which has
a dependent window opened from an offscreen window, and the offscreen
window positioning happens right after the load event.
The window ends up on screen even without that tweak.
Differential Revision: https://phabricator.services.mozilla.com/D197903
Previously it may have been possible in some edge cases for us to send
`MaybeFireEmbedderLoadEvents` for a non-toplevel frame during docshell
tree teardown.
Differential Revision: https://phabricator.services.mozilla.com/D197825
When a user's environment matches one or more variants, the variant's properties
override an existing property on the base engine or is added cumulatively when
the property does not exist on the base. The test ensures this process is using
deep copies and not modifying the original search config. There should be no
references to nested objects or arrays of the original config.
Differential Revision: https://phabricator.services.mozilla.com/D197602
No other platform does this. This comes from bug 413277, but positioning
windows (in particular popups) partially offscreen is desirable in some
cases (e.g., when drawing non-native shadows).
We have protections in place to prevent content from doing things like
what caused this code to be added.
Differential Revision: https://phabricator.services.mozilla.com/D197903
Mark Banner
Updatebot
Mozilla Releng Treescript
alwu
Jeff Muizelaar
Tooru Fujisawa
Gregory Pappas
Mike Hommey
Nika Layzell
Emilio Cobos Álvarez
Natalia Csoregi
Iulian Moraru
Stephen A Pohl
Karl Tomlinson
Hiroyuki Ikezoe
Matthew Gaudet
Ryan Hunt
Asumu Takikawa
andrej
Andrew Osmond
Anna Yeddi
Daniel Holbert
Eitan Isaacson
Gabriel Bustamante
ffxbld
Dianna Smith
mcheang