Bug 1254020 - Always compute theme scaling factor when per-monitor dpi aware, even if only a single display is currently present. r=emk a=ritu MozReview-Commit-ID: 9KUukZ7tcxu

Bug 1245260 - Add crashtest; r=hiro a=ritu MozReview-Commit-ID: IBe0zbsCJJy

Bug 1245260 - Ignore redundant calls to RestyleManager::IncrementAnimationGeneration; r=dbaron a=ritu While processing restyles and starting transitions, we may trigger a call to EffectCompositor::UpdateCascadeResults which may, in turn, call EffectCompositor::RequestRestyle with RestyleType::Layer, which ultimately results in a call to RestyleManager::IncrementAnimationGeneration(). Typically, nsTransitionManager::StyleContextChanged compares the animation generation on its collection with that of the restyle manager and uses this to ignore the restyle that it generates. However, given the sequence of events above, that check may no longer help since the restyle manager's animation generation will be out of step. As a result, nsTransitionManager::StyleContextChanged will fail to ignore a subsequent and redundant restyle. With certain combinations of content, this can mean that restyles are posted in such a manner than an infinite cycle of restyles ensues. This patch causes RestyleManager to ignore calls to IncrementAnimationGeneration when it is already processing restyles such that the animation generation is only ever updated once per restyle. This makes the check for a matching animation generation in nsTransitionManager::StyleContextChanged work as expected, preventing us from generating needless transitions which can produce this endless loop. MozReview-Commit-ID: 9HYDrknKPAI

Bug 1259108 - Increase timeout of notifications from 12s to 20s to match parity with Chromium. r=MattN a=ritu MozReview-Commit-ID: 31RjSWuszuC

Bug 1259065 - Don't constrain window position (only its size) when DPI-rescaling during a move. r=emk a=ritu MozReview-Commit-ID: Dx8o4tFYBU3

Bug 1254491 - Enable downloadable fonts in all release channels. r=rnewman a=ritu MozReview-Commit-ID: 7htS1v9jWJq

Bug 1254468 - Post: Remove unused TransitionsTracker r=sebastian a=ritu This is no longer needed - TransitionAwareCursorLoaderCallbacks was the only consumer - it was removed as it caused race conditions. The ideal future solution is probably to use recyclerviews to avoid jank, rather than trying to wait for transitions to happen. It's also extremely difficult to use this correctly - the TransitionAwareCursorLoaderCallbacks simply held the cursor that would usually be swapped in onLoadFinished until transitions have finished (which is incorrect, since cursors need to be swapped in before onLoadFinished returns). It's hard to imagine any alternative solutions, short of avoiding loading cursors in the first place (which isn't too useful, since cursor loading happens in the background, at which point the UI status is irrelevant), or hacking the CursorLoader to not return from its worker thread until UI transitions are done (which would require a new thread-safe implementation of TransitionsTracker), or maybe even hacking Android Framework's AsyncTaskLoader to not run Loader.deliverResult while transitions are running (which seems awfully brittle and hacky). MozReview-Commit-ID: 3JWDcznYL4Y

Bug 1254468 - Remove broken TransitionAwareCursorLoaderCallbacks r=sebastian a=ritu TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader cursors _must_ not be used after onLoadFinished has been called. However we sometimes queue the cursor swapping (which is implemented by subclasses in onLoadFinishedAfterTransitions) until after transitions have finished. CursorLoader.deliverResult() closes the old cursor immediately after calling onLoadFinished (with the new cursor). At this stage the adapter is still holding onto the old (but now closed cursor), and will crash if it tries to read this cursor (which can happen if the adapter is still iterating over the cursor). Instead we should ensure that we swap the cursors during onLoadFinished - the simplest way to do this is by eliminating TransitionAwareCursorLoader and using onLoadFinished the way the Android framework expects. It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added, home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about its transitions. However HomePagerTabStrip no longer exists, hence there's no need for us to care about these transitions anymore. (The crash seems to happen because we try to hide the doorhanger every time we receive LOCATION_CHANGE, and each of these starts a hide transition - even if no doorhanger is shown - hence we often have a transition in progress every time we show topsites.) MozReview-Commit-ID: HsytLpHOrp2

Bug 1258567 - per comment 3, ensure volume is only applied once to the AudioSegment. r=kinetik. a=ritu MozReview-Commit-ID: Bks59JySrep

Bug 1256615 - Partially restore removed <activity-alias>. r=sebastian a=ritu Bug 1242213 removed the entire <activity-alias>. Sadly, users who added the Firefox icon to their dock (for example, Samsung's Touchwiz dock) will see the icon disappear when they upgrade, because the intent filter disappears. (That is, the icon is connected to .App and action MAIN, not to the package and action MAIN.) This patch restores the .App <activity-alias> for action MAIN. It doesn't add the launcher and other categories, which could lead to multiple launcher icons. New users that add the Firefox icon to their dock will use .BrowserApp, but sadly we'll need to maintain this alias essentially forever to support existing dock icons. MozReview-Commit-ID: 1o9XS5MEs1s

Bug 1256515 - bail out in CanvasRenderingContext2D::DrawWindow if snapshotting draw target fails. r=bas.schouten a=lizzard MozReview-Commit-ID: LxQ3v8zqXI

Bug 1254102 - Add "blackout" mode. If the window is not legal, output a black square. r=jesup a=ritu MozReview-Commit-ID: GlBy8fUZwIE

Bug 1254102 - Don't skip Tab sources if the camera is in use. r=jesup a=ritu MozReview-Commit-ID: 7ZaebdnWj3R

Bug 1041599 - Maintain a single volume control session between browser, content, and plugins on Windows. r=aklotz a=ritu MozReview-Commit-ID: 2LuYciKfsWn

Backed out changeset 30de9ac21a78 (bug 1256992) for causing crashes a=backout MozReview-Commit-ID: L30XEzrSo0y

Bug 1254122 - Don't bother saving scratch registers across TypeUpdate IC calls. r=jandem, a=lizzard

Bug 1246061. r=jandem, r=bz, r=luke, r=froydnj, a=lizzard

Bug 1256061 - Hold a strong reference to a request when we call a method on it. r=jdm, a=ritu I think it is possible for the TimerCallbackHolder to fire off a Notify() while the geolocation object and the nsGeolocationRequest are only holding each other alive, so they would be freed by the cycle collector the next time it runs, but we haven't run the cycle collector yet. If that happens, then Geolocation::RemoveRequest() would break the cycle, causing stuff to unravel and bad things to happen. To fix this, we just hold the request alive in TimerCallbackHolder::Notify(), which will also ensure that the geolocation object is alive, hopefully preventing crashes. This will make the Notify() behavior similar to what it was before bug 1238427, when the nsITimer object would hold a strong reference to the request when the Notify() was being run.

Bug 1242668 - Hold more references. r=sotaro, a=lizzard

Bug 1258231 - Lock while iterating console messages. r=mccr8, a=lizzard