Bug 1452970 - Add auto-hide option to Download toolbar icon context menu r=Gijs MozReview-Commit-ID: VVPQesdzJ6

Bug 1459207 - Properly style separator in Throttle drop down; r=davidwalsh MozReview-Commit-ID: 5qXoUtfqDYu

Bug 1459979 - Sort artifact candidate hg revisions by local integer revision. r=froydnj This works around a situation observed with old hg versions (hg 4.2?) with mozilla-unified. I don't know why we haven't witnessed it more generally, since the sort order was textual and should have caused issues. MozReview-Commit-ID: DBtfRJ3NJGR

bug 1457034 - populate release_partner_build_number. r=nthomas MozReview-Commit-ID: EC4jHIwBWWb

bug 1457034 - generate `release_partner_config` in `release_promotion` r=nthomas If we're not passed `release_partner_config` in the input, let's poll github for it in the action. MozReview-Commit-ID: 2swx76vhTE5

bug 1457034 - re-add partner github code. r=nthomas We originally had this logic here, and called it from the `partner_repack` transform. This kept the config more hidden, but had the downsides of a) being difficult to test, and b) hitting the network during transforms, which we're trying to avoid. We moved this code to release-runner3, and passed in the `release_partner_config` as input, and saved it as a parameter. Parameterizing the partner config means that we can refer to it easily throughout taskgraph generation and in local testing, and we don't have to hit the network during transforms. The downsides include potentially having to generate this config in multiple places (rr3, ship-it-v2, the partner hook), and risking hitting the 20k gpg cleartext character limit in the `ACTION_INPUT` environment variable. Now I'm moving this code back into util.partners, but I'm calling it from the action, not from the transform. The action populates the `release_partner_config` parameter, so we can still access the config from anywhere in the taskgraph generation code, more easily test, and avoid hitting the network during transforms. It also means that release-runner3, ship-it-v2, and the partner hook can all use the partner config generation code from a single location, rather than having to duplicate it. Hoping this is the last major change we need to make here for a while. MozReview-Commit-ID: 8UmvmcAoZgD

Bug 1089691 - Convert consumers of removePagesByTimeframe and removePagesFromHost to PlacesUtils.history.removeByFilter. r=mak MozReview-Commit-ID: HevUcwPhYhd

Bug 1459118 - [wdspec] Disable test_handle_prompt_twice for execute (async) script. r=jgraham MozReview-Commit-ID: 4dcNUcJCur

Merge inbound to mozilla-central. a=merge

Bug 1446834 - Make EventStateManager to use GetFlattenedTreeParent when updating hover/active content, r=emilio

Bug 1459728 - Include more Android test suites in try list of non-compiled suites; r=maja_zf

Bug 1453454 - Improve SourceBuffer support for large encoded image data. r=jrmuizel Regardless of the size of an encoded image, SourceBuffer::Compact would try to consolidate all of the chunks into a single chunk. If an image is quite large, it can be actively harmful to do this, because we want a very large contiguous chunk of memory for no real reason, and spend extra time on the main thread doing the memcpy/consolidation. Instead we now cap out the chunk size at 20MB. If we start allocating chunks of this size, we will not perform compacting when we have received all of the data. (Save for realloc'ing the last chunk since it probably isn't full.) On a related note, if we hit an out-of-memory condition in the middle of appending data to the SourceBuffer, we would swallow the error. This is because nsIInputStream::ReadSegments will succeed if any data was written. This leaves the SourceBuffer out of sync. We now propogate this error up properly to the higher levels. fixup

Bug 1392106 - skip css writing modes on win7/debug and fix import-tests.py to support reftest_writing_modes.list. r=gbrown,xidorn

Bug 1458004 - Link font-style values italic / oblique to the appropriate variation-font axes or synthetic styling. r=jwatt

Bug 1460258 - Re-enable discarding of animated image frames. r=aosmond

Bug 1458655: Do not copy DisplayItemClip onto AssignedDisplayItemData. r=mattwoodrow

Bug 1454149 - Do not advance animated images which are not displayed. r=tnikkel All animated images on a page are currently registered with the refresh driver and advance with the tick refresh. These animations may not even be in view, and if they are large and thus cause redecoding, cause a marked increase in CPU usage for no benefit to the user. This patch adds an additional flag, mCompositedFrameRequested, to the AnimationState used by FrameAnimator. It is set to true each time the current animated image frame is requested via FrameAnimator::GetCompositedFrame. It is set to false each time the frame is advanced in FrameAnimator::AdvanceFrame (via FrameAnimator::RequestRefresh). If it is true when FrameAnimator::RequestRefresh is called, then it will advance the animation according to the normal rules. If it is false, then it will set the current animation time to the current time instead of advancing. This should not cause the animation to fall behind anymore or skip frames more than it does today. This is because if FrameAnimator::GetCompositedFrame is not called, then the internal state of the animation is advancing ahead of what the user sees. Once it is called, the new frame is far ahead of the previously displayed frame. The only difference now is that we will display the previous frame for slightly longer until the next refresh tick. Note that if an animated image is layerized (should not happen today) or otherwise uses an ImageContainer, this optimization fails. While we know whether or not we have an image container, we do not know if anything is actively using it.

Bug 1460054 - Update Debugger Frontend v49. r=jdescottes MozReview-Commit-ID: 4wr5NnLBTn7

Bug 1302449 - Remove the "referrer" directive in CSP, r=ckerschb

Bug 1400678 - quota storage should be cleared on exit if user has requested cookies to be cleared on exit - fix a ES failure, r=me CLOSED TREE