These events were a hack implemented in bug 703198.
At that time, JAWS required focus events for selection changes in a collapsed combo box.
However, these events also fire for expanded combo boxes.
This is problematic with e10s because now, for an expanded combo box, the real focus events come from the XUL dropdown implemented in the parent process, which is not associated with the document a11y tree in any way.
JAWS seems to cope just fine with value changes for Firefox combo boxes now and VFO have agreed that this is the correct path forward.
MozReview-Commit-ID: Iefop25bFe0
--HG--
extra : rebase_source : a86e5d73d560853bb50e1d8e3bbd11431aba8eb0
I've also manually verified that no other references to HANDLE_EINTR are
wrapping a close() in any less syntactically obvious way.
MozReview-Commit-ID: 3KkBwFIhEIq
--HG--
extra : rebase_source : 4e79a70b3be22a7721b6f85b19ee5a31c98df456
This is based on the current security/sandbox/chromium version of eintr_wrapper.h,
taken from upstream commit 937db09514e061d7983e90e0c448cfa61680f605.
I've edited it to remove some things that aren't relevant to us: the
debug-mode loop limit in HANDLE_EINTR, because we don't seem to be
having the problem it's meant to fix and it risks regressions, and
references to Fuchsia, which we don't (yet) support. I also kept the
original include guards (the file path has changed upstream).
What this patch *does* do is add IGNORE_EINTR and modernize the C++
slightly (using decltype instead of nonstandard typeof).
MozReview-Commit-ID: BO4uQL9jUtf
--HG--
extra : rebase_source : ab3343c6d93e0ce753859217a55af131a0c4ea68
Although they still happen in the same transaction, they are done in two
separate frame messages. This results in better encapsulated code on the
C++ side since we don't have to pass around an array of properties, and
will simplify future changes to update these properties at render time
rather than at GenerateFrame time.
MozReview-Commit-ID: 9qUkHX7gmD1
--HG--
extra : rebase_source : 15a319ba270eb1783815c514ae05c6a72e323dac
In the e10s implementation, Accessible::NativeState for the options doesn't include the invisible state. (It does with e10s disabled.)
In HTMLSelectOptionAccessible::NativeState, rather than just flipping (xor) the invisible state, absolutely ensure it gets removed. We don't want to *add* the invisible state if it isn't there.
This allows group position info to be calculated correctly.
MozReview-Commit-ID: LPEVhOOm2NT
--HG--
extra : rebase_source : 3091ca1826b216bb7c91eb62aafc16f79b786272
Also cleaned up a few other loose ends on webextensions api docs.
MozReview-Commit-ID: FnyqmM7NjqE
--HG--
extra : rebase_source : 6039a70c72790c14d8872e38e77e9596b7dac3f8
These lines of code are within the #else section of the #ifndef MOZ_GECKO_PROFILER
at the top of the file, so MOZ_GECKO_PROFILER is always defined for them.
MozReview-Commit-ID: IxRYexzZH0G
--HG--
extra : rebase_source : 302e5515323a63f145eed75a2b66a04fbde052e5
Also adds too the cookie tests to ensure this takes effect.
MozReview-Commit-ID: A85kv20BcnI
--HG--
extra : rebase_source : bd724ac1fb358d6ed1d4bfbe0d903f33619da647
This patch changes alignment property of additional backgrounds to be relative to #navigator-toolbox, instead of root.
MozReview-Commit-ID: LlSZmu39u6D
--HG--
extra : rebase_source : 1c5eda6d21f80b377c360dd26830c48c7fdc4548
This is mainly to pick up bug 1448221 since the version of mozprofile on pypi can't
install addons with nightly anymore (due to the profile/extensions/staged directory
not being supported).
But since that change I've also landed several backwards incompatible API changes to
how addons are installed.
Bumping to 1.0.0 because I'd like us to start (attempting) to follow SemVer:
https://semver.org/
MozReview-Commit-ID: FDIPqNnSKJ6
--HG--
extra : rebase_source : 4e083b77802c97b85436410b40225ad234b9e7fb
We don't need or want cookies sent to incoming.tmo. It just throws them on the
floor, but we needn't waste clients' bandwidth on it.
MozReview-Commit-ID: F9WjcDyKFGN
Returning UniquePtr is nicer than returning raw pointers, and has the
nice side effect of forcing us to clean up the uses of nsAutoPtr that
were hanging about.