d3fd96af0ca264b2637b88107420070ea9400700: Bug 1494162 - Part 19: Directly import getCssPath, getXpath and findCssSelector. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Sat, 29 Sep 2018 15:25:34 -0400 - rev 497361
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1494162 - Part 19: Directly import getCssPath, getXpath and findCssSelector. r=pbro
f1dcdcc1674b19b6384f7354c4ac8a0f6896a1e5: Bug 1494898. Re-generate FFI header
Jeff Muizelaar <jmuizelaar@mozilla.com> - Sat, 29 Sep 2018 14:19:32 -0400 - rev 497360
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1494898. Re-generate FFI header
85ee60997e57b500bff9f2588837d3ee6df01f82: Bug 1494836. Replace NormalizedRect for visible area. r=mstange
Jeff Muizelaar <jmuizelaar@mozilla.com> - Wed, 26 Sep 2018 10:32:41 -0400 - rev 497359
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1494836. Replace NormalizedRect for visible area. r=mstange Differential Revision: https://phabricator.services.mozilla.com/D7189
ab5269bd3c218e44e98c31edee99cdd185d0beda: Bug 1494898. Update webrender to commit d7a6d081384ce0da9dd359b0cf4b9f758aab1b67
Jeff Muizelaar <jmuizelaar@mozilla.com> - Sat, 29 Sep 2018 14:19:27 -0400 - rev 497358
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1494898. Update webrender to commit d7a6d081384ce0da9dd359b0cf4b9f758aab1b67
c3d7f8a2a6d4febb937ef7ee6ee79f3b96fed55c: Backed out changeset 7652cf6fa0e4 (bug 1492663) for static analysis bustage
Coroiu Cristina <ccoroiu@mozilla.com> - Sun, 30 Sep 2018 10:09:19 +0300 - rev 497357
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Backed out changeset 7652cf6fa0e4 (bug 1492663) for static analysis bustage
570fdc8386296f3f6f5c008800b978aeacf7a17a: Bug 1488381 - Use target.getFront to instantiate WebExtensionInspectedWindowFront; r=ochameau
yulia <ystartsev@mozilla.com> - Fri, 28 Sep 2018 17:52:26 +0000 - rev 497356
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1488381 - Use target.getFront to instantiate WebExtensionInspectedWindowFront; r=ochameau Depends on D6768 Differential Revision: https://phabricator.services.mozilla.com/D7063
2d9900b114f1fce25926a83638c5946efdca3e4c: Bug 1488373 - Use target.getFront to instantiate StyleSheetsFront; r=ochameau
yulia <ystartsev@mozilla.com> - Thu, 27 Sep 2018 15:44:54 +0000 - rev 497355
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1488373 - Use target.getFront to instantiate StyleSheetsFront; r=ochameau Depends on D6768 Differential Revision: https://phabricator.services.mozilla.com/D7093
7bc2e38aea7b83b6f54f4c213c42590efd4c0102: Bug 1488370 - Use target.getFront to instantiate WebGLFront; r=ochameau
yulia <ystartsev@mozilla.com> - Fri, 28 Sep 2018 18:04:29 +0000 - rev 497354
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1488370 - Use target.getFront to instantiate WebGLFront; r=ochameau Differential Revision: https://phabricator.services.mozilla.com/D7094
a0f61a924be6eafa5c3634adcb57acbf38c3a93a: Bug 1488374 - Use target.getFront to instantiate StorageFront; r=ochameau
yulia <ystartsev@mozilla.com> - Sun, 30 Sep 2018 06:55:23 +0000 - rev 497353
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1488374 - Use target.getFront to instantiate StorageFront; r=ochameau Depends on D7061 Differential Revision: https://phabricator.services.mozilla.com/D7062
7652cf6fa0e426bd4c8fa949aa67b10d1395778b: Bug 1492663 - Upgrade most CI builds to clang 7 r=froydnj
Mike Hommey <mh+mozilla@glandium.org> - Thu, 27 Sep 2018 15:33:42 +0000 - rev 497352
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1492663 - Upgrade most CI builds to clang 7 r=froydnj The cctools-port linker links against libraries from clang (for LTO), which have different SONAMEs depending on the clang version. Which means the linker needs to be used along the same version of clang it was built against. Thus we also make it depend on linux64-clang-7. But changing the dependency is not enough, cf. bug 1471905, so also touch its build script, which it turns out, we need to do anyways because llvm-dsymutil was renamed to dsymutil. Relatedly, all toolchains that are built using cctools-port need to use linux64-clang-7 too. Building compiler-rt 7 with the OSX 10.11 SDK fails because of some newer APIs being used in compiler-rt for xray, but this is not a feature we use, so disable that. Differential Revision: https://phabricator.services.mozilla.com/D6766
ace8fc8c112ec192ae853157875f1be6ea43a755: Bug 1494308 - Use consistent logger in wpt commands r=ato
James Graham <james@hoppipolla.co.uk> - Sat, 29 Sep 2018 14:51:44 +0000 - rev 497351
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1494308 - Use consistent logger in wpt commands r=ato Before we were using a different logger for the manifest download and the actual test run. This caused timestamps to get reset in a confusing way. Now create the logger early and share it for all the subseteps. Depends on D7171 Differential Revision: https://phabricator.services.mozilla.com/D7172
70f1b33a2dacf7798be831b35d0dec474ea5b067: Bug 1494960 - Remove wpt-reduce mach command r=ato
James Graham <james@hoppipolla.co.uk> - Sat, 29 Sep 2018 14:49:25 +0000 - rev 497350
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1494960 - Remove wpt-reduce mach command r=ato As far as I know this was unused and hasn't been well maintained since it's not that useful. Differential Revision: https://phabricator.services.mozilla.com/D7171
e540269f91e25d1735c619facf0af77115a8abb9: Merge mozilla-central to autoland. a=merge CLOSED TREE
Bogdan Tara <btara@mozilla.com> - Sun, 30 Sep 2018 00:59:24 +0300 - rev 497349
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Merge mozilla-central to autoland. a=merge CLOSED TREE
b96cec26d463643b2dc0347930cf2561bfcb0071: Bug 1491907 - Get comm/ version from comm/mail/*version.txt r=dustin
Rob Lemley <rob@thunderbird.net> - Sat, 29 Sep 2018 20:53:10 +0000 - rev 497348
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1491907 - Get comm/ version from comm/mail/*version.txt r=dustin The release-update-verify-config task requires that the versions passed to it match up with what's been released. The version of Thunderbird does not necessarily match the Gecko version it's based on. Depends on D6509 Differential Revision: https://phabricator.services.mozilla.com/D6510
f9cf6e98fc4bbaebf12fe6c101adc6f7ff8702c7: Bug 1491907 - Set correct branch URL for Thunderbird based on product-details r=bhearsum
Rob Lemley <rob@thunderbird.net> - Mon, 24 Sep 2018 08:21:17 +0000 - rev 497347
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1491907 - Set correct branch URL for Thunderbird based on product-details r=bhearsum Thunderbird releases come from the comm-esr.* repositories rather than the comm-release repository. This adds a special case for Thunderbird and sets the branch URL correctly. This initial patch is based on the branch_prefix (comm or mozilla). Differential Revision: https://phabricator.services.mozilla.com/D6509
5688a792346d144f2f7a2ac511d8f0d84dc217c6: Backed out 5 changesets (bug 1428670, bug 1380830) for perma failing tests/layout/generic/crashtests/742602.html
Bogdan Tara <btara@mozilla.com> - Sat, 29 Sep 2018 23:51:23 +0300 - rev 497346
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Backed out 5 changesets (bug 1428670, bug 1380830) for perma failing tests/layout/generic/crashtests/742602.html Backed out changeset f38ac02fefac (bug 1380830) Backed out changeset 1bf6b5fac1f9 (bug 1428670) Backed out changeset faec1cb8ab5d (bug 1428670) Backed out changeset 34736c8507e6 (bug 1428670) Backed out changeset 6ecb75be4a61 (bug 1428670)
f38ac02fefacf6c79e945a25db824b40267a2542: Bug 1380830 - Enable container-with-clamping reftest again. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 29 Sep 2018 15:55:22 +0000 - rev 497345
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1380830 - Enable container-with-clamping reftest again. r=dbaron Judging from the description in comment 3 and the fact that this test started failing shortly after bug 1308876 landed, it is highly likely that this test is being hit by the same issue as bug 1428670. This also makes sense given that this test is supposed to test the clamping of the effective container width for font inflation by the actually visible area of that frame - be that the viewport for a top level document as in bug 1428670, or the width of an <iframe> as in this test. Without the patches for bug 1428670, this test is still failing very frequently. With those patches applied on the other hand, no more failures are encountered. Differential Revision: https://phabricator.services.mozilla.com/D5580
1bf6b5fac1f9cc439338777531bbf9c50fc5656a: Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 29 Sep 2018 15:55:21 +0000 - rev 497344
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron When one of the two factors governing the effective container width for font inflation changes, we need to mark all affected frames as dirty. While the visible area commonly changes because of viewport changes and we can catch those through the check for ISize resizes of the top-level frame ("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation of the effective container width into the FontInflationData itself, especially since the effective container width calculation in nsLayoutUtils is the only consumer of the NCAISize currently stored by the FontInflationData. That way - we can be sure that really all changes of the visible width will correctly mark all affected frames as dirty - can avoid repeatedly recalculating the effective container width - can also detect the cases where the effective container width actually remains the same after a change in one of its input factors and skip forcing a full dirty reflow for all descendants just because of font inflation. While the code in nsLayoutUtils was technically always using the writing direction of each individual frame for determining which dimension of the visible size should be used for clamping, just using the writing direction of the respective flow root should be enough, since each change in writing direction should create a new flow root. This assumption should already hold today because 1. as per the Writing Modes CSS spec, a change in writing mode compared to its parent means that the affected block cannot be purely "inline", but at most "inline-block". 2. Generally, any non-inline frame will be marked as a font inflation container. 3. Any block frame whose writing direction doesn't match its parent will be a block formatting context, which implies NS_BLOCK_FLOAT_MGR. 4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation container will also become a font inflation flow root. but because this chain of reasoning is not the most direct, we also add a corresponding assertion to better catch any potential bugs here. Differential Revision: https://phabricator.services.mozilla.com/D5578
faec1cb8ab5d14e4cc056d179859f6dae1606be0: Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 29 Sep 2018 15:55:14 +0000 - rev 497343
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron Before bug 1308876, child frames marked themselves as dirty during reflow if their parent was dirty, too. After bug 1308876, the point where dirtiness is being propagated to a frame's descendants has been shifted: Now, dirty parents are responsible for marking all their children as dirty, too, when the parent starts reflowing. This means that if a frame wants to mark a whole subtree as dirty *during its own* reflow, it's no longer sufficient to just mark the root of the subtree as dirty and then rely on all further children marking themselves as dirty as well when reflow reaches them. The font inflation code is one such case. When the font inflation data on a font inflation flow root has become dirty, or we're resizing the top-level frame (which because of the effective container width clamping from bug 707855 can affect the font inflation font size as well), we now need to explicitly mark all affected children as dirty. Differential Revision: https://phabricator.services.mozilla.com/D5577
34736c8507e625bfc1d792e14a6fbaf62b9fceb7: Bug 1428670 - Part 1: Add reftest. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 29 Sep 2018 15:54:59 +0000 - rev 497342
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1428670 - Part 1: Add reftest. r=dbaron The failure mode this test is testing is the following: Apart from the relevant preferences (which cannot change without reloading the page, so they're not relevant in this case), the magnitude of font size inflation for all content governed by a particular font inflation flow root depends on the flow root's effective container width, which is calculated by taking the smaller of the following two values: - The font inflation flow root's calculated NCAIsize. - The ISize of the PresContext's currently visible area. Minimum font size for font inflation then scales linearly with the effective container width. While for a plain document without frames, the visible area normally corresponds to the viewport size, the MobileViewportManager will only calculate the viewport after the "load" event or the first paint, whichever is sooner. This means that the initial reflow will proceed using the current window dimensions (on mobile this is corresponding to the display size) for the currently visible area, which in portrait mode typically means around 300 - 500 px width. After the MVM has done its viewport calculations, we'll reflow again using the new viewport size as our visible area. For non-mobile friendly pages where font inflation is relevant, the standard viewport width is 980 px. If a font inflation flow root is wider than the initial window size, this means that its effective container width is governed by the visible area and will therefore increase during the second reflow, as will correspondingly font inflation's minimum font size. While the font inflation code detects changes in a font inflation flow root's NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug 1308876 it no longer correctly marks all descendants of the affected flow root as dirty. If the text is contained inside an element with a fixed width, which has therefore been unaffected by the viewport width change, this means that we'll skip reflow for that text entirely, so the text gets rendered at the new, increased font size, but continues using the old layout laid out assuming the smaller initial font size. I didn't manage to force the visible area to be larger than the initial window size of 800 px using meta viewport tags, so I'm adjusting browser.viewport. desktopWidth for this test instead. This also more closely mimics the real-life failure case described above, where the viewport width gets set to a value larger than the initial window size through the special desktop page viewport width handling. Differential Revision: https://phabricator.services.mozilla.com/D5579
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip