When we fail to generate an image key for an image, it is likely because
the image container is empty. This is not a fatal error, it just means
we haven't produced a frame yet. We should be using NOT_READY instead of
BAD_IMAGE as a result. This is important because reftests rely upon
these error codes to know whether or not they should wait; it could
cause intermittent failures.
If an image container is empty, it will not produce an image key for use
with WebRender. This is generally not a sign of failure because the
producer likely has yet to populate the container with data. As such, we
should not immediately attempt to fallback. In fact, fallback can make
things worse in this situation, as we will create an image client to
send over the data, but then find that there is no data to share (or
find that there is, due to a race with the producer thread, and use
image clients when we could use shared surfaces).
If we can assume that a layer being composited has an APZC at index i if and
only if the frame metrics at index i is scrollable, then we can do the
transformations in the next patch without any change in functionality.
MozReview-Commit-ID: FRkvhwdd3nh
--HG--
extra : rebase_source : f1bee292305730079b3208e447330028c1a40727
This makes more sense in APZCTreeManager, but is exposed back to
AsyncCompositionManager via APZSampler. This also makes the APZ code
better encapsulated since the method API exposed on APZSampler doesn't
need to take a AsyncPanZoomController; it can just take the
LayerMetricsWrapper instead.
MozReview-Commit-ID: 9yJJd3x8VhN
--HG--
extra : rebase_source : b6f81116183810df158d8cce72891bb2db458355
This behavior matches what gets used in mozalloc.h to define these
wrappers, and is particularly necessary for newer versions of clang to
not complain about our definitions.
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
In addition to removing the unnecessary return value and the logic that may anchor the panel to anything other than the main menu button, this also fixes the asynchronous error handling.
MozReview-Commit-ID: KaUKYUhrUoc
--HG--
extra : rebase_source : 50cbc1c847b719a798cd33fc46fd5195dbef4596
This is the Servo side changes of [bug 1444296](https://bugzilla.mozilla.org/show_bug.cgi?id=1444296).
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e6cfbca47a259f20ba1c0d09e599169372d4930
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6ff5ab1fc0e8bf5c182e1bcbd65433b93ed069b1
<!-- Please describe your changes on the following line: -->
Needed to expose `get_framebuffer_attachment_parameter_iv()`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 863f8477ed4766ffcff3b8fcf16c0d90bd179eb4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ca198e4124e606fb6196c0c2377fd3dd3e485457
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
The original code (from bug 1200802) declared an XPCOM object as a static bare
pointer, which for future reference is probably never the right thing to do. It
might have worked if it was cleared before shutdown but it never was.
MozReview-Commit-ID: EMe7wgzm6zv
--HG--
extra : rebase_source : 572ce6822e297692bab3311a65e1143785b913c4
Yura Zenevich
Andrew Osmond
Jon K
Sebastian Hengst
Narcis Beleuzu
Kartikaya Gupta
Trisha
Edouard Oger
Jeff Walden
Tim Taubert
Andreea Pavel
Nathan Froyd
Emilio Cobos Álvarez
Paolo Amadini
Andrea Marchesini
Lars T Hansen
Andreas Tolfsen
Kit Cambridge
Xidorn Quan
Adrian Wielgosik
Ryan VanderMeulen
Igor Gutorov
Masayuki Nakano
Michael Ratcliffe
Johann Hofmann
David Keeler