c525a24dffc34f710b52dfcb949fcafeb3f6bac6: Merge mozilla-inbound to mozilla-central a=merge
Razvan Maries <rmaries@mozilla.com> - Fri, 15 Mar 2019 05:40:21 +0200 - rev 522012
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Merge mozilla-inbound to mozilla-central a=merge
f3500b0a2f3bbce27476b4602d1e7be26524d909: Bug 1534847 - Part 3: Pass originalText load failure through to UI instead of failing silently. r=jlast
Logan Smyth <loganfsmyth@gmail.com> - Thu, 14 Mar 2019 16:15:21 -0400 - rev 522011
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1534847 - Part 3: Pass originalText load failure through to UI instead of failing silently. r=jlast Summary: Returning null here leaves us in an infinite loading state because null is treated as neither success nor failure. Reviewers: jlast Bug #: 1534847 Differential Revision: https://phabricator.services.mozilla.com/D23453
35af4e6b563343968f5556c7aebdabc929553c1d: Bug 1534847 - Part 2: Invalidate the loadSourceText cache on navigation. r=jlast
Logan Smyth <loganfsmyth@gmail.com> - Thu, 14 Mar 2019 14:35:30 -0400 - rev 522010
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1534847 - Part 2: Invalidate the loadSourceText cache on navigation. r=jlast Summary: If users navigate while source text is loading, we need to ignore existing cached promises because they may resolve and then not actually set the resulting source, because the source was deleted from the source list. We want to explicitly use a new cache entry if we have navigated. Reviewers: jlast Bug #: 1534847 Differential Revision: https://phabricator.services.mozilla.com/D23452
3befa22661a8cbab7b30f337fb3b42fbcb30fcdd: Bug 1534847 - Part 1: Refactor loadSourceText to separate caching from logic. r=jlast
Logan Smyth <loganfsmyth@gmail.com> - Thu, 14 Mar 2019 14:34:59 -0400 - rev 522009
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1534847 - Part 1: Refactor loadSourceText to separate caching from logic. r=jlast Summary: Splitting up this logic makes us less likely to introduce code that would break the caching behavior. If you look closely at these changes, you'll notice that there actually one one early return in this code that would cause us to exit without clearing the 'requests' cache meaning we could get stuck in an infinite loading state. Reviewers: jlast Reviewed By: jlast Bug #: 1534847 Differential Revision: https://phabricator.services.mozilla.com/D23451
afd8d968a200f3b8de05f4e626fee206cb67e154: Merge mozilla-central to mozilla-inbound. a=merge on a CLOSED TREE
Razvan Maries <rmaries@mozilla.com> - Thu, 14 Mar 2019 23:50:44 +0200 - rev 522008
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Merge mozilla-central to mozilla-inbound. a=merge on a CLOSED TREE
d57a9605a6d156801d07b6572e362a90b2b13bb5: Bug 1523175 - land NSS NSS_3_43_BETA3 UPGRADE_NSS_RELEASE, r=me
J.C. Jones <jc@mozilla.com> - Thu, 14 Mar 2019 21:05:01 +0000 - rev 522007
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1523175 - land NSS NSS_3_43_BETA3 UPGRADE_NSS_RELEASE, r=me
14e0efdd3d9cfb4ea23276a7d237847a8e6f0c75: Bug 1525662 - Part 6: Turn on word wrapping by default for plain text documents on mobile. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 10 Feb 2019 14:28:35 +0100 - rev 522006
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1525662 - Part 6: Turn on word wrapping by default for plain text documents on mobile. r=snorp Differential Revision: https://phabricator.services.mozilla.com/D19308
7634907d87d06d8cce3d223f3d85d9a2d3c86393: Bug 1525662 - Part 5: Use smaller image for Geckoview tests. r=snorp
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 11 Mar 2019 20:18:54 +0100 - rev 522005
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1525662 - Part 5: Use smaller image for Geckoview tests. r=snorp The animation is cute, but one test is effectively treating the image data as a text file, and displaying the whole file as text leads to *very* long loading times on the ARM emulator when word-wrapping is turned on, especially when using a debug build. Differential Revision: https://phabricator.services.mozilla.com/D23367
60e8006f70d2ebf9c52a397bf916924bc7c0a646: Bug 1525662 - Part 4: Use "width=device-width" viewport for plain text documents. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 24 Feb 2019 17:32:08 +0100 - rev 522004
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1525662 - Part 4: Use "width=device-width" viewport for plain text documents. r=botond Differential Revision: https://phabricator.services.mozilla.com/D20954
7b61f5d7f7d26ad493ee940fdf8a6f62f70a59b5: Bug 1525662 - Part 3: Provide a hook for treating missing viewport specification as an explicit "width=device-width". r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 24 Feb 2019 14:55:02 +0100 - rev 522003
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1525662 - Part 3: Provide a hook for treating missing viewport specification as an explicit "width=device-width". r=botond Ordinarily, when a page doesn't explicitly specify its viewport dimensions using a <meta> viewport tag, we treat is as a non-mobile-friendly desktop page and do some special viewport handling. For some document types however we might want to override that behaviour and treat the page as if "<meta name="viewport" content="width=device-width>" had explicitly been specified anyway. Differential Revision: https://phabricator.services.mozilla.com/D20953
dc422efc31037bbf666a830bfa02c157612c9bbb: Bug 1525662 - Part 2: Remember plain-textness of HTML documents post loading. r=hsivonen
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 23 Feb 2019 17:06:52 +0100 - rev 522002
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1525662 - Part 2: Remember plain-textness of HTML documents post loading. r=hsivonen Based on the current implementation of nsContentUtils::IsPlainTextType(), we could just call that function again if we need to know whether we're dealing with plain text content or not later on, but doing it this way ensures we're always consistent with the current code in StartDocumentLoad(), which includes some additional sanity checks. Differential Revision: https://phabricator.services.mozilla.com/D20952
65a5625c479045150d7990b93a64b9a5e00ffb82: Bug 1525662 - Part 1: Add test for viewport treatment of plain text documents. r=botond
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 24 Feb 2019 19:55:32 +0100 - rev 522001
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1525662 - Part 1: Add test for viewport treatment of plain text documents. r=botond I want to turn on word-wrapping for plain text documents on mobile. However currently, these are rendered with the desktop viewport by default, leading to still tiny font sizes and still having to scroll horizontally if you then pinch-zoom in to achieve a readable font size. While font inflation would solve that problem, the layout of plain text documents is so simple that we can also just render them using a "width=device-width" viewport instead. This test will test that plain text documents will be rendered as they would include a <meta name="viewport" content="width=device-width"> tag. Differential Revision: https://phabricator.services.mozilla.com/D20951
355c9ff9b89581cf5b2ff03f3df9df05939f89c3: Bug 1526717. Guard against libpng calling the info callback more than once. r=aosmond
Timothy Nikkel <tnikkel@gmail.com> - Thu, 14 Mar 2019 14:32:37 -0500 - rev 522000
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1526717. Guard against libpng calling the info callback more than once. r=aosmond libpng uses the first IDAT chunk it encounters as a signal that it has read all header chunks and to send the info callback. The testcase png has an IDAT chunk, then a z chunk (not a known chunk type), and then another IDAT chunk. libpng tracks if we are in an "after idat" state, and throws a benign error if it encounters another IDAT chunk in "after idat" mode, but it just continues normally, processing the idat chunk as if it were the first and therefore sends the info callback again. This seems silly. https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/media/libpng/pngpread.c#307
8854d4a1652878c30a85eaf9178771efc8025dee: Bug 1343357 - Ignore lower-priority animateMotion if a to-animation is encountered r=dholbert
violet <violet.bugreport@gmail.com> - Fri, 15 Mar 2019 01:26:13 +0000 - rev 521999
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1343357 - Ignore lower-priority animateMotion if a to-animation is encountered r=dholbert Current impl at SVGMotionSMILType::Interpolate has some wrong assertions, it's probably caused by overlooking the special behavior of to-animation. These assumptions also lead weird animation in the product build. Now we take to-animation into account, and implement similar behavior as Chrome and Safari. Differential Revision: https://phabricator.services.mozilla.com/D23095
a34bdd9a2ebcba3d22436687b0d59d4ed1557ceb: Bug 1535460 - Add dark theme styles, Discovery stream blocking and bug fixes to Activity Stream r=r1cky
k88hudson <k88hudson@gmail.com> - Thu, 14 Mar 2019 22:27:33 +0000 - rev 521998
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1535460 - Add dark theme styles, Discovery stream blocking and bug fixes to Activity Stream r=r1cky Differential Revision: https://phabricator.services.mozilla.com/D23589
76a3b7b0c9d702f9671bcaf07bea8399357b7945: Bug 1451104 - part 6 - don't remove the libstdc++ files from the mingw build; r=glandium
Nathan Froyd <froydnj@gmail.com> - Fri, 15 Mar 2019 01:29:33 +0000 - rev 521997
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1451104 - part 6 - don't remove the libstdc++ files from the mingw build; r=glandium History does not disclose why we needed this, but in the brave new GCC 6-compiled world, deleting these files means that host links can no longer find libstdc++, which causes problems. Let's put the files back. Differential Revision: https://phabricator.services.mozilla.com/D22884
858b68d306f2e661a2094a76d6977334de58e52f: Bug 1451104 - part 5 - move toolchains off GCC 4.9; r=glandium
Nathan Froyd <froydnj@gmail.com> - Fri, 15 Mar 2019 01:29:23 +0000 - rev 521996
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1451104 - part 5 - move toolchains off GCC 4.9; r=glandium Firefox itself has moved on to GCC 6.x; we can move our toolchains along too. Differential Revision: https://phabricator.services.mozilla.com/D22883
292ed1bb9143e7853110e9a7574c168ae3780932: Bug 1451104 - part 4 - sync up gcc-related toolchains and linux64-binutils binutils version; r=glandium
Nathan Froyd <froydnj@mozilla.com> - Fri, 15 Mar 2019 01:29:14 +0000 - rev 521995
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1451104 - part 4 - sync up gcc-related toolchains and linux64-binutils binutils version; r=glandium We're going to copy an x86_64-unknown-linux-gnu ld into the clang build, which clang will then use in preference to things on PATH. We therefore need to ensure that this ld is the same ld as would be used for other builds, such as PGO. This change is the most expedient way to do that; future work will make the gcc job(s) depend on linux64-binutils directly. Differential Revision: https://phabricator.services.mozilla.com/D22882
f3290e95b38d23973b31b5bcb8d811fe253cedbc: Bug 1451104 - part 3 - inform stage2/3 clang about gcc binutils; r=glandium
Nathan Froyd <froydnj@gmail.com> - Fri, 15 Mar 2019 01:29:04 +0000 - rev 521994
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1451104 - part 3 - inform stage2/3 clang about gcc binutils; r=glandium We do this to encourage clang to find an new-enough linker instead of the system one. Differential Revision: https://phabricator.services.mozilla.com/D22881
961ac7318786c56eeb21975fb77eb97ef790c51b: Bug 1451104 - part 2 - force clang to always pick up its local GCC headers and libraries; r=glandium
Nathan Froyd <froydnj@gmail.com> - Fri, 15 Mar 2019 01:28:55 +0000 - rev 521993
Push 10870 by nbeleuzu@mozilla.com at Fri, 15 Mar 2019 20:00:07 +0000
Bug 1451104 - part 2 - force clang to always pick up its local GCC headers and libraries; r=glandium We want our clang bootstrap to use the GCC headers we're building with, not whatever sysroot it happens to find on the server we're building on. The -gcc-toolchain argument we specify when building clang will also be picked up by llvm-config, so we need to strip it out when building the plugin. Otherwise, we will get peculiar failures about not being able to find C++ header files. Differential Revision: https://phabricator.services.mozilla.com/D22880
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip