a1c904b858e8dc096ad8ed6d6f21235a26641c71: Bug 1458049 - Implement ability to move a selection of tabs into a new window through tab context menu. r?jaws draft multiselect_move
Abdoulaye O. Ly <ablayelyfondou@gmail.com> - Fri, 06 Jul 2018 03:58:44 +0000 - rev 815529
Push 115531 by bmo:ablayelyfondou@gmail.com at Mon, 09 Jul 2018 05:26:49 +0000
Bug 1458049 - Implement ability to move a selection of tabs into a new window through tab context menu. r?jaws MozReview-Commit-ID: Lgng51Ponqw
ac31505c57a5af2d129b783f3c36164f911fcebf: Bug 1474149 - Allow media seek amount so be configured draft
h-h <henrik.hank@aol.de> - Mon, 09 Jul 2018 07:07:07 +0200 - rev 815528
Push 115530 by bmo:henrik.hank@aol.de at Mon, 09 Jul 2018 05:07:47 +0000
Bug 1474149 - Allow media seek amount so be configured Satisfied ESLint. MozReview-Commit-ID: 97wsTqRC26M
ca20160475fdcf131994e8256a619008a1009d6f: Bug 1474149 - Allow media seek amount so be configured draft
h-h <henrik.hank@aol.de> - Mon, 09 Jul 2018 06:28:20 +0200 - rev 815527
Push 115529 by bmo:henrik.hank@aol.de at Mon, 09 Jul 2018 04:36:12 +0000
Bug 1474149 - Allow media seek amount so be configured When you play audio or video in Firefox, you can jump by a fixed amount of 15 seconds, as this help page explains: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_media-shortcuts. Here are media files for testing. You may have to click on the pause/play button, before the keystrokes will be recognized: - Audio: http://wilwheaton.typepad.com/files/wil_wheaton_vs_text_2_speech.mp3 - Video: http://www.belleslettres.eu/video/konjunktiv-irrealis.mp4 15 seconds is an unusual big seek step. These apps all have 5 seconds as their default seek step: - YouTube - foobar2000 (popular audio player for Windows) - MPC-BE (video player for Windows) So, a user should be able to modify the seek step length. To accomplish that, this patch introduces the config option `media.seekStepLength`. I changed `HTMLMediaElement`, because, in `videocontrols.xml`, unlike in other XBL files, - `Services` (for `Services.prefs.getIntPref()`), - `Cc` (for `Cc["@mozilla.org/preferences-service;1"]`) or - `Components`/`Components.classes` (for `Components.classes["@mozilla.org/preferences-service;1"]`) ...were not available. In accordance with the existing `HTMLMediaElement` API, the newly introduced property `mozSeekStepLength` has seconds as its unit. The `media.seekStepLength` config option is in milliseconds, because floats are converted from strings and milliseconds are already a popular unit in Firefox's preferences. Should I add `, 15000` like in the following code, in case the config option was deleted? ```c++ double HTMLMediaElement::MozSeekStepLength() const { return Preferences::GetInt("media.seekStepLength", 15000) /*ms*/ / 1000.0; } ``` MozReview-Commit-ID: 97wsTqRC26M
0dea01725c3235e9c14363df0f29c5343a8c3b7e: Bug 1421885 - Part 2: Don't compute APZ touch-action regions on platforms that don't support touch gestures. r?kats draft
Matt Woodrow <mwoodrow@mozilla.com> - Mon, 09 Jul 2018 16:13:23 +1200 - rev 815526
Push 115528 by mwoodrow@mozilla.com at Mon, 09 Jul 2018 04:13:53 +0000
Bug 1421885 - Part 2: Don't compute APZ touch-action regions on platforms that don't support touch gestures. r?kats MozReview-Commit-ID: EdHKXIcPKMd
1c9e658e0c45624920ded92d63338b63645f23e8: Bug 1421885 - Part 1: Don't let mNoActionRegion get complex when we've already added it to mDispatchToContentRegion. r?kats draft
Matt Woodrow <mwoodrow@mozilla.com> - Mon, 09 Jul 2018 16:12:54 +1200 - rev 815525
Push 115528 by mwoodrow@mozilla.com at Mon, 09 Jul 2018 04:13:53 +0000
Bug 1421885 - Part 1: Don't let mNoActionRegion get complex when we've already added it to mDispatchToContentRegion. r?kats MozReview-Commit-ID: 11gi2u4bAdJ
58689fec70396b117138ddc2c33c5b7c265dc0e1: Bug 1466638 - Implement support for ContainerLayerParameters::mOffset in nsDisplayImageContainer. r?mstange draft
Matt Woodrow <mwoodrow@mozilla.com> - Mon, 09 Jul 2018 16:11:08 +1200 - rev 815524
Push 115527 by mwoodrow@mozilla.com at Mon, 09 Jul 2018 04:11:40 +0000
Bug 1466638 - Implement support for ContainerLayerParameters::mOffset in nsDisplayImageContainer. r?mstange This gets set to a non-zero value when we have an inactive ContainerLayer ancestor (filter in this case). The current code assumes we'd never call BuildLayer on an image when that happen, but we force the pseudo-active state here because background-position is animated (all properties have a transition). MozReview-Commit-ID: 6pL8EJTNgWy
b75bdd1e80de4399549477137fc83f274d6705c4: Bug 1458049 - Implement ability to move a selection of tabs into a new window through tab context menu. r?jaws draft multiselect_move
Abdoulaye O. Ly <ablayelyfondou@gmail.com> - Fri, 06 Jul 2018 03:58:44 +0000 - rev 815523
Push 115526 by bmo:ablayelyfondou@gmail.com at Mon, 09 Jul 2018 04:06:48 +0000
Bug 1458049 - Implement ability to move a selection of tabs into a new window through tab context menu. r?jaws MozReview-Commit-ID: Lgng51Ponqw
982f2e5aae5d57b3fc095d48fabe5370686f27e0: Bug 1368808 - Honor the system light/dark mode setting on Windows 10. r?jimm draft
Matt Howell <mhowell@mozilla.com> - Sun, 08 Jul 2018 17:32:52 -0700 - rev 815522
Push 115525 by bmo:mhowell@mozilla.com at Mon, 09 Jul 2018 03:13:20 +0000
Bug 1368808 - Honor the system light/dark mode setting on Windows 10. r?jimm MozReview-Commit-ID: 3bzhX9bfR4s
ff633d9021e9afe3ab9114a5b0c952b6057cdc6d: Bug 1474007: Null check to prevent crash when ipc::mscom::GetInitialInterceptorForIID fails after PublishTarget. r?aklotz draft
James Teh <jteh@mozilla.com> - Mon, 09 Jul 2018 10:24:20 +1000 - rev 815521
Push 115524 by bmo:jteh@mozilla.com at Mon, 09 Jul 2018 02:54:12 +0000
Bug 1474007: Null check to prevent crash when ipc::mscom::GetInitialInterceptorForIID fails after PublishTarget. r?aklotz PublishTarget calls Unlock on our LiveSetAutolock. It's possible for GetInitialInterceptorForIID to fail after this point. This will cause the failure cleanup code to run, which tries to call Unlock again. However, the previous call to Unlock set mLiveSet to null, and Unlock previously didn't handle this case. Now, unlock is a no-op (in release builds) if it's already been called. MozReview-Commit-ID: 15ffXR6nKqc
cf10434712a07e02a780763a798863bcc8e56460: Bug 1423011 - Part 3: Add mochitests. r?botond draft
Tanushree Podder <tpodder@mozilla.com> - Sun, 08 Jul 2018 20:37:04 -0400 - rev 815520
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1423011 - Part 3: Add mochitests. r?botond MozReview-Commit-ID: 7jqh8ExtbVE
484a808a7cdc89fe1f7827065185d48015bbe71b: Bug 1423011 - Part 2: Add gtests. r?botond draft
Tanushree Podder <tpodder@mozilla.com> - Sun, 08 Jul 2018 20:34:57 -0400 - rev 815519
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1423011 - Part 2: Add gtests. r?botond Ensures that APZ correctly updates the layout viewport offset when the visual viewport exceeds the boundaries of the layout viewport. Includes changes to APZCPinchTester::GetPinchableFrameMetrics to correct the offset of the composition bounds (which should always be (0, 0) for the RCD-RSF) and fixes to impacted test cases. MozReview-Commit-ID: JIyDglsqAYh
202e34310f9f7362bfadf7cbb898db6365889f96: Bug 1423011 - Part 1: Allow APZ to async-scroll the layout viewport. r?botond draft
Tanushree Podder <tpodder@mozilla.com> - Sun, 08 Jul 2018 20:32:42 -0400 - rev 815518
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1423011 - Part 1: Allow APZ to async-scroll the layout viewport. r?botond There are 3 main components to this change: a) Store the origin of the layout viewport in APZ (until now we only stored it's size). This required updating the offset stored in mViewport, which was previously (0, 0). b) Adjust the layout viewport in APZ each time the visual viewport exceeds the bounds of the layout viewport. c) Update the main thread to store the layout viewport offset for the RCD-RSF (currently it uses the layout viewport offset for overflow:hidden pages, and the visual viewport offset otherwise). MozReview-Commit-ID: LmwalLnPDYZ
2207dc948a86ef6f61d857d1f941fb499b7d4cc8: Bug 1423011 - Part 4: Fix for overflow-x:hidden test failures in the mochitest test_wheel_default_action.html. r?botond draft
Tanushree Podder <tpodder@mozilla.com> - Tue, 03 Jul 2018 13:12:17 -0400 - rev 815517
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1423011 - Part 4: Fix for overflow-x:hidden test failures in the mochitest test_wheel_default_action.html. r?botond Scrolling is not permitted along the axis whose overflow style is hidden. In the mochitest test_wheel_default_action, tests which checked if overflow hidden pages were scrollable failed after the changes in the Part 1 patch were submitted to try. The tests failed as overflow hidden pages were scrollable. After investigating the sequence of events, we realized that the overflow-x:hidden property was taking effect on the compositor thread after the scroll-wheel event was received on the compositor thread. Therefore, scrolling took place even before the scrollable rect was sized appropriately and scrolling beyond the layout viewport size was possible. To solve this, we wait for all repaints to occur before the test sends a scroll-wheel event. Waiting for all repaints guarantees that the overflow-x:hidden property will be set before a scroll-wheel event is received. MozReview-Commit-ID: 2hc3MTyKhnS
ffb7b5015fc331bdc4c5e6ab52b9de669faa8864: Merge inbound to mozilla-central. a=merge
Brindusan Cristian <cbrindusan@mozilla.com> - Mon, 09 Jul 2018 00:36:24 +0300 - rev 815516
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Merge inbound to mozilla-central. a=merge
3c24d85af2dbe96025422dabc9ebdc5867786b03: Bug 1474122 - Update brotli to version 1.0.5. r=jfkthame
Ryan VanderMeulen <ryanvm@gmail.com> - Sat, 07 Jul 2018 16:00:53 -0400 - rev 815515
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1474122 - Update brotli to version 1.0.5. r=jfkthame
8eab40c279038941d767790b2d2cf82b21634ff0: Bug 1452490 - Remove marionetteScriptFinished. r=whimboo
Venkatesh Pitta <venkateshpitta@gmail.com> - Sun, 08 Jul 2018 14:52:49 +1000 - rev 815514
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1452490 - Remove marionetteScriptFinished. r=whimboo MozReview-Commit-ID: CdQCmtaodww
33e19a7ad66420c29648b459214634eadb627cef: Bug 1473651: Track animated image status for generated content and content: url(). r=tnikkel
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 06 Jul 2018 10:22:09 +0000 - rev 815513
Push 115523 by bmo:tpodder@mozilla.com at Mon, 09 Jul 2018 00:41:46 +0000
Bug 1473651: Track animated image status for generated content and content: url(). r=tnikkel I thought of just moving the tracking to nsImageFrame instead of nsImageLoadingContent entirely, though that would mean I need to handle it also in nsImageBoxFrame and nsSVGImageFrame, which was even more duplicated code. Ideas for testing this welcome, though all our animated image test-cases are borked (all reftests in image/test/reftest/apng are disabled, and all the ones for gifs that have animations as well). I'll cross-ref this bug and bug 1473651 so that we can write a test for this once that's fixed. Differential Revision: https://phabricator.services.mozilla.com/D1994
fe7d3ee17f8f66539fdb07325e687ff2da2ed4a8: Bug 1468475 - Part 2. Display the zero graduation. r?daisuke draft
Mantaroh Yoshinaga <mantaroh@gmail.com> - Mon, 09 Jul 2018 09:32:17 +0900 - rev 815512
Push 115522 by bmo:mantaroh@gmail.com at Mon, 09 Jul 2018 00:32:49 +0000
Bug 1468475 - Part 2. Display the zero graduation. r?daisuke This patch will ensure that displaying the zero graduation into the timeline by using shift the graduation with zeroBaseTime. If we shifted all of the graduations, the graph might not have the first graduation. So this patch will add the first graduation intentionally in this case. Furthermore, this patch will not display negative divisions excepting the first graduation. MozReview-Commit-ID: I2RTFtQWEtL
2ed7f042063c55de4c58fb2aa57efcb8f2236cbd: Bug 1468475 - Part 2. Display the zero graduation. r?daisuke draft
Mantaroh Yoshinaga <mantaroh@gmail.com> - Mon, 09 Jul 2018 09:21:46 +0900 - rev 815511
Push 115521 by bmo:mantaroh@gmail.com at Mon, 09 Jul 2018 00:22:27 +0000
Bug 1468475 - Part 2. Display the zero graduation. r?daisuke This patch will ensure that displaying the zero graduation into the timeline by using shift the graduation with zeroBaseTime. If we shifted all of the graduations, the graph might not have the first graduation. So this patch will add the first graduation intentionally in this case. Furthermore, this patch will not display negative divisions excepting the first graduation. MozReview-Commit-ID: 3zkPH8RuCoj
86f77e9d3952c376e942fec0ef4e35043060a699: Bug 1468475 - Part 1. Introduce zeroPositionTime in order to shift the graduation if animations have negative-delay. r?daisuke draft
Mantaroh Yoshinaga <mantaroh@gmail.com> - Fri, 06 Jul 2018 19:34:38 +0900 - rev 815510
Push 115521 by bmo:mantaroh@gmail.com at Mon, 09 Jul 2018 00:22:27 +0000
Bug 1468475 - Part 1. Introduce zeroPositionTime in order to shift the graduation if animations have negative-delay. r?daisuke This patch will introduce the zeroPositionTime, this value means the time that current time of animation will be zero. In front-side, use this value for shifting the graduation in order to display the zero. MozReview-Commit-ID: 3XawdLTehJo
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip