searching for reviewer(dbaron)
2dd8df3604ef: Bug 1499863 - Honor will-change: position dynamic changes. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 17 Oct 2018 22:13:51 +0000 - rev 497609
Push 9996 by archaeopteryx@coole-files.de at 2018-10-18 18:37 +0000
Bug 1499863 - Honor will-change: position dynamic changes. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D9032
9d43c4ab83a5: Bug 1498067 - Add event markers for WipeContainingBlock and other expensive paths in the frame constructor. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 11 Oct 2018 01:22:05 +0000 - rev 496436
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1498067 - Add event markers for WipeContainingBlock and other expensive paths in the frame constructor. r=dbaron I removed the debug-only printf spew because I think this is superior. Let me know if you want to keep it around. See https://bugzilla.mozilla.org/show_bug.cgi?id=1496817#c8, this needs a fix to the profiler UI which is still not deployed, but can be tested already and I expect will be deployed soon. Differential Revision: https://phabricator.services.mozilla.com/D8323
2247311dfb80: Bug 1496014 - Fix shape-outside invalidation. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 04 Oct 2018 19:41:22 +0200 - rev 496095
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1496014 - Fix shape-outside invalidation. r=dbaron It's not really invalidated anywhere, and the float manager code only checks for float region changes. Extend it so that it knows about shapes as well, and avoid reframing due to a bogus nsChangeHint_ScrollbarChange which really meant to be UpdateOverflow, which really is useless in this situation.. Differential Revision: https://phabricator.services.mozilla.com/D7583
3b597edf0a98: Bug 1495470: Only let 'contain:layout/paint' create stacking contexts on frames that support it. r=dbaron
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 09 Oct 2018 21:04:03 +0000 - rev 496083
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1495470: Only let 'contain:layout/paint' create stacking contexts on frames that support it. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D7926
2f3ac50f1ce9: Bug 1496275 - Fix wpt test multicol-span-all-margin-bottom-001-ref.xht. r=dbaron
Ting-Yu Lin <tlin@mozilla.com> - Thu, 04 Oct 2018 17:28:52 +0000 - rev 495384
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1496275 - Fix wpt test multicol-span-all-margin-bottom-001-ref.xht. r=dbaron Per example in the spec https://drafts.csswg.org/css-multicol-1/#column-span ... the bottom margin of the second spanner does not collapse with the top margin of the subsequent element. Likewise, in the test file multicol-span-all-margin-bottom-001.xht, the bottom margin of the black spanner <h4> should not collapse with the top margin of the orange non-spanner <h4>. Differential Revision: https://phabricator.services.mozilla.com/D7670
427b3c0f8add: Bug 1495875 - Fix width of black <img> in multicol-span-none-001-ref.xht. r=dbaron
Ting-Yu Lin <aethanyc@gmail.com> - Tue, 02 Oct 2018 23:35:20 +0000 - rev 495042
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1495875 - Fix width of black <img> in multicol-span-none-001-ref.xht. r=dbaron <h4>'s in the test file (multicol-span-none-001-ref.xht) should not be clipped according to the spec [1]. Fix the width of the reference black <img>. 260 = 20 (a chararcter's width) * 13 [1] https://drafts.csswg.org/css-multicol-1/#overflow Differential Revision: https://phabricator.services.mozilla.com/D7539
ec51b039eef1: Bug 1380830 - Enable container-with-clamping reftest again. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:19 +0000 - rev 494924
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
57e3c8d09ace: Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:17 +0000 - rev 494923
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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 mode (horizontal/vertical) of each individual frame for determining which dimension of the visible size should be used for clamping, just using the writing mode of the respective flow root should be enough, since each change in the writing mode 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
87971e291470: Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:12 +0000 - rev 494922
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
205758034a6c: Bug 1428670 - Part 1: Add reftest. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:10 +0000 - rev 494921
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
e2eb3d8b408f: Bug 1428670 - Part 0: Fix mixed tabs and spaces. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 02 Oct 2018 15:23:07 +0000 - rev 494920
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1428670 - Part 0: Fix mixed tabs and spaces. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D5576
a080d82d994e: Bug 1495323 - Don't retrieve font size inflation for margin calculation unless really required. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 01 Oct 2018 22:07:57 +0000 - rev 494850
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1495323 - Don't retrieve font size inflation for margin calculation unless really required. r=dbaron Once again, calculating the amount of font size inflation isn't as expensive as it used to be, but there's still no need to do it unnecessarily. The current code does this unconditionally as part of computing a frame's margins Additionally, calculating the font size inflation for frames that we don't actually want to inflate also messes with the planned writing mode assertions from bug 1428670. In some special cases (e.g. the scroll bars), a frame might use a different writing mode (horizontal/vertical) than its parent without creating a new font inflation flow root at the boundary. As long as we never want to apply font size inflation for that frame this is okay, but if the margin computation then runs the font inflation calculation regardless, we have a problem. Differential Revision: https://phabricator.services.mozilla.com/D7329
f38ac02fefac: 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 494633
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
1bf6b5fac1f9: 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 494632
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
faec1cb8ab5d: 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 494631
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
34736c8507e6: Bug 1428670 - Part 1: Add reftest. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 29 Sep 2018 15:54:59 +0000 - rev 494630
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +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
6ecb75be4a61: Bug 1428670 - Part 0: Fix mixed tabs and spaces. r=dbaron
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 29 Sep 2018 15:55:01 +0000 - rev 494629
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1428670 - Part 0: Fix mixed tabs and spaces. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D5576
cf9cd0662126: Bug 1492567 - Back out bug 1481866. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 19 Sep 2018 22:02:01 +0200 - rev 493091
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1492567 - Back out bug 1481866. r=dbaron Summary: The behavior the WG proposed is way more subtle than what that bug implements, including: * Implementing two logical overflow longhands. * Expanding the overflow shorthand to different longhands depending on the syntax of that. Meanwhile, Blink hasn't done the swap and will ship the same behavior that we shipped in Firefox 61 (bug 1453148), that is, overflow-x, then overflow-y. So I think lacking a clear way forward we should revert this change and preserve our shipped behavior. Reviewers: dbaron! Tags: #secure-revision Bug #: 1492567 Differential Revision: https://phabricator.services.mozilla.com/D6317
b0fe36c3965f: Bug 1481098 - Remove Unused aParentContext Parameter in ServoStyleSet::ResolveStyleFor Function r=dbaron
Jean-Luc Bonnafoux <jeanluc.bonnafoux@wanadoo.fr> - Tue, 18 Sep 2018 08:01:36 +0000 - rev 492669
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1481098 - Remove Unused aParentContext Parameter in ServoStyleSet::ResolveStyleFor Function r=dbaron Remove Unused aParentContext Parameter in ServoStyleSet::ResolveStyleFor Function Differential Revision: https://phabricator.services.mozilla.com/D5979
e4990387dd8c: Bug 1491639 - rename function IS_TABLE_CELL r=dbaron
Jean-Luc Bonnafoux <jeanluc.bonnafoux@wanadoo.fr> - Tue, 18 Sep 2018 01:29:19 +0000 - rev 492653
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1491639 - rename function IS_TABLE_CELL r=dbaron rename function IS_TABLE_CELL Differential Revision: https://phabricator.services.mozilla.com/D5974
6ef8cd81d405: Bug 458473 - initialize local variable fType r=dbaron
Jean-Luc Bonnafoux <jeanluc.bonnafoux@wanadoo.fr> - Fri, 14 Sep 2018 22:04:17 +0000 - rev 492271
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 458473 - initialize local variable fType r=dbaron Bug 458473 - initialize local variable fType Differential Revision: https://phabricator.services.mozilla.com/D5387
1ead18010257: Bug 1490575 - wpt: Remove Mulet check from reftest annotation regex. r=dbaron
Chris Peterson <cpeterson@mozilla.com> - Tue, 11 Sep 2018 23:11:36 -0700 - rev 492057
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1490575 - wpt: Remove Mulet check from reftest annotation regex. r=dbaron Remove `;s/ # Initial mulet triage:.*//` from the sed script because no reftests still have "Initial mulet triage" annotations. Mulet was a Firefox OS simulator that is no longer supported: https://wiki.mozilla.org/Mulet URL to this script in the wpt repo: https://github.com/web-platform-tests/wpt/blob/master/css/vendor-imports/mozilla/mozilla-central-reftests/sync-tests.sh Differential Revision: https://phabricator.services.mozilla.com/D5737
c8c95278f139: Bug 1397119 - Part 2: Rename p2t to d2a (app units per device pixel). r=dbaron
Chris Peterson <cpeterson@mozilla.com> - Mon, 10 Sep 2018 19:55:05 +0000 - rev 491336
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1397119 - Part 2: Rename p2t to d2a (app units per device pixel). r=dbaron Bug 895096 comment 0 recommends using the name `d2a` instead of `p2t`. Depends on D5368 Differential Revision: https://phabricator.services.mozilla.com/D5369
6d0f8348cdb6: Bug 1397119 - Part 1: Change nsTable*Frame::Get*BorderWidth() return values from nscoord to BCPixelSize. r=dbaron
Chris Peterson <cpeterson@mozilla.com> - Mon, 10 Sep 2018 19:51:52 +0000 - rev 491334
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1397119 - Part 1: Change nsTable*Frame::Get*BorderWidth() return values from nscoord to BCPixelSize. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D5368
2ffd781dd9a1: Bug 1346983 - Add ColumnSetWrapperFrame to wrap nsColumnSetFrames and column span frames. r=dbaron
Ting-Yu Lin <tlin@mozilla.com> - Thu, 06 Sep 2018 17:58:24 +0000 - rev 490872
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1346983 - Add ColumnSetWrapperFrame to wrap nsColumnSetFrames and column span frames. r=dbaron ColumnSetWrapperFrame is needed to implement column-span. Patches in bug 1421105 will utilize this frame. Co-authored-by: Neerja Pancholi <npancholi@mozilla.com> Differential Revision: https://phabricator.services.mozilla.com/D5092
bc3b69fb4426: Bug 1488684 - Made some layout methods 'final' or non-virtual - r=dbaron
Gerald Squelart <gsquelart@mozilla.com> - Thu, 06 Sep 2018 01:23:49 +0000 - rev 490760
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1488684 - Made some layout methods 'final' or non-virtual - r=dbaron Some methods were not overrides and were never overridden, so they could simply be non-virtual. Others were overrides but were not overridden, so they could benefit from being final to hopefully lead to devirtualized calls. Though some of these are not strictly necessary because they are inside 'final' classes, I think they're worth adding anyway, because: - The 'final' keyword becomes more obvious when looking at methods without the wider context in sight (e.g., in reviews or searchfox). - If one day any of these classes becomes non-final, it would keep the final attribute on these methods by default, and force the programmer to explicitly reflect before removing 'final' from the methods that need to be overridden. Depends on D5020 Differential Revision: https://phabricator.services.mozilla.com/D5021
8aa236bd11b2: Bug 1485581 - Make nsImageFrame report intrinsic inline sizes in the correct dimension (height) when writing-mode is vertical. r=dbaron
張俊芝 <zjz@zjz.name> - Wed, 05 Sep 2018 15:48:56 -0700 - rev 490755
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1485581 - Make nsImageFrame report intrinsic inline sizes in the correct dimension (height) when writing-mode is vertical. r=dbaron
52dabf91acd0: Bug 1488684 - Made nsIFrame-derived classes and some others 'final' where possible - r=dbaron
Gerald Squelart <gsquelart@mozilla.com> - Thu, 06 Sep 2018 01:23:14 +0000 - rev 490728
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1488684 - Made nsIFrame-derived classes and some others 'final' where possible - r=dbaron All classes deriving from nsIFrame that did not have any subclasses themselves (at the time of writing this patch) have been marked with `final`. Some other Layout classes have also been made final, but this was opportunistic while working on nsIFrame subclasses, and is definitely not exhaustive, further patches welcome; refer to bug 1332680. Advantages of marking a class final include: - Allowing the compiler to devirtualize some method calls (i.e., calling virtual functions directly instead of going through the vtable), - Indicating that the class is not currently subclassed, - Preventing subclassing without being aware that this would remove the finalization benefits of the parent class. `final` does not signify that these classes should *never* be subclassed, this is left for developers to decide. Differential Revision: https://phabricator.services.mozilla.com/D5020
2fe00c411c46: Bug 1483659 - Ensure that child overflow areas are included in perspective frame overflow areas r=dbaron
Miko Mynttinen <mikokm@gmail.com> - Tue, 04 Sep 2018 16:25:54 +0000 - rev 490352
Push 9984 by ffxbld-merge at 2018-10-15 21:07 +0000
Bug 1483659 - Ensure that child overflow areas are included in perspective frame overflow areas r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D3515
862f7fc8be9d: Bug 1492567 - Back out bug 1481866. r=dbaron a=pascalc
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 19 Sep 2018 22:02:01 +0200 - rev 489958
Push 9842 by dluca@mozilla.com at 2018-09-20 13:12 +0000
Bug 1492567 - Back out bug 1481866. r=dbaron a=pascalc Summary: The behavior the WG proposed is way more subtle than what that bug implements, including: * Implementing two logical overflow longhands. * Expanding the overflow shorthand to different longhands depending on the syntax of that. Meanwhile, Blink hasn't done the swap and will ship the same behavior that we shipped in Firefox 61 (bug 1453148), that is, overflow-x, then overflow-y. So I think lacking a clear way forward we should revert this change and preserve our shipped behavior. Reviewers: dbaron! Tags: #secure-revision Bug #: 1492567 Differential Revision: https://phabricator.services.mozilla.com/D6317
8614b6f4970a: Bug 1485581 - Make nsImageFrame report intrinsic inline sizes in the correct dimension (height) when writing-mode is vertical. r=dbaron a=pascalc
張俊芝 <zjz@zjz.name> - Wed, 05 Sep 2018 15:48:56 -0700 - rev 489780
Push 9773 by dvarga@mozilla.com at 2018-09-10 11:38 +0000
Bug 1485581 - Make nsImageFrame report intrinsic inline sizes in the correct dimension (height) when writing-mode is vertical. r=dbaron a=pascalc
6932f13cab4b: Bug 1485669: Upstream the tests from bug 488725. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 23 Aug 2018 15:29:01 +0200 - rev 489477
Push 9738 by aciure@mozilla.com at 2018-09-03 16:13 +0000
Bug 1485669: Upstream the tests from bug 488725. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D4076
f6753d3d9db1: Bug 1485669: Upstream the tests from bug 488725. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 23 Aug 2018 15:29:01 +0200 - rev 489473
Push 9738 by aciure@mozilla.com at 2018-09-03 16:13 +0000
Bug 1485669: Upstream the tests from bug 488725. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D4076
7edf18c31ee0: Bug 1486457 - Clear the float list if we weren't able to place a line. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 28 Aug 2018 18:13:20 +0000 - rev 488880
Push 9738 by aciure@mozilla.com at 2018-09-03 16:13 +0000
Bug 1486457 - Clear the float list if we weren't able to place a line. r=dbaron We'll re-do the line anyway, and we'll forget about all the already-positioned floats in the line DoReflowInlineFrames anyway. Differential Revision: https://phabricator.services.mozilla.com/D4457
a4eef4b8a3b0: Bug 488725: Don't position floats in a nowrap context until hitting a break opportunity. r=dbaron
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 21 Aug 2018 16:16:50 +0200 - rev 488171
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 488725: Don't position floats in a nowrap context until hitting a break opportunity. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D3900
975546ce7e13: Bug 1485430 - Simplify PlaceBelowCurrentFloats. r=dbaron,mats
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 22 Aug 2018 23:29:22 +0000 - rev 488122
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1485430 - Simplify PlaceBelowCurrentFloats. r=dbaron,mats No reason to pass our own member as an argument. Differential Revision: https://phabricator.services.mozilla.com/D4000
6c3db80981da: Bug 1481951 part 2: Adjust reftest contain-layout-overflow-002.html to be clearer & have accurate expectations. r=dbaron
Daniel Holbert <dholbert@cs.stanford.edu> - Mon, 20 Aug 2018 12:43:14 -0700 - rev 487643
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1481951 part 2: Adjust reftest contain-layout-overflow-002.html to be clearer & have accurate expectations. r=dbaron This test is basically a copy of its -001 variant, with some "float:left" sprinkled around on contained descendants. Before this patch, this test had an additional arbitrary sizing difference as compared to the -001 version -- there's one element that arbitrarily has class "outer" in the -002 test whereas it has class "inner-lg" in the -001 version. These classes have different sizing characteristics, which makes a difference to whether scrollbars show up, because this element is not contained (though it is a layout container itself). This patch undoes this arbitrary difference and also adds a "float" class to make it easier to see which elements we've sprinkled float styling onto. Differential Revision: https://phabricator.services.mozilla.com/D3826
e47a225b907e: Bug 1481951 part 1: Adjust contain-layout-overflow-* reftests to remove unused rule for nonexistent class "inner-md". r=dbaron
Daniel Holbert <dholbert@cs.stanford.edu> - Mon, 20 Aug 2018 12:45:06 -0700 - rev 487642
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1481951 part 1: Adjust contain-layout-overflow-* reftests to remove unused rule for nonexistent class "inner-md". r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D3825
e0ddd48b0a8f: Bug 1460075 - Use 1px as the minimum column width. r=dbaron
Ting-Yu Lin <tlin@mozilla.com> - Mon, 13 Aug 2018 17:48:42 +0000 - rev 486392
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1460075 - Use 1px as the minimum column width. r=dbaron Differential Revision: https://phabricator.services.mozilla.com/D3140
9a6728f46269: Bug 1472919 - Establish stacking context, containing block, independent formatting context for contain:layout. r=dbaron
Morgan Rae Reschenberg <mreschenberg@mozilla.com> - Fri, 20 Jul 2018 10:57:22 -0700 - rev 486100
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1472919 - Establish stacking context, containing block, independent formatting context for contain:layout. r=dbaron MozReview-Commit-ID: H36HpePX29C
2a818faa9c1b: Bug 1467541 - Add a test for opening the layout debugger. r=dbaron
Ian Moody <moz-ian@perix.co.uk> - Thu, 09 Aug 2018 10:53:01 +0300 - rev 485904
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1467541 - Add a test for opening the layout debugger. r=dbaron Summary: Reviewers: dbaron Reviewed By: dbaron Bug #: 1467541 Differential Revision: https://phabricator.services.mozilla.com/D2691
5ed009eaad1c: Bug 1467541 - Remove dead layout debug files. r=dbaron
Ian Moody <moz-ian@perix.co.uk> - Thu, 09 Aug 2018 10:52:54 +0300 - rev 485903
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1467541 - Remove dead layout debug files. r=dbaron Summary: No longer used since it stopped being built as an extension. Reviewers: dbaron Reviewed By: dbaron Bug #: 1467541 Differential Revision: https://phabricator.services.mozilla.com/D2663
db5198c10a4b: Bug 1467541 - Package layout debugger in debug builds. r=dbaron
Ian Moody <moz-ian@perix.co.uk> - Thu, 09 Aug 2018 10:52:49 +0300 - rev 485902
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1467541 - Package layout debugger in debug builds. r=dbaron Reviewers: dbaron Reviewed By: dbaron Bug #: 1467541 Differential Revision: https://phabricator.services.mozilla.com/D2665
8fae317831c1: Bug 1481097 - layout: Remove nsCSSPseudoElements workaround for gcc 4.9.2 bug. r=dbaron
Chris Peterson <cpeterson@mozilla.com> - Sat, 21 Jul 2018 23:48:16 -0700 - rev 485615
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1481097 - layout: Remove nsCSSPseudoElements workaround for gcc 4.9.2 bug. r=dbaron This gcc 4.9.2 workaround (from bug 1273048) is no longer needed because Firefox for Android now uses clang instead of gcc (as of bug 1163171). The gcc bug was fixed in gcc 4.8.5 and 4.9.3: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 MozReview-Commit-ID: IAKONNSkqcz
9c9b31d0ed53: Bug 1478455 - Add overflow-wrap: normal for table to html.css. r=dbaron
Xidorn Quan <me@upsuper.org> - Thu, 02 Aug 2018 01:18:26 +0000 - rev 484777
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1478455 - Add overflow-wrap: normal for table to html.css. r=dbaron This would fix this bug as well as webcompat/web-bugs#17900. The argument for this to be a reasonable change is that, table cells can never shrink below the min intrinsic size, so overflow-wrap: break-word doesn't make any sense in table when it didn't affect intrinsic size. So this change basically revert the behavior of bug 1472386 for tables which seems to be the biggest problem so far. Differential Revision: https://phabricator.services.mozilla.com/D2638
a05794e50453: Bug 1476437 - Correct original-text indexing when checking for explicit hyphens in text where auto-hyphenation is enabled. r=dbaron
Jonathan Kew <jkew@mozilla.com> - Sat, 28 Jul 2018 09:23:36 +0100 - rev 483968
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1476437 - Correct original-text indexing when checking for explicit hyphens in text where auto-hyphenation is enabled. r=dbaron
fbb04354c2cf: Bug 1476437 - Further reftest for multi-line content with whitespace/explicit-hyphen/autohyphenation. r=dbaron
Jonathan Kew <jkew@mozilla.com> - Sat, 28 Jul 2018 09:23:30 +0100 - rev 483967
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1476437 - Further reftest for multi-line content with whitespace/explicit-hyphen/autohyphenation. r=dbaron
af1cdd4b96b3: Bug 1476437 - Reftest for interaction between whitespace collapsing, explicit hyphen, and auto-hyphenation. r=dbaron
Jonathan Kew <jkew@mozilla.com> - Sat, 28 Jul 2018 09:23:26 +0100 - rev 483966
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1476437 - Reftest for interaction between whitespace collapsing, explicit hyphen, and auto-hyphenation. r=dbaron
0f907558ec7f: Bug 1478574 - Fix off-by-one error in marking explicit hyphens, so we don't introduce spurious pre-hyphen breaks. r=dbaron
Jonathan Kew <jkew@mozilla.com> - Sat, 28 Jul 2018 09:23:11 +0100 - rev 483965
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1478574 - Fix off-by-one error in marking explicit hyphens, so we don't introduce spurious pre-hyphen breaks. r=dbaron
5f98633a0e8f: Bug 1478574 - Reftest for interaction of explicit hyphen and auto-hyphenation in the same word. r=dbaron
Jonathan Kew <jkew@mozilla.com> - Sat, 28 Jul 2018 09:22:44 +0100 - rev 483964
Push 9719 by ffxbld-merge at 2018-08-24 17:49 +0000
Bug 1478574 - Reftest for interaction of explicit hyphen and auto-hyphenation in the same word. r=dbaron