Previously, the only button that could be accessed with the keyboard was the Back button.
MozReview-Commit-ID: 2khSExFNkVP
--HG--
extra : rebase_source : 3f4f02cdccc43abf11b4782458abad5b04b7c899
PanelMultiView has specific code to support keyboard navigation.
However, it only includes elements with class subviewbutton, which has visual styling.
Some views have controls which should be included in keyboard navigation, but for which the subviewbutton styling is not appropriate.
Therefore, also include elements with the new class subviewkeynav, which is specific to keyboard navigation and has no visual styling.
MozReview-Commit-ID: 8A5q9nbGpdc
--HG--
extra : rebase_source : 431fd2b1e2926e53002a45c290f9d88e8463c42c
paper.dropbox.com provides editable and sharable document. Some editing
shortcut keys in it listens to "keypress" events on Firefox. Therefore,
we need to add the URL into the blacklist for Nightly testers.
MozReview-Commit-ID: 3bCrjIzP80v
--HG--
extra : rebase_source : 06420cb6a2a9a511edded9a5133d5d07ab240d61
This reftest fails without the fix in this series.
MozReview-Commit-ID: 3C8TEuCoTS3
--HG--
extra : rebase_source : 13278ee2f8f8facd38d050711330164bf9a174dd
In pseudo element cases mTarget->mElement is the parent element of the pseudo,
thus we inefficiently use the parent frame and walked through parent
continuations.
MozReview-Commit-ID: DsNRXaM346D
--HG--
extra : rebase_source : e62eeff02897ca08e800c1d807f81a0d4cf38dd1
In FindAnimationsForCompositor(), we can ensure
EffectCompositor::GetAnimationElementAndPseudoForFrame doesn't return nullptr
since EffectSet::GetEffectSet(const nsIFrame*) at the top of
FindAnimationsForCompositor() also uses GetAnimationElementAndPseudoForFrame.
MozReview-Commit-ID: CtWdUt40Zyx
--HG--
extra : rebase_source : 7ea1058f4fb740ca35c2ebdc8d2f69d7b634a257
In case of table element, display item has the primary frame for the element,
whereas for animation stuff we basically use the style frame instead.
MozReview-Commit-ID: GT6yaXv3wM4
--HG--
extra : rebase_source : e6c68949d80a3deb51309c1bd1d8a3d2142f0e9f
For table element nsDisplayTransform's mFrame is the primary frame not style
frame.
MozReview-Commit-ID: 9BMSpuGE7lC
--HG--
extra : rebase_source : 19edd8978165cfa3904dcabea3e382e9b7c16ee3
GetAnimationFrame is bit ambiguous, the name should match what we call it.
MozReview-Commit-ID: GuyhVrUFgiW
--HG--
extra : rebase_source : 1120e34aa3fdd20cf26552fda01d1a473e3ffff0
And drop an unnecessary forward declaration for nsIFrame from AnimationCommon.h.
MozReview-Commit-ID: IYroCrg1rtq
--HG--
extra : rebase_source : f41fc19e2cff4ef0dba26192b2f19edfb57189d6
OCSP requests cannot be performed on the main thread. If we were to wait for a
response from the network, we would be blocking the main thread for an
unnaceptably long time. If we were to spin the event loop while waiting (which
is what we do currently), other parts of the code that assume this will never
happen (which is essentially all of them) can break.
As of bug 867473, no certificate verification happens on the main thread, so no
OCSP requests happen on the main thread. Given this, we can go ahead and
prohibit such requests.
Incidentally, this gives us an opportunity to improve the current OCSP
implementation, which has a few drawbacks (the largest of which is that it's
unclear that its ownership model is implemented correctly).
This also removes OCSP GET support. Due to recent OCSP server implementations
(namely, the ability to cache OCSP POST request responses), OCSP GET is not a
compelling technology to pursue. Furthermore, continued support presents a
maintenance burden.
MozReview-Commit-ID: 4ACDY09nCBA
--HG--
extra : rebase_source : 072564adf1836720e147b8250afca7cebe4dbf62
It's the *compile*SdkVersion that needs to match the installed Android SDK plat-
form in order to be able to build an app, whereas the *target*SdkVersion is
merely a compatibility flag.
Since the received wisdom is that targetSdkVersion should be <= compileSdk-
Version and Android Studio is also showing a warning to that effect if you
modify the build.gradle of a small sample app accordingly, I've also added a
corresponding configure check of our own to enforce this.
MozReview-Commit-ID: F2RZemChFrm
--HG--
extra : rebase_source : cf4f6256baa4446d673b94d97f9497f93d7917ff
We no longer need them since in the previous commit we make sure subsequent
ticks happens for animations in delay phase.
MozReview-Commit-ID: F68wCCsCEiE
--HG--
extra : rebase_source : d6ebe9bfa90a767154cea04255dbf4a5403674fe
mAnimStorage->AnimatedValueCount() returns zero in the case where all
animations are in delay phase, even in such case, we should update the previous
timestamp.
MozReview-Commit-ID: 5Dds1YjfVh9
--HG--
extra : rebase_source : 759b7b4d9e5aa23542a31593674683fbef2dbc47
If the animation is in delay phase, we shouldn't produce any values for the
animation but we have to make sure subsequent ticks happen in order to the time
when the animation starts. So what we should do here is that
1) Make AnimationHelper::SampleAnimations() return boolean, return true if
there is any animation.
2) Schedule the next tick if AnimationHelper::SampleAnimations return true
This setup is equivalent to what we do non-WebRender.
So that we don't need to set non-animated value as AnimatedValue for delay
phase to make subsequent ticks happen for the delay phase animations. The
non-animated value will be dropped in the next patch.
MozReview-Commit-ID: IwltLGgvT7K
--HG--
extra : rebase_source : f2c59cb3bdb3affc5846e65ccbaad7dbc069d0ad
Having the native theme widget to flip its own direction turned out to be
something not needed anymore, and it interfere with the CSS rule we set to
flip non-native SVG background.
This patch turned that off and always flips the resizer with CSS transform.
MozReview-Commit-ID: EbjTfFpJpZ0
--HG--
rename : layout/reftests/forms/textarea/resize-ref.html => layout/reftests/forms/textarea/resize-rtl-ref.html
rename : layout/reftests/forms/textarea/resize.html => layout/reftests/forms/textarea/resize-rtl.html
extra : rebase_source : a319698cea6c8460aaed23948e20b0757cec686e
The test case has a fixed item A inside a scrollframe B which is inside
a reference frame C which is inside the root scrollframe D. The
ClipManager code currently uses D's scrollid as the scrolling ancestor
for A, because the gecko display list's ASR is set up that way. However,
we really want to set C as the scrolling ancestor, because otherwise the
item A gets hoisted out of C and the transform from C doesn't get
applied to it. This patch ensures that when we enter C, we install an
override so that anything that would have used D's scrollid ends up
using C's, which results in the correct behaviour.
MozReview-Commit-ID: 31tscfT4xWW
--HG--
extra : rebase_source : 03df2fa5519b2592a2c9f598af0f3f1500773718
Boris Zbarsky
Alexander Surkov
Bogdan Tara
Dorel Luca
Sylvestre Ledru
Kris Maglione
James Teh
Xidorn Quan
Masayuki Nakano
Kartikaya Gupta
Hiroyuki Ikezoe
Andreea Pavel
David Keeler
Ciure Andrei
Chris Pearce
Jan Henning
Razvan Caliman
Timothy Guan-tin Chien
Mark Banner
Michael Kaply
Dennis Schubert