b65bdac64411583c6514278ded031132933eca51: Bug 1412497 - fix test for buffered input stream. r=baku
Jorg K <jorgk@jorgk.com> - Sun, 29 Oct 2017 08:59:26 +0100 - rev 439676
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1412497 - fix test for buffered input stream. r=baku
56279ee0401990417fa4f19f47000850934e3846: Bug 1163171 - part 9.1 - attempt to pacify flake8 complaints for real; r=me
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 18:58:59 -0400 - rev 439675
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 9.1 - attempt to pacify flake8 complaints for real; r=me
f89b4a42ac3cd40633f83af92a00c15fe4f6b6df: Bug 1380014. Fix up the webrender bindings. r=kats
Jeff Muizelaar <jmuizelaar@mozilla.com> - Sat, 28 Oct 2017 18:32:24 -0400 - rev 439674
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1380014. Fix up the webrender bindings. r=kats The earlier patches in this bug were written before we had sophisticated binding generation so the types didn't match very well. This fixes all of that. MozReview-Commit-ID: DpcblpB8vxW
4aa8283cbeaa83cbf18461eaee8b9e6f0de8b7bd: merge mozilla-central to mozilla-inbound. r=merge a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Sun, 29 Oct 2017 00:23:03 +0200 - rev 439673
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
merge mozilla-central to mozilla-inbound. r=merge a=merge
4f85969fa24a040b34842cc22baaefc1bdb5bc3f: Bug 1163171 - part 9 - fix flake8 complains in android-ndk.configure. r=me
Sebastian Hengst <archaeopteryx@coole-files.de> - Sun, 29 Oct 2017 00:08:13 +0200 - rev 439672
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 9 - fix flake8 complains in android-ndk.configure. r=me
babd400c828aee19ce9416296a1d32deaee3a49a: Bug 1163171 - part 8 - touch CLOBBER because we're changing compilers; r=me
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:58 -0400 - rev 439671
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 8 - touch CLOBBER because we're changing compilers; r=me
6afa42ff81ef94ca5f13040797c19c6f287e4e3a: Bug 1163171 - part 7 - mark counter tests as passing now that we use clang; r=dholbert
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:58 -0400 - rev 439670
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 7 - mark counter tests as passing now that we use clang; r=dholbert These tests were failing because of some misoptimizations that GCC did. clang is generating correct code here, and the tests correctly pass, so we can mark them as such.
28f3d894a0dc3fb1ab132db30d8740ba8a3e67b8: Bug 1163171 - part 6 - update to NDK r15c; r=snorp
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:58 -0400 - rev 439669
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 6 - update to NDK r15c; r=snorp
2a03305f96d7dee83ce28b5768848bf22697e445: Bug 1163171 - part 4 - fix jsapi-tests link errors with __atomic_* intrinsics on x86/Android with clang; r=glandium
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:58 -0400 - rev 439668
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 4 - fix jsapi-tests link errors with __atomic_* intrinsics on x86/Android with clang; r=glandium NDK r15+ clang changed the code generation strategy for the __atomic_* intrinics such that using them with 64-bit types now requires linking with libatomic. Our current configure tests for libatomic doesn't catch this, because the std::atomic implementation is such that it doesn't require an external library, even for 64-bit types, whereas the __atomic_* intrinsics do. The safest thing to do is to force this configure check to always return true when we are compiling for x86/Android with clang.
5c33bd0a9c36aa7e551da81c652e81b33d0f0617: Bug 1163171 - part 3b - inform clang about the NDK's gcc toolchain; r=glandium
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:59 -0400 - rev 439667
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 3b - inform clang about the NDK's gcc toolchain; r=glandium The NDK clang needs to be informed about the existence of a GCC toolchain, so important programs like the linker can be located. With this change, we're starting to use command-line options that are incompatible with GCC, so we also add a check to inform the user about the non-support for this configuration.
b3f95a78cca8bfd4c92927087948a9c3d90558ff: Bug 1163171 - part 3a - expose the NDK clang binaries to toolchain configury; r=glandium
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:59 -0400 - rev 439666
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 3a - expose the NDK clang binaries to toolchain configury; r=glandium Our normal method of locating the compilers in the NDK is to set --with-toolchain-prefix when compiling for Android. However, the clang binaries are in a different location than would otherwise be implied by --with-toolchain-prefix. Additionally, we still need to know about --with-toolchain-prefix because the NDK clang needs to be pointed there so clang can find important binaries like the linker and because various other bits of the build system depend on the --with-toolchain-prefix value as well. So we need a separate mechanism for communicating the whereabouts of the NDK clang. We can't set CC and CXX because doing so would conflict with the CC and CXX values exported to the js/src/ subconfigure. But Android already has an extra_toolchain_flags function that we use for informing moz.configure about additional flags needed solely for Android, and we can use a similar trick to communicate the existence of the NDK's clang to the main C/C++ compiler selection process.
9f81a968a2584817c8e4738517c498050a2ec296: Bug 1163171 - part 2 - switch to using -isystem rather than -idirafter for Android; r=glandium
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:59 -0400 - rev 439665
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 2 - switch to using -isystem rather than -idirafter for Android; r=glandium This command-line flag is a little more evocative and works correctly with both GCC and clang.
1f074437df8b47cb6d66a390eb5d6a267b89750c: Bug 1163171 - part 1 - switch to r11c NDKs that include clang; r=snorp
Nathan Froyd <froydnj@mozilla.com> - Sat, 28 Oct 2017 17:38:59 -0400 - rev 439664
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1163171 - part 1 - switch to r11c NDKs that include clang; r=snorp The first thing to do to make Fennec compile with clang is to use NDK tarballs that actually include LLVM.
09cdea082e9abee362b89d8ab6ca9c8b282583d8: merge autoland to mozilla-central. r=merge a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Sun, 29 Oct 2017 22:50:47 +0100 - rev 439663
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
merge autoland to mozilla-central. r=merge a=merge MozReview-Commit-ID: AgOQA5cp8C2
9089083929039ac0dddc5707525b73e9922edef8: Bug 1411879 - Use kPMDataFormatXMLCompressed parameter into PMPageFormatCreateDataRepresentation(). r=mstange
Mantaroh Yoshinaga <mantaroh@gmail.com> - Thu, 26 Oct 2017 17:36:16 +0900 - rev 439662
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 1411879 - Use kPMDataFormatXMLCompressed parameter into PMPageFormatCreateDataRepresentation(). r=mstange We can use kPMDataFormatXMLCompressed parameter when storing the page format data. As result, this preference data will be 20 times smaller. MozReview-Commit-ID: HMQzhodQyA
2b51a6cf8f4c25baa87d90e98646868615e8273d: Bug 748315 - Part 5. Update browserscope test result. r=masayuki
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 25 Oct 2017 16:13:10 +0900 - rev 439661
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 748315 - Part 5. Update browserscope test result. r=masayuki MozReview-Commit-ID: KIC7OcDe2i6
73804363647e1483b0e4851e08c9f167ec874b51: Bug 748315 - Part 4. Update web-platform-tests result. r=masayuki
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 25 Oct 2017 16:13:10 +0900 - rev 439660
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 748315 - Part 4. Update web-platform-tests result. r=masayuki By this changes, many queryCommandValue("justify*") return correct value. But since we don't support mixed state of queryCommandState("justify*") (Bug 1412167), when queryCommandValue returns correct value, queryCommandState will return incorrectly value instead. MozReview-Commit-ID: S6IAK8xdW2
5904a51460e29fd74cebb8b92d2b7515ef452325: Bug 748315 - Part 3. Use SetAttributeOrEquivalent even if HTMLEditor::IsCSSEnabled() is false. r=masayuki
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Sun, 29 Oct 2017 23:05:16 +0900 - rev 439659
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 748315 - Part 3. Use SetAttributeOrEquivalent even if HTMLEditor::IsCSSEnabled() is false. r=masayuki SetAttributeOrEquivalent can remove CSS property that is same behaviour by part 2. So we should use it instead of SetAttribute. MozReview-Commit-ID: InCZQVdbDRm
f5d83a9ca1b0063d1f73a164acd76c62d80a1039: Bug 748315 - Part 2. SetAttributeOrEquivalent should remove CSS property when HTMLEditor::IsCSSEnabled() is false. r=masayuki
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 25 Oct 2017 16:13:09 +0900 - rev 439658
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 748315 - Part 2. SetAttributeOrEquivalent should remove CSS property when HTMLEditor::IsCSSEnabled() is false. r=masayuki SetAttributeOrEquivalent sets element's attribute when HTMLEditor::IsCSSEnabled() is false. It should remove the CSS property that is same behaviour too. MozReview-Commit-ID: ChKjlB7wI0Z
68e52184e9010b663378c801eb1e8858dcb47ef8: Bug 748315 - Part 1. Consider text-align property even if HTMLEditor::IsCSSEnabled() is false. r=masayuki
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 25 Oct 2017 16:13:02 +0900 - rev 439657
Push 8114 by jlorenzo@mozilla.com at Thu, 02 Nov 2017 16:33:21 +0000
Bug 748315 - Part 1. Consider text-align property even if HTMLEditor::IsCSSEnabled() is false. r=masayuki Actually, we don't consider CSS property to get alignment when IsCSSEnabled() is false. For WebKit and Blink compatibility, we should consider this situation. MozReview-Commit-ID: 9ORntUmbIbf
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip