Calling setExperimentActive too early during startup can change
the order of some initialization. setExperimentActive probably
shouldn't have this kind of effect, so simply cache early calls
to it until gGlobalEnvironment has been initialized through other
functions.
Additionally, I am speculatively including work to ensure that
setExperimentInactive and getActiveExperiments have the same
behavior, while remaining correct by working from the same cache
that setExperimentActive uses.
MozReview-Commit-ID: IlzT1J0o6gK
--HG--
extra : rebase_source : b39b8d7e7b0970b520ce3f63af9750846d08b0eb
With a WebDriver-conforming Element Click implementation, the element
click intercepted error is returned when an element with pointer-events:
"none" causes the click to hit the underlying element.
This patch does not functionally change anything yet about the
accessibility tests, but splits disabled_accessibility_elementIDs into
two lists, aria_disabled_elements and pointer_events_none_elements, in
anticipation of moving Marionette to use a different click implementation.
In the future, the ARIA tests will fail with "element not accessible"
errors as they do now, but the pointer-events tests will fail with
"element click intercepted" instead.
MozReview-Commit-ID: Ks1hyUVyLK7
--HG--
extra : rebase_source : 20dbcc228955626cd2d1617aa055f29f4e5928a4
The issue here is that we had marked 'chunked' as false, but were still trying to use 8 chunks for reftest. Because of this we were also sending the unchunked buildbot name to BBB for each chunk we actually tried to run, on e10s and other variants.
MozReview-Commit-ID: Dc5npIq5sxr
--HG--
extra : rebase_source : 6a043c5da4675b00fb9061ddba2e383f05f89d33
The issue here is that we had marked 'chunked' as false, but were still trying to use 8 chunks for reftest. Because of this we were also sending the unchunked buildbot name to BBB for each chunk we actually tried to run, on e10s and other variants.
MozReview-Commit-ID: 3Ffv8UMBzk2
--HG--
extra : rebase_source : bb234d41c28875842f60cf192d184ca8fad316d6
Currently, these two functions take nsIFormControl* as argument, but we only
pass HTMLInputElements to it, so we can change it to take HTMLInputElement* to
avoid overhead in casting.
MozReview-Commit-ID: CHG0F3xWCVF
--HG--
extra : amend_source : 6052bfec33bb8aa7d92e31b242757ed265256002
When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
Put mEffectsBounds in nsDisplyaSVGEffect does not really make sense, since only
nsDisplayFilter need it.
MozReview-Commit-ID: KSvDspZJcMP
--HG--
extra : rebase_source : 9d2f994b40e82e7146358932fbebbc60a4ca01c6
extra : source : cfd8d564c0198239eb029e4984d75a692bd9f9ca