e3512368ff7a1d5c3c2fa395aa0aea84efa3e63e: Bug 1424970 - adjust label for preferring tabs over windows for _blank links, r=jaws
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 04 Jan 2018 15:09:02 +0000 - rev 397768
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1424970 - adjust label for preferring tabs over windows for _blank links, r=jaws MozReview-Commit-ID: 555cehqwoLg
982eb37f52f62f4801d0fa85a89c64260ae09d3f: bug 1401647 - Fix spidermonkey mozjs / rust-bindings builds. r=nalexander
Ted Mielczarek <ted@mielczarek.org> - Wed, 03 Jan 2018 14:51:52 -0500 - rev 397767
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
bug 1401647 - Fix spidermonkey mozjs / rust-bindings builds. r=nalexander The spidermonkey mozjs and rust-bindings builds run sed on $topsrcdir/.cargo/config.in to generate the cargo config they use, but they previously only replaced the @top_srcdir@ substitution. This patch makes them replace any other substitutions with an empty value to add a bit of future-proofing. MozReview-Commit-ID: 1DzP9vXxHMD
98ec3a378b91ad49a8b82138b5d2283ae6c98e66: bug 1401647 - use a 64-bit Rust toolchain for win32 builds. r=nalexander,rillian
Ted Mielczarek <ted@mielczarek.org> - Thu, 14 Dec 2017 10:20:33 -0600 - rev 397766
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
bug 1401647 - use a 64-bit Rust toolchain for win32 builds. r=nalexander,rillian We currently use a 32-bit Rust toolchain for win32 builds, but this can lead to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain, which requires a little bit of extra configuration because rustc needs to be able to find a link.exe that produces 64-bit binaries for building things like build scripts, which are host binaries. We will now generate a batch file that sets LIB to the paths to 64-bit libraries and invokes the x64-targeting link.exe, and add a section to the .cargo/config file to instruct cargo to use that batch file as the linker when producing 64-bit binaries. MozReview-Commit-ID: 9vKBbm7Gvra
d098b3eb9f976fa8a3f207db2b442db13e6ce26e: Bug 1401647 - Add i686 target to win64-rust. r=ted
Ralph Giles <giles@mozilla.com> - Wed, 13 Dec 2017 22:41:29 -0600 - rev 397765
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1401647 - Add i686 target to win64-rust. r=ted Add a cross-compilation copy of rust's standard library targeting i686-pc-windows-msvc to the win64-rust toolchain package so it can be used to build for win32 as well. MozReview-Commit-ID: 3598VZrDjIH
29e0ea0b247007a2760addeae2c8194686a8d35c: Bug 1427670 - Escape warning message when the user can't write to their profile. r=mhowell
Joey Chagnon <chagnon.joey@gmail.com> - Tue, 02 Jan 2018 22:40:44 -0500 - rev 397764
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1427670 - Escape warning message when the user can't write to their profile. r=mhowell MozReview-Commit-ID: C5ZJd6ZQwzz
ed1d0d623ca4a66733383335b6fa19a5a3472b76: Bug 1428040 - Allow PlacesUtils.isRootItem to take guids as well as ids. r=mak
Mark Banner <standard8@mozilla.com> - Thu, 21 Dec 2017 09:16:48 +0000 - rev 397763
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1428040 - Allow PlacesUtils.isRootItem to take guids as well as ids. r=mak MozReview-Commit-ID: 9ZMA2A879O8
7fe4c38ae22f924209aacc4cb3e5177d79cdb9ef: Bug 1428061 - Remove support for the tabs-bottom class. r=jaws
Dão Gottwald <dao@mozilla.com> - Thu, 04 Jan 2018 16:29:30 +0100 - rev 397762
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1428061 - Remove support for the tabs-bottom class. r=jaws MozReview-Commit-ID: KvOO0uCjCUC
42358e64b1cc6224a4dfd9592b722aef74facbc0: Bug 1424921 - Support Lint dependencies in bootstrap. r=froydnj
Mark Banner <standard8@mozilla.com> - Wed, 03 Jan 2018 21:11:44 +0000 - rev 397761
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1424921 - Support Lint dependencies in bootstrap. r=froydnj - Add node as a dependency on Linux and Mac - Add python3 for Mac only (linux generally has it installed already). MozReview-Commit-ID: EpNWFTI9UXc
bd91c94565e31f70b1a8a63a0f2bbff962bf5d21: Bug 1421335 - Update test; r=nchevobbe
Jan Odvarko <odvarko@gmail.com> - Mon, 11 Dec 2017 14:39:37 +0100 - rev 397760
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1421335 - Update test; r=nchevobbe MozReview-Commit-ID: Far6gsV6SXd
7f796e33aa5bd233d64e9d3eb466e62ca91af99e: Bug 1421335 - Right response info link disappears after request is expanded; r=nchevobbe
Jan Odvarko <odvarko@gmail.com> - Thu, 07 Dec 2017 16:28:33 +0100 - rev 397759
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1421335 - Right response info link disappears after request is expanded; r=nchevobbe MozReview-Commit-ID: 5WEqPQaWGGt
08fbe54daea390c164308cce9e97a288c420166a: Bug 1341466 - Stop Marionette test run when Android emulator is unresponsive; r=automatedtester
Maja Frydrychowicz <mjzffr@gmail.com> - Thu, 16 Nov 2017 12:00:49 -0500 - rev 397758
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1341466 - Stop Marionette test run when Android emulator is unresponsive; r=automatedtester The clean-up code in FennecInstance now counts and logs consecutive DMErrors. The Marionette clean-up code then throws an UnresponsiveInstanceException if we hit consecutive errors more than twice, which interrupts the test run entirely. (Previously, MarionetteTestRunner would just keep running tests despite consecutive clean-up failures, and eventually it would time out.) This change allows us to take advantage of the retry mechanism in the mozharness script that runs all Android tests: it sets the job status to "retry" if it finds DMError in the test log after the run_tests step is done. MozReview-Commit-ID: J36XuFVK1aK
39a358d362671cc16d31d4660924d286fb3c16b8: Bug 1404368 - Enable browser_webconsole_document_focus.js in new frontend;r=jdescottes.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Thu, 04 Jan 2018 12:35:06 +0100 - rev 397757
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1404368 - Enable browser_webconsole_document_focus.js in new frontend;r=jdescottes. MozReview-Commit-ID: Fd9p0oigRpB
87cd01b3dc4c615da71bc64e14594b96a7f65519: Bug 1428006 - Remove skip-if for browser_webconsole_cspro.js;r=nchevobbe.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Thu, 04 Jan 2018 12:18:18 +0100 - rev 397756
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1428006 - Remove skip-if for browser_webconsole_cspro.js;r=nchevobbe. The test was refactored in Bug 1408932, but it wasn't actually enabled. MozReview-Commit-ID: 85vI9iX5p2V
d64cd605dc2f942f8b8efbf6ad21101f5f53544f: Bug 1362425 - Remove unused browser/app/profile/pagethemes.rdf. r=mak
Tim Nguyen <ntim.bugs@gmail.com> - Thu, 04 Jan 2018 00:37:11 +0100 - rev 397755
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1362425 - Remove unused browser/app/profile/pagethemes.rdf. r=mak MozReview-Commit-ID: 3ubOgBDMDwk
6b76f6a5ca637af6cd6c32aeed183bbf4f01ae0e: Bug 1426809 - Prevent fetching network update packet again after packet arrived r=Honza
Ricky Chien <ricky060709@gmail.com> - Sat, 23 Dec 2017 14:03:24 +0800 - rev 397754
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1426809 - Prevent fetching network update packet again after packet arrived r=Honza MozReview-Commit-ID: 5Ifgj1opsNW
849d216e3f9afe08b2896c0b793119efa6c966d1: Bug 1427568 - Adding python 3 support for mozversion. r=wlach
Vedant Chakravadhanula <vedantc98@gmail.com> - Tue, 02 Jan 2018 09:17:28 +0530 - rev 397753
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1427568 - Adding python 3 support for mozversion. r=wlach MozReview-Commit-ID: HyRVFvMBNek
650454c3cc35181a8ed0cc59a633bac3743018ec: Bug 1427184 - devtools-reps v0.18.0: update reps bundle from GitHub;r=Honza.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Thu, 04 Jan 2018 09:02:55 +0100 - rev 397752
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1427184 - devtools-reps v0.18.0: update reps bundle from GitHub;r=Honza. MozReview-Commit-ID: 86gvJSI7grM
209dc71353056afed81100cfb84047bef2f3b535: Bug 1426194 - Part 2: Add test. r=pbro
Daisuke Akatsuka <dakatsuka@mozilla.com> - Fri, 22 Dec 2017 00:49:18 +0900 - rev 397751
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1426194 - Part 2: Add test. r=pbro MozReview-Commit-ID: 9A0hRjiYGTE
1230c90d4d9945f2d9edf304ad876424f8ed1cbb: Bug 1426194 - Part 1: Correspond to the keyframes which have same offset. r=pbro
Daisuke Akatsuka <dakatsuka@mozilla.com> - Fri, 22 Dec 2017 00:49:10 +0900 - rev 397750
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1426194 - Part 1: Correspond to the keyframes which have same offset. r=pbro The problem with this bug was that it did not correspond to animations that have multiple keyframes with the same offset. In summary graph, although we were changing the resolution for the graph creation by the distance of offset between keyframes, as the calculation of resolution between keyframes with equivalent offset was infinite, generation was not completed and it was in a state of freezing. In here, in case of zero distance of offsets, we make avoiding to affect to changing the resolution. In addition, the detail graph did not display correctly. For example, there is an animation below. div.animate( [ { offset: 0, opacity: 1, }, { offset: 0.5, opacity: 0.5, }, { offset: 0.5, opacity: 0.1, }, { offset: 1, opacity: 1, }, ], 1000 ); In this animation, opacity changes from 1 to 0.5 during 0 - 499ms, from 0.1 to 1 after 500ms. So, opacity at offset 0.5 behaves 0.5 during 0 - 499ms, 0.1 after 500ms. Since current animation inspector creates the graph with computed value of the time of offset, the opacity of offset 0.5 always is 0.1 in the example, was not correct. As a solution, same to the actual animation work, create the graph between each keyframes with range that from start keyframe offset time to just before the time of end keyframe offset time. Also, in same offsets, connects between just before the time of the offset time and the offset time. So, in the example, we separate as below, then calculate the each coordinates, then combine as graph shape. 1: 0 ~ 499.999ms 2: 499.999 ~ 500ms (same offsets) 3: 500 ~ 999.999ms 4: 1000ms MozReview-Commit-ID: p4Cn2N9iFt
b5679bcdadf8f9538b4e431df0031d601378d1a7: Bug 1352133 - Handle selected tab not yet existing when exiting BrowserSearch. r=nechen
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 28 Dec 2017 15:29:24 +0100 - rev 397749
Push 33190 by apavel@mozilla.com at Thu, 04 Jan 2018 21:27:29 +0000
Bug 1352133 - Handle selected tab not yet existing when exiting BrowserSearch. r=nechen Early during startup there might not be a selected tab yet, so we can't use its data to decide which home panel to show again. Fortunately showHomePager can be called with a null panelId, in which case it will eventually simply fall back to using the default home panel from our settings. MozReview-Commit-ID: GbmozJeYZVb
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip