Bug 1256565 - Part 3. Turn on highrestimestamp on Android Nightly. r=smaug MozReview-Commit-ID: HSXAiXkYfLv

Bug 1256565 - Part 2. Use GetEventTimeStamp() for timestamp. r=jchen MozReview-Commit-ID: 4fBI6EXLmR1

Bug 1256565 - Part 1. Implement GetEventTimeStamp(). r=jchen r?karlt Android uses android.os.SystemClock.uptimeMilles for event time and SystemClock.uptimeMilles uses SYSTEM_TIME_MONOTONIC. So since TimeStamp posix impelemetation uses SYSTEM_TIME_MONOTONIC too, so we can use event time on FromSystemTime. MozReview-Commit-ID: 5Qb5kmnHHCI

Bug 1338961 - A mozinputrangeignorepreventdefault hack for input[type=range], r=smaug, sr=smaug This is a terrible hack, asking input[type=range] in our video control xbl binding content continue to handle mouse/touch event, even if the event is being defaultPrevented by the content. MozReview-Commit-ID: G1huxbS7oeq

Bug 1340942. Part 4 - pass Data& to DoInitDecoder(). MozReview-Commit-ID: IwlpxR2MuRE

Bug 1340942. Part 3 - pass Data& to DoCreateDecoder. MozReview-Commit-ID: ABHu0tp57AM

Bug 1340942. Part 2 - pass Data& to RunStage(). MozReview-Commit-ID: DAALmMBhoep

Bug 1340942. Part 1 - add some members so we don't have to pass the track type around. MozReview-Commit-ID: Ewipsg8FFqb

debug MediaCache. MozReview-Commit-ID: 3uGC1nCUKi0

Bug 1314921 - merge events.js into constants.js;r=rickychien MozReview-Commit-ID: 3tstH8uxv0B

Bug 1314921 - move top-level files into utils;r=honza MozReview-Commit-ID: GtAe9ggiCeA

Bug 1338082 - Add telemetry probes to track the positive and negative cache durations in V4. r?francois MozReview-Commit-ID: 43Nf5bS2Uo

Bug 1340885 - Null check frame's content when searching for NAC ancestors in GetCorrectedParent. r?xidorn MozReview-Commit-ID: 7u2yKe8ir1V

Bug 1337694 - Add Language negotiation to LocaleService API MozReview-Commit-ID: 59zOYC8Y219

Bug 1337694 - Add language negotiation heuristics to LocaleService. MozReview-Commit-ID: Ka6ESWYqyTQ

Bug 1323366 - Create new IconRequest to prevent ConcurrentModificationException, r?sebastian

Bug 1317223 (part 6) - integration tests for the bookmark repair requestor and responder. r?tcsc This is an attempt at a true integration tests without the use of mocks. It's tricky and hacky to do such tests - I suspect this patch is probably misguided and that TPS might be a better environment for these kinds of tests - I'm flagging Thom for review here primarily to see what he things about using TPS instead of this. MozReview-Commit-ID: 8us4v6Y21oM

Bug 1317223 (part 5) - a bookmark repair responder. r?kitcambridge This is the "repair responder" - it handles a "repairRequest" command sent by another client and attempts to take the list of IDs that client lists as missing and upload whatever records are necessary such that the requesting client would then be likely to find a complete and valid tree on the server. In the simple case, the responder would just upload the listed items if they exist locally, but this isn't smart enough - we will also need to (a) walk to the root from a requested item and ensure all subsequent parents also exist (b) if the missing item is a folder ensure the entire subtree under the item exists correctly and (c) see if the item should never have been uploaded in the first place (eg, if it is a local left-pane root) and if so, issue a delete of that ID and all subsequent parents up to the root. Currently (a) is done - (b) and (c) are not. The main TODOs here are: * (b) and (c) above, including tests for those. * Any other edge cases we can think about. * See if the "tree walking" code in the patch should be moved to PlacesSyncUtils. * Formalize the concept of "track weakly" used in the patch - we don't touch the syncChangeCounter field when tracking items as the entire repair process will automatically restart when the browser does. * More tests for other edge-cases - there are some XXX comments in the test file. MozReview-Commit-ID: 4xw19nH6EfL

Bug 1317223 (part 4) -Formalize weak tracking in `BookmarksChangeset`. r=markh MozReview-Commit-ID: C6otrtSuhZH

Bug 1317223 (part 3) - A bookmark repair requestor. r=markh,tcsc This is where the fun actually starts :) The bookmark repair requestor takes the validation results, and if those results include missing children records (when the parent exists but a child doesn't) and orphans (when the child exists but the parent doesn't) it kicks off a repair request by sending a "repairRequest" command to other clients in a controlled manner (effectivly a round-robin of all suitable other devices, waiting for a period of time before giving up on that client and moving on to another) until either all requested IDs have been found or no other clients are suitable. The main TODOs in this patch are: * See if there are other obvious validation results which mean a simple "record is missing from the server". * Decide if we really do need to attempt each client twice given that part 1 changes the engine implementation such that the repairRequest command is not actually removed from the client record until a repairResponse has been written. (See XXX comment in _continueRepairs) * Possibly more tests of edge and error cases. MozReview-Commit-ID: 7rRNbBx8Vo3