Bug 1289549 P1 socialapi remove status and marks, r=florian MozReview-Commit-ID: 5fT51pp97Tm

Bug 1291180 - Add Android-Job library in the build r?sebastian MozReview-Commit-ID: 3c0myuFUlmY

Bug 1150371 - [Part2] DRM UI should not show up when Clearkey is the only one CDM created successfully. r?Gijs MozReview-Commit-ID: ISPrz7A979G

Bug 1150371 - [Part1] Remove 'Learn more about Drm...' from r-click context menu if it's a MediaElement for clearkey content. r?Gijs MozReview-Commit-ID: 9nRwG9Bx7D

Bug 1274042 - Add test for hidden checkbox in HTTP auth dialogs in e10s. r=Dolske MozReview-Commit-ID: FKocwybNyib

Bug 1274042 - Fix checkbox for HTTP auth dialogs in e10s. r=Dolske MozReview-Commit-ID: CuOBJ9m0DMW

Bug 1292245 - remove some unnecessary imports of chrome from devtools; r?gregtatum MozReview-Commit-ID: JVVVHAImsko

Bug 1290966 - Remove callback function argument from sync scripts; r?automatedtester MozReview-Commit-ID: CaDSYA5PNFp

Bug 1290966 - Permit introspection into arguments; r?automatedtester The callback function available to asynchronously evaluated scripts is defined in a privileged content frame script, and is thus not readable or introspectable in a sandboxed content script. Attempting this will yield a "Permission denied to access property" error. To circumvent this problem we "hide" the callback function by wrapping it before pushing it on the arguments object that is applied to the injected script. This allows introspection into the _immediate_ elements on the arguments object available to executed scripts. MozReview-Commit-ID: 9ZigPNYcYpf

Bug 1272614 - Avoid blocking where possible while waiting for the updater to stage; r?spohl MozReview-Commit-ID: 1aAU2wxQvMm

Bug 1291809 - Use http URL for DAMP simple page to get remote browser. r=bgrins MozReview-Commit-ID: 7e9CaKX6DTr

Bug 1291283 - Use URLValueData::GetLocalURLFlag() to identify local-ref URI. MozReview-Commit-ID: 2tXEGMhPCkn

Bug 1292184 - remove lazy requires from inspector; r?jlongster MozReview-Commit-ID: AQMlkXAlVeX

Bug 1291618 - Fix dropmarker position of command-button-frames in RTL locales. r=ntim MozReview-Commit-ID: 8yd1J6tkxDT

Bug 1291272 - Fix aboutdebugging reload test that requires a signed add-on. r=ochameau a=test-only MozReview-Commit-ID: 65CZqbbHAHo

Bug 1291030 - Update TPS dependencies to prevent crashes for locally built firefox on Mac 10.11. r=markh MozReview-Commit-ID: 9gmP6OJvakP

Bug 1290263 - Source maps in console don't work after first log; r=jsantell

Bug 1290063 - Call correct function on mouseout for breadcrumb; r=gasolin

Bug 1288341 - Don't overlap layout-expander in RTL Locales. r=ntim MozReview-Commit-ID: Gp4SeTZctIT

Bug 1012752 - Snap scrolled area to layer pixels. r?tnikkel We want the maximum scroll position to be aligned with layer pixels. That way we don't have to re-rasterize the scrolled contents once scrolling hits the edge of the scrollable area. Here's how we determine the maximum scroll position: We get the scroll port rect, snapped to layer pixels. Then we get the scrolled rect and also snap that to layer pixels. The maximum scroll position is set to the difference between right/bottom edges of these rectangles. Now the scrollable area is computed by adding this maximum scroll position to the unsnapped scroll port size. The underlying idea here is: Pretend we have overflow:visible so that the scrolled contents start at (0, 0) relative to the scroll port and spill over the scroll port edges. When these contents are rendered, their rendering is snapped to layer pixels. We want those exact pixels to be accessible by scrolling. This way of computing the snapped scrollable area ensures that, if you scroll to the maximum scroll position, the right/bottom edges of the rendered scrolled contents line up exactly with the right/bottom edges of the scroll port. The scrolled contents are neither cut off nor are they moved too far. (This is something that no other browser engine gets completely right, see the testcase in bug 1012752.) There are also a few disadvantages to this solution. We snap to layer pixels, and the size of a layer pixel can depend on the zoom level, the document resolution, the current screen's scale factor, and CSS transforms. The snap origin is the position of the reference frame. So a change to any of these things can influence the scrollable area and the maximum scroll position. This patch does not make us adjust the current scroll position in the event that the maximum scroll position changes such that the current scroll position would be out of range, unless there's a reflow of the scrolled contents. This means that we can sometimes render a slightly inconsistent state where the current scroll position exceeds the maximum scroll position. We can fix this once it turns out to be a problem; I doubt that it will be a problem because none of the other browsers seems to prevent this problem either. The size of the scrollable area is exposed through the DOM properties scrollWidth and scrollHeight. At the moment, these are integer properties, so their value is rounded to the nearest CSS pixel. Before this patch, the returned value would always be within 0.5 CSS pixels of the value that layout computed for the content's scrollable overflow based on the CSS styles of the contents. Now that scrollWidth and scrollHeight also depend on pixel snapping, their values can deviate by up to one layer pixel from what the page might expect based on the styles of the contents. This change requires a few changes to existing tests. The fact that scrollWidth and scrollHeight can change based on the position of the scrollable element and the zoom level / resolution may surprise some web pages. However, this also seems to happen in Edge. Edge seems to always round scrollWidth and scrollHeight upwards, possibly to their equivalent of layout device pixels. MozReview-Commit-ID: 3LFV7Lio4tG