Bug 1419148 - Export Screenshots 25.0.0 to Firefox (except translations); r?kmag,ianbicking MozReview-Commit-ID: 2InUwTe8oPa

Bug 1419148 - Export Screenshots 25.0.0 to Firefox (translations only); r=ianbicking MozReview-Commit-ID: 5vscnPIGDvN

Bug 1419226 - Part 3.Wait for non-timer MozAfterPaint on an animation mochitest.r?hiro This patch will: * Wait for MozAfterPaint without waiting for another event in test_deferred_start.html. * Remove waiting for MozAfterPaint if paint process doesn't occur in test_restyles.html. * Move advanceTimeAndRefresh() before waiting for MozAfterPaint in order to occur painting process in test_missing-keyframe-on-compositor.html. MozReview-Commit-ID: 4M79yTywc9k

Bug 1419226 - Part 2. Create the notify did paint timer only if view manager has a pending flush. r?mattwoodrow This EnsureEventualDidPaintEvent() creates software timer. But this timer will bring several intermittent tests fail. For example, if we want to check the compositor animation property. If test receives MozAfterPaint of the timer, there doesn't have animation property on compositor, as result of this, a test will fail. I think we don't need to create this timer each time since current painting is happening synchronously under the refresh driver. However, we might need this timer when display list invalidation doesn't invalidate actually[1]. So this patch will remove this timer from NotifyInvalidat(), and create timer only if nsPresContext::IsDOMPaintEventPending() return true due to view manager has pending flush. [1] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#189 MozReview-Commit-ID: BouX6RCu9jQ

Bug 1419226 - Part 1.Change observing target window of MozAfterPaint of the print preview. r?mconley Previous code, print preview waits for content window's MozAfterPaint. However gecko prevents send MozAfterPaint to content window[1]. So this code will not work correctly. However, software timer of firing MozAfterPaint ran this code.[2] This patch will change the observing content to chrome content. [1] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#2452 [2] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#3466-3472 MozReview-Commit-ID: JHcvt1pR6Xs

Bug 1406585 - Close the autocomplete popup when the crash of a content page or Message Manager disconnection happens. r=MattN MozReview-Commit-ID: DjSc4R0WBQP

Bug 1419148 - Export Screenshots 25.0.0 to Firefox (except translations); r?kmag,ianbicking MozReview-Commit-ID: 2InUwTe8oPa

Bug 1418766 - Fix Crash in java.lang.OutOfMemoryError by making Exoplayer pause by default. MozReview-Commit-ID: JGIRcYLXtdv

Bug 1418430. P2 - simplify the if statement of "reopen on error". A truth table is listed to illustrate all conditions of length/offset/reopen. The original code doesn't handle the following cases correctly: 1. length == offset == 0, shouldn't reopen the channel for there is no data to download. 2. length == -1 && offset > 0, should reopen the channel if seekable. MozReview-Commit-ID: IisnrA8hK4M

Bug 1418430. P1 - always check "reopen on error" when a connection is closed. The server might send us fewer bytes than requested. So we also need "reopen on error" in this case as well. MozReview-Commit-ID: Fi82x4h1TZ0

Fix clang-format. MozReview-Commit-ID: K8AtqkyOZpP

Bug 1417869. P2 - abort the load algorithm early if media not allowed to load. MozReview-Commit-ID: DUxyo4ywCPW

Bug 1417869. P1 - Backed out changeset bf0e4dd83b3b of bug 1412505. MozReview-Commit-ID: KdxxwIsHZJS

Bug 1416799 - fix crash when seek fails. MozReview-Commit-ID: A2HWJB3x7pb

Bug 1416686 - Reduce the uses of IPC_FAIL_NO_REASON in GMPChild.cpp. Originally, we use IPC_FAIL_NO_REASON to make IPC call return error and then it invokes MOZ_CRASH to kill the process itself. By using IPC_FAIL, we can pass a descriptive reason to GMPChild::ProcessingError and Bug 1416667 will use MOZ_CRASH_UNSAFE_PRINTF to print the reason to the crash report. In addition, we use CrashReporter::AnnotateCrashReport to record the lib path without exposing the data publicly. MozReview-Commit-ID: 15n1PItLgAp

Bug 1414745 - Filter out everything except STATE_IS_NETWORK in nsBrowserStatusFilter::OnStateChange. r?mconley The mFinishedRequests / mTotalRequests counters in nsBrowserStatusFilter has been known buggy for around a decade. With e10s we double filtered in both parent and child processes which makes it worse. There are a few problems with the counters / filter: 1. The ResetMembers() were invoked on each network request starts, which means a iframe document loading followed by the root document loading would also reset the members incorrectly. 2. The filter for non-network request was incorrect. The basic idea seems to be that if `mFinishedRequests == mTotalRequests` and `!isLoadingDocument`, it should be the STOP request right after document loading finishes, and that STOP should be delivered so listener would get symmetric numbers of START / STOP of STATE_IS_REQUEST. However some requests such as imgRequest can start after document loading finishes, in this case the START would be filtered out (since mFinishedRequests != mTotalRequests), but STOP would be delivered to the listener. It's the reason that nsBrowserStatusFilter tend to deliver much more STATE_STOP than STATE_START. 3. When applying the filter on both parent & child side, the above issues often make the mFinishedRequests / mFinishedRequests be unmatched on parent side, eseentially filtered out most non-network requests and make the progressChange based on the counters useless. Firefox no longer shows the ratio of progressChange on the UI (and the number is incorrect anyway with current nsBrowserStatusFilter), and Fennec's progress bar is based on some predefined constants [1] which doesn't rely on progressChange either, so it not necessary to keep calculating a progress number with request counters. In addition, it seems tabbrowser & browser.js mostly only care about STATE_IS_NETWORK, and Fennec has already filtered out everything else [2], it should be safe to only pass STATE_IS_NETWORK to the listener, and we get the benefit of reducing unused IPC messages. [1] https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/mobile/android/base/java/org/mozilla/gecko/Tab.java#111-115 [2] https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/mobile/android/chrome/content/browser.js#4356-4357 MozReview-Commit-ID: 5tUP5SRwDoP

Bug 1413310 - Part 2: Add unit tests for CSS variable swatches r?tromey MozReview-Commit-ID: reE7ctzoQd

Bug 1413310 - Part 1: Add swatches for CSS variables r?tromey MozReview-Commit-ID: 6Z5vqbYiCWq

Bug 1417639 move tests out of mochitest-chrome MozReview-Commit-ID: 6Ot7VedwNek

Bug 1418374 - Discard blob image key when we create another new one. r=kats MozReview-Commit-ID: FOa25SkYmdK