Until we get rid of animation phases in bug 960465, we need to ensure
we're producing style data for the correct animation phase. This makes
this optimization slightly less beneficial until then.
When the misc tier was added, only directories with misc-associated
variables from moz.build were traversed. This patch adds a dummy
variable to moz.build whose presence will add the directory to the misc
tier.
This will enable us to aggressively convert existing libs:: rules
to the misc tier.
--HG--
extra : rebase_source : c5477010c7d87fafa512f4fbbf1d2b995e07ffbd
extra : amend_source : a54eee6254ef2d63ef6b247d45e38eda2ab88fef
extra : histedit_source : c0f3352e84ec18ca7b88571cd5f9c2a33ab8eda9
========
https://hg.mozilla.org/integration/gaia-central/rev/d59d24ac9804
Author: Yi-Fan Liao <yliao@mozilla.com>
Desc: Merge pull request #26050 from begeeben/1095360_wallpaper_will_display_master
Bug 1095369 - [FFOS2.0][Woodduck][Browser]Wallpaper will display when edit bookmark, r=alive
========
https://hg.mozilla.org/integration/gaia-central/rev/86bae88bdad4
Author: Yi-Fan Liao <begeeben@gmail.com>
Desc: Bug 1095369 - [FFOS2.0][Woodduck][Browser]Wallpaper will display when edit bookmark
When changing orientation from portrait to landscape and resizing with keyboard on, the layout manager in the system app will resize the height of the active app first with the keyboard height in portrait (line 55 in layout_manager.js). When the height of the keyboard in portrait mode is bigger than the height in landscape mode, the calculated height of the active app will be smaller than it should've been. The system wallpaper is visible at the mean time. Subsequent resize events later will immediately correct the active app height using the correct landscape keyboard height.
The resizing event sequence is 'resize' --> 'keyboardchange' --> 'keyboardchange'. This patch disables the keyboard height check in the 'resize' event since it'd be incorrect during orientation change, which would display part of the system wallpaper in a flash.
========
https://hg.mozilla.org/integration/gaia-central/rev/ebb431673edc
Author: David Flanagan <dflanagan@mozilla.com>
Desc: Merge pull request #26047 from davidflanagan/bug1079692
Bug 1079692: update video thumbnail title asynchonously so we don't block when user rotates phone r=johnhu
========
https://hg.mozilla.org/integration/gaia-central/rev/56c7781bce82
Author: David Flanagan <dflanagan@mozilla.com>
Desc: Bug 1079692: update video thumbnail title asynchonously so we don't block when the user rotates the phone
fix spelling error in method name
update test busted by spelling correction
We believe the rate is constrained by the audio driver in practice,
but want to verify this assumption. The valid range 8-192 kHz covers
all sample rates in general use for audio data.
Note we must use an error return instead of an assertion since these
bounds are verified by unit tests, which do not catch MOZ_ASSERT().
