searching for reviewer(TYLin)
c1d9e657897e5e7ef32227d8a0c8c7dfc9d13de6: Bug 1596310 - Clamp negative available size to zero and ensure page break frames don't apply margins. r=TYLin
Mats Palmgren <mats@mozilla.com> - Mon, 18 Nov 2019 20:36:52 +0000 - rev 502468
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596310 - Clamp negative available size to zero and ensure page break frames don't apply margins. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D53040
74ae5427c21f848b01a2e72fd81f339ba2a5b7a3: Bug 1591947 - Fix style changes from list-style-image to -moz-appearance for XUL images. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Sat, 09 Nov 2019 16:48:04 +0000 - rev 501414
Push 114169 by ncsoregi@mozilla.com at Mon, 11 Nov 2019 12:39:11 +0000
Bug 1591947 - Fix style changes from list-style-image to -moz-appearance for XUL images. r=TYLin Consider the following case: <image style="list-style-image: url(foo.png)"></image> image.style.MozAppearance = "something" The early return was preventing us from clearing the image. This is an ancient bug, but it has started happening in the browser chrome because the lack of lazy frame construction for XUL elements makes us construct elements with an outdated style, which means in this case that they wouldn't have the -moz-appearance rule applied yet. Differential Revision: https://phabricator.services.mozilla.com/D52112
1aae03a822b891ef346603d537c271e5c9b8c677: Bug 1591947 - Fix style changes from list-style-image to -moz-appearance for XUL images. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 08 Nov 2019 11:14:35 +0000 - rev 501238
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1591947 - Fix style changes from list-style-image to -moz-appearance for XUL images. r=TYLin Consider the following case: <image style="list-style-image: url(foo.png)"></image> image.style.MozAppearance = "something" The early return was preventing us from clearing the image. This is an ancient bug, but it has started happening in the browser chrome because the lack of lazy frame construction for XUL elements makes us construct elements with an outdated style, which means in this case that they wouldn't have the -moz-appearance rule applied yet. Differential Revision: https://phabricator.services.mozilla.com/D52112
189852a9cf2ab97bda7372bf570c77c9e4ea71a8: Bug 1588017 - Clean up nsIFrame::IntrinsicISizeOffsetData r=TYLin,dholbert
alaskanemily <emcdonough@mozilla.com> - Tue, 05 Nov 2019 18:52:03 +0000 - rev 500706
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1588017 - Clean up nsIFrame::IntrinsicISizeOffsetData r=TYLin,dholbert Update the comments, name, and fields to show it is agnostic of isize/bsize. Differential Revision: https://phabricator.services.mozilla.com/D51739
ec8a7fed426d972d24058ba1249a9d44335f5a07: Bug 1591297 - Remove XBL binding loading code in the frame constructor. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 25 Oct 2019 18:46:59 +0000 - rev 499595
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1591297 - Remove XBL binding loading code in the frame constructor. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D50555
7d697ed8c7276b155403c14daaa640be0ce4c8e4: Bug 1590639 part 3: Fix non-unified build issues in layout/{forms,painting}. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 23 Oct 2019 22:12:39 +0000 - rev 499128
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1590639 part 3: Fix non-unified build issues in layout/{forms,painting}. r=TYLin This patch: - Gives nsMeterFrame.cpp a "using" decl for mozilla::dom::Document (matching local style), to make its "nsCOMPtr<Document>" variable valid. - Gives RetainedDisplayListBuilder.cpp an include for nsIFrameInlines.h (and nsIFrame.h for good measure) to provide the definition for inline function nsIFrame::IsFixedPosContainingBlock(). - Gives nsDisplayList.cpp an include for LayerAnimationInfo.h, since it uses that type. Depends on D50164 Differential Revision: https://phabricator.services.mozilla.com/D50165
db3fe5184abb0201fe0b7a6384cde1e6e52bbaca: Bug 1590639 part 2: Fix non-unified build issues in layout/base. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 23 Oct 2019 22:10:11 +0000 - rev 499127
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1590639 part 2: Fix non-unified build issues in layout/base. r=TYLin Changes here: - Adding a "dom::" prefix in GeckoMVMContext.cpp (could've also added a "using" decl, but I'm just adding a one-off prefix to match "dom::Document" usage elsewhere in this file). - Giving nsLayoutUtils an include for ViewportFrame.h since it uses that type. - Giving nsPresArena.cpp an include for nsDisplayList.h to provide the DisplayListArenaObjectId enum type. Depends on D50163 Differential Revision: https://phabricator.services.mozilla.com/D50164
7c82ce0af9f0b5589e08e8f69e6d7ab466aacab4: Bug 1590639 part 1: Fix non-unified build issues in layout/generic. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 23 Oct 2019 22:05:22 +0000 - rev 499126
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1590639 part 1: Fix non-unified build issues in layout/generic. r=TYLin The issues fall into these categories: - Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an include. (Addressed by adding the missing include.) - Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the namespace & without a 'using' decl. (Addressed by adding "using".) - A few other includes for types/inlines that were used without their header. Depends on D50162 Differential Revision: https://phabricator.services.mozilla.com/D50163
8884f26e36b340c2860b6afbcfa50c3ec641fe6d: Bug 1590639 part 0: Run clang-format on layout/. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 23 Oct 2019 22:02:43 +0000 - rev 499125
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1590639 part 0: Run clang-format on layout/. r=TYLin This patch is entirely automated, and was generated with the following command: ./mach clang-format -p layout/ Differential Revision: https://phabricator.services.mozilla.com/D50162
25d95be82e953bfe3758acb96c3fb80b9b602f5a: Bug 1562057: Change size-contained & empty select elements to have the same inline-size. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Sat, 12 Oct 2019 16:11:54 +0000 - rev 497351
Push 114148 by shindli@mozilla.com at Mon, 14 Oct 2019 10:49:50 +0000
Bug 1562057: Change size-contained & empty select elements to have the same inline-size. r=TYLin Per the css-contain specification, size contained elements must be sized as if they were empty. Up until now, we've been handling that by just using "0" as the intrinsic size of some components, but that doesn't actually match the size of a "true" empty select, which has some nonzero width from: (a) the default inline-axis padding on the display frame (added in a rule for the ::-moz-display-comboboxcontrol-frame pseudo, in forms.css). (b) the width (inline-size) of the display frame's "placeholder" space character, which has a small intrinsic width (but which really only exists for *block-axis* sizing and alignment, when no option is selected from the dropdown). This patch addresses issue (a) by explicitly adding the display frame's inline-axis padding to size-contained elements, and it addresses issue (b) by changing to use a zero-width space character in empty select elements. So: as of this patch, size-contained select elements are getting a little wider (to address (a)), and empty select elements are also getting a little skinnier (to address (b)), and they'll end up being the same width. (I chose U+FEFF "zero-width non-breaking-space" since we were previously using a non-breaking space character. I'm not sure if the non-breaking aspect matters, but I figured I'd preserve that to be on the safe side.) Differential Revision: https://phabricator.services.mozilla.com/D48791
a8ea98346a87402b1c3ad4c892694d0de163a0b3: Bug 1562057: Change size-contained & empty select elements to have the same inline-size. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 11 Oct 2019 16:51:41 +0000 - rev 497289
Push 114148 by shindli@mozilla.com at Mon, 14 Oct 2019 10:49:50 +0000
Bug 1562057: Change size-contained & empty select elements to have the same inline-size. r=TYLin Per the css-contain specification, size contained elements must be sized as if they were empty. Up until now, we've been handling that by just using "0" as the intrinsic size of some components, but that doesn't actually match the size of a "true" empty select, which has some nonzero width from: (a) the default inline-axis padding on the display frame (added in a rule for the ::-moz-display-comboboxcontrol-frame pseudo, in forms.css). (b) the width (inline-size) of the display frame's "placeholder" space character, which has a small intrinsic width (but which really only exists for *block-axis* sizing and alignment, when no option is selected from the dropdown). This patch addresses issue (a) by explicitly adding the display frame's inline-axis padding to size-contained elements, and it addresses issue (b) by changing to use a zero-width space character in empty select elements. So: as of this patch, size-contained select elements are getting a little wider (to address (a)), and empty select elements are also getting a little skinnier (to address (b)), and they'll end up being the same width. (I chose U+FEFF "zero-width non-breaking-space" since we were previously using a non-breaking space character. I'm not sure if the non-breaking aspect matters, but I figured I'd preserve that to be on the safe side.) Differential Revision: https://phabricator.services.mozilla.com/D48791
c154d38e2741b2a2c7ed4a70e58e43b40204dbf9: Bug 1553772 - Bug 1549812 - Try to assert a bit harder about stuff not flushing under our nose. r=TYLin,mats
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 26 Sep 2019 20:55:58 +0000 - rev 495255
Push 114134 by ccoroiu@mozilla.com at Mon, 30 Sep 2019 09:57:15 +0000
Bug 1553772 - Bug 1549812 - Try to assert a bit harder about stuff not flushing under our nose. r=TYLin,mats I think these should hold, everything that runs under them should just schedule other stuff to some later date: * Synth mouse events -> scheduled as refresh driver observers. * Scroll events -> Scheduled as well. * Caret state change events -> Also scheduled after last patch. * IME and accessibility stuff -> I don't think they can reenter layout. We can always revert this if it causes troubles, plus it shouldn't crash on release so should be fine. Differential Revision: https://phabricator.services.mozilla.com/D31090
4984ebbc98f5671749565d6934f82a41579f5061: Bug 1553772 - Bug 1549812 - Don't run arbitrary script from AccessibleCaretManager callbacks. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 26 Sep 2019 20:55:53 +0000 - rev 495254
Push 114134 by ccoroiu@mozilla.com at Mon, 30 Sep 2019 09:57:15 +0000
Bug 1553772 - Bug 1549812 - Don't run arbitrary script from AccessibleCaretManager callbacks. r=TYLin Instead, post the event for the next turn of the event loop. In this case, what killed the frame is ActionBarHandler.jsm via Selection.toString(). Depends on D31088 Differential Revision: https://phabricator.services.mozilla.com/D31089
dd1ab53baf97c49e65ab6a98f6fccff9c6691f95: Bug 1448730 - Long tap doesn't select word if tapped point isn't text. r=TYLin
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Thu, 26 Sep 2019 08:36:46 +0000 - rev 495144
Push 114133 by shindli@mozilla.com at Thu, 26 Sep 2019 21:40:49 +0000
Bug 1448730 - Long tap doesn't select word if tapped point isn't text. r=TYLin Actually, Gecko's long tap implementation will select a word string near tapped area even if tapped area isn't text. Since Blink doesn't select it and user reports this issue via web compat, I would not like to select text if tapped area isn't text. Differential Revision: https://phabricator.services.mozilla.com/D46126
8f159b8c631d3e2d05a81644ad435ca751a8aefe: Bug 1481951 late-breaking followup: Remove mistaken comment with a reference to this (closed) bug. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 30 Aug 2019 20:37:10 +0000 - rev 490938
Push 114010 by dluca@mozilla.com at Sat, 31 Aug 2019 09:58:00 +0000
Bug 1481951 late-breaking followup: Remove mistaken comment with a reference to this (closed) bug. r=TYLin DONTBUILD because this is a comment-only change. Per bug 1481951 comment 6, it seems our behavior was in fact correct even when the comment was added, and this "// XXX" comment was just due to a misunderstanding in what was going on in the testcase. Differential Revision: https://phabricator.services.mozilla.com/D44229
8ab6419caa6a8d474c5055c66e3530864db39816: Bug 1576018 - Tweak frame tree debugging output. r=TYLin
Cameron McCormack <cam@mcc.id.au> - Fri, 23 Aug 2019 05:31:37 +0000 - rev 489544
Push 113953 by ncsoregi@mozilla.com at Fri, 23 Aug 2019 15:43:44 +0000
Bug 1576018 - Tweak frame tree debugging output. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D43178
905117fbca93bc285a77bb6c4a46c4c0f8557af9: Bug 1571250 - Convert flags passed to ReflowChild, FinishReflowChild, SyncFrameViewAfterReflow and from GetXULLayoutFlags / GetLayoutFlags into an enum class. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 08 Aug 2019 19:48:19 +0000 - rev 487065
Push 113859 by rmaries@mozilla.com at Fri, 09 Aug 2019 03:53:37 +0000
Bug 1571250 - Convert flags passed to ReflowChild, FinishReflowChild, SyncFrameViewAfterReflow and from GetXULLayoutFlags / GetLayoutFlags into an enum class. r=TYLin It seems better to convert this before adding a new flag (in bug 1547759) and risking replacing the wrong 0 with a flag. Differential Revision: https://phabricator.services.mozilla.com/D40562
6fd3876db7c695a231ce396d8076659d9c0aaee2: Bug 1571249 - Remove the IsTableCell() function. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 08 Aug 2019 19:48:12 +0000 - rev 487064
Push 113859 by rmaries@mozilla.com at Fri, 09 Aug 2019 03:53:37 +0000
Bug 1571249 - Remove the IsTableCell() function. r=TYLin It was made pointless by the previous patch. This replaces callers that had a frame type for another reason with the frame type check that IsTableCell did, and callers that needed to call Type() with an IsTableCellFrame call. Differential Revision: https://phabricator.services.mozilla.com/D40561
44bfb4911daf27aceef88efdf91f06a1b75cc9e5: Bug 1571249 - Remove BCTableCell as a distinct frame type. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 08 Aug 2019 19:48:10 +0000 - rev 487063
Push 113859 by rmaries@mozilla.com at Fri, 09 Aug 2019 03:53:37 +0000
Bug 1571249 - Remove BCTableCell as a distinct frame type. r=TYLin There are two existing callers of IsTableCellFrame that both appear to want to include BCTableCell frames, but don't. A patch in bug 1547759 will add a third that wants the same. The existing users of frame types all have to work around it being a distinct type, and none appear to want the distinction. This removes that complexity. If any callers want to make the distinction, they could implement QueryFrame for BCTableCellFrame and use it. (It's not implemented now, though!) In a little more detail, prior to this patch (in my debug build, at least): * nsQueryFrame::ClassID::nsMathMLmtdFrame_id was 46 * nsQueryFrame::ClassID::nsTableCellFrame_id was 47 * nsQueryFrame::ClassID::nsBCTableCellFrame_id was 65 and entries 46 and 47 in sLayoutFrameTypes were mozilla::LayoutFrameType::TableCell while entry 65 was mozilla::LayoutFrameType::BCTableCell. With this patch: * nsQueryFrame::ClassID::nsBCTableCellFrame_id is 40 * nsQueryFrame::ClassID::nsMathMLmtdFrame_id is 41 * nsQueryFrame::ClassID::nsTableCellFrame_id is 42 and entries 40 through 42 in sLayoutFrameTypes are mozilla::LayoutFrameType::TableCell. Differential Revision: https://phabricator.services.mozilla.com/D40560
d649cff4234211f78f7e5f2c309d07029b99fb7b: Bug 1571460 - Set prev-in-flow before calling nsFrame::Init. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 06 Aug 2019 20:16:44 +0200 - rev 486810
Push 113855 by shindli@mozilla.com at Wed, 07 Aug 2019 21:56:41 +0000
Bug 1571460 - Set prev-in-flow before calling nsFrame::Init. r=TYLin Parts of nsFrame::Init or code called by it should be able to rely on the invariant that, if the frame has the NS_FRAME_OUT_OF_FLOW bit, the first-in-flow frame has a placeholder property. Alternatively to this patch, the NS_FRAME_OUT_OF_FLOW frame bit could be propagated later, as it used to be. Differential Revision: https://phabricator.services.mozilla.com//D40815
3f4421e34ab4604ff077e8b88fc2bfa1b362f4cf: Bug 1571460 - Set prev-in-flow before calling nsFrame::Init. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 07 Aug 2019 10:44:54 +0000 - rev 486784
Push 113855 by shindli@mozilla.com at Wed, 07 Aug 2019 21:56:41 +0000
Bug 1571460 - Set prev-in-flow before calling nsFrame::Init. r=TYLin Parts of nsFrame::Init or code called by it should be able to rely on the invariant that, if the frame has the NS_FRAME_OUT_OF_FLOW bit, the first-in-flow frame has a placeholder property. Alternatively to this patch, the NS_FRAME_OUT_OF_FLOW frame bit could be propagated later, as it used to be. Differential Revision: https://phabricator.services.mozilla.com/D40815
14d818778beb780f63ff82ff01e574ed0473af0f: Bug 1404868 - Always reflow float placeholders when they move to a different block fragment. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 02 Aug 2019 21:05:20 +0000 - rev 486070
Push 113827 by btara@mozilla.com at Sat, 03 Aug 2019 09:54:50 +0000
Bug 1404868 - Always reflow float placeholders when they move to a different block fragment. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D40276
c3cbe1928fea91ae4764f95762a19118c6d28902: Bug 1404868 - Record in the reflow input whether we're in a different page/column than before. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 02 Aug 2019 23:51:21 +0000 - rev 486069
Push 113827 by btara@mozilla.com at Sat, 03 Aug 2019 09:54:50 +0000
Bug 1404868 - Record in the reflow input whether we're in a different page/column than before. r=TYLin This depends on the line state stored in the previous patch, and will be used in the following patch. I'm passing this information through the reflow input here, rather than doing an extra pass over the frame tree in the following patch, because I believe it's substantially better for memory locality during reflow. Differential Revision: https://phabricator.services.mozilla.com/D40275
838aa6f9e0c7ea69db6bb7ac04b1e1c0ca019903: Bug 1404868 - Record when lines are in a different fragment than the one in which they were previously reflowed. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 02 Aug 2019 20:44:53 +0000 - rev 486068
Push 113827 by btara@mozilla.com at Sat, 03 Aug 2019 09:54:50 +0000
Bug 1404868 - Record when lines are in a different fragment than the one in which they were previously reflowed. r=TYLin This will be used in the following patch. Differential Revision: https://phabricator.services.mozilla.com/D40274
9fe69074259e50f2bc1805f8c42d22d15c43ee75: Bug 1404868 - Add reftests. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 02 Aug 2019 23:44:13 +0000 - rev 486067
Push 113827 by btara@mozilla.com at Sat, 03 Aug 2019 09:54:50 +0000
Bug 1404868 - Add reftests. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D40273
a5d545e31781b28dfc37020e0b622377288d17bd: Bug 1420528 - As with constrained block-size, reflow lines with floats when block-size was *previously* constrained. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 01 Aug 2019 06:57:07 +0000 - rev 485805
Push 113820 by rmaries@mozilla.com at Fri, 02 Aug 2019 04:17:07 +0000
Bug 1420528 - As with constrained block-size, reflow lines with floats when block-size was *previously* constrained. r=TYLin On its own (without the previous patch), this fixes bug 1406291. Combined with the previous patch, this patch fixes this bug (bug 1420528) when column-span is not enabled (today's configuration), and also fixes 1411799. Differential Revision: https://phabricator.services.mozilla.com/D39818
9d335538cabc9647c997600c8615dd123fd1c67a: Bug 1420528 - When a frame that was incomplete doesn't fit, make sure we reflow it again. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 01 Aug 2019 00:48:05 +0000 - rev 485804
Push 113820 by rmaries@mozilla.com at Fri, 02 Aug 2019 04:17:07 +0000
Bug 1420528 - When a frame that was incomplete doesn't fit, make sure we reflow it again. r=TYLin This patch fixes bug 1420528 when column-span is enabled, and it also fixes bug 1468654. Differential Revision: https://phabricator.services.mozilla.com/D39582
0e809359904aa2c2a53c5b94977c7fa017245927: Bug 1420528 - Add reftests for other bugs fixed by this bug. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 01 Aug 2019 06:55:04 +0000 - rev 485803
Push 113820 by rmaries@mozilla.com at Fri, 02 Aug 2019 04:17:07 +0000
Bug 1420528 - Add reftests for other bugs fixed by this bug. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D40144
df63a9466390088910afd03d881d05bd8d0b9067: Bug 1420528 - Add reftest. r=TYLin
L. David Baron <dbaron@dbaron.org> - Thu, 01 Aug 2019 00:48:00 +0000 - rev 485802
Push 113820 by rmaries@mozilla.com at Fri, 02 Aug 2019 04:17:07 +0000
Bug 1420528 - Add reftest. r=TYLin Note that I introduced a blank line to make the intent of the NOTE clearer, which I had to research. I think it's clear it covers the three tests below it based on https://hg.mozilla.org/mozilla-central/rev/53489b3e14f1 and https://bugzilla.mozilla.org/show_bug.cgi?id=967311#c0 . I'm also running this test both with and without the column-span pref, because those two states will be fixed by different patches. Co-authored-by: L. David Baron <dbaron@dbaron.org> Co-authored-by: Daniel Holbert <dholbert@cs.stanford.edu> Differential Revision: https://phabricator.services.mozilla.com/D39581
ac4398269328e4abb86618e9483921acfe7eed6a: Bug 1564649 - Reflow all columns when a multicol with non-auto block-size balances its columns at a different block-size. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 12 Jul 2019 20:24:46 +0000 - rev 482683
Push 113678 by csabou@mozilla.com at Sat, 13 Jul 2019 10:07:02 +0000
Bug 1564649 - Reflow all columns when a multicol with non-auto block-size balances its columns at a different block-size. r=TYLin Depends on D37516 Differential Revision: https://phabricator.services.mozilla.com/D37517
fed851fb8e831435ebe7f445d0d6672b6f2aa682: Bug 1564649 - Add reftest. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 12 Jul 2019 20:24:44 +0000 - rev 482682
Push 113678 by csabou@mozilla.com at Sat, 13 Jul 2019 10:07:02 +0000
Bug 1564649 - Add reftest. r=TYLin Depends on D37515 Differential Revision: https://phabricator.services.mozilla.com/D37516
c34163e3ba0bc56900f1344e0296b8e027307f05: Bug 1564649 - Remove a duplicate variable where we had two variables for the same thing, and a little related cleanup. r=TYLin
L. David Baron <dbaron@dbaron.org> - Fri, 12 Jul 2019 20:24:41 +0000 - rev 482681
Push 113678 by csabou@mozilla.com at Sat, 13 Jul 2019 10:07:02 +0000
Bug 1564649 - Remove a duplicate variable where we had two variables for the same thing, and a little related cleanup. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D37515
bbcd2af40409fad89375fcaabc5b83d9ae99e99e: Bug 1563278: Specify font-family and font-size on the same element in web-platform-test contain-paint-008.html. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 10 Jul 2019 17:45:35 +0000 - rev 482284
Push 113660 by opoprus@mozilla.com at Thu, 11 Jul 2019 10:01:33 +0000
Bug 1563278: Specify font-family and font-size on the same element in web-platform-test contain-paint-008.html. r=TYLin This patch corrects a likely-inadvertent difference between the CSS in this testcase vs. its reference case. This patch fixes a Windows & MacOS off-by-1px spurious failure in this test, which was probably due to having text whose font-metrics differ from its line-box (in the testcase) vs. agree with its line-box (in the reference). While we're here, this patch also adjusts the code-comment in the testcase to avoid implying that Firefox unconditionally lacks support for containment. (And to fix a minor grammatical typo, "not need" --> "no need".) Differential Revision: https://phabricator.services.mozilla.com/D37494
58154cdbf8980ccd0494f4301c10f4c0e44d0fe8: Bug 1487493: Remove early-beta restriction on CSS Containment (i.e. let it ride the trains to release). r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Mon, 08 Jul 2019 21:11:54 +0000 - rev 481730
Push 113632 by nbeleuzu@mozilla.com at Tue, 09 Jul 2019 03:54:50 +0000
Bug 1487493: Remove early-beta restriction on CSS Containment (i.e. let it ride the trains to release). r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D37303
824b5c4ed05e7fea23beae05413929540f871f8a: Bug 1563050: Treat table-cells with contain:layout as if they had no baseline. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Mon, 08 Jul 2019 17:41:35 +0000 - rev 481699
Push 113632 by nbeleuzu@mozilla.com at Tue, 09 Jul 2019 03:54:50 +0000
Bug 1563050: Treat table-cells with contain:layout as if they had no baseline. r=TYLin This makes us pass web platform test contain-layout-baseline-004.html (i.e. it makes us treat that test's 'contain:layout' table-cell as having no baseline, so we align its bottom edge with the other cell's actual baseline, as the test expects). This is required by the spec text at [1] which excludes most table parts but includes table cells, and says "the containing element is treated as having no baseline". [1] https://drafts.csswg.org/css-contain/#containment-layout Differential Revision: https://phabricator.services.mozilla.com/D37118
a248baf9930163ebeb066239174ed57b9bbb0b06: Bug 1562312: Implement 'contain:size' for <select multiple> elements. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Tue, 02 Jul 2019 18:40:17 +0000 - rev 481011
Push 113587 by aciure@mozilla.com at Wed, 03 Jul 2019 04:10:52 +0000
Bug 1562312: Implement 'contain:size' for <select multiple> elements. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D36418
8bf1ded5ea19f5ade7d2ff89b92d1edef6ad5ba5: Bug 1476127: Implement 'contain:size' for select elements. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 28 Jun 2019 20:32:13 +0000 - rev 480635
Push 113561 by ncsoregi@mozilla.com at Sat, 29 Jun 2019 10:06:30 +0000
Bug 1476127: Implement 'contain:size' for select elements. r=TYLin Note that this is an imperfect implementation, in that it doesn't exactly match the sizing behavior of a truly empty `<select>` element. I've filed followup bug 1562057 on that. However, the behavior that's implemented here *does* successfully make us ignore a `<select>`'s contents for sizing purposes, and it's much better than what we do currently (which is pretty broken via inheriting a partial `contain:size` implementation from our parent class, nsBlockFrame). Differential Revision: https://phabricator.services.mozilla.com/D36253
01c3e71304c671a20a95bfe578dc3a4c5cc41079: Bug 1555757: Exempt table-wrapper frames from becoming css-containment-promoted reflow roots. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Thu, 27 Jun 2019 00:16:41 +0000 - rev 480272
Push 113537 by ccoroiu@mozilla.com at Thu, 27 Jun 2019 09:46:01 +0000
Bug 1555757: Exempt table-wrapper frames from becoming css-containment-promoted reflow roots. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D36073
e2af929535f6b486eab6875f361cc7776f27d194: Bug 1558352 - Ensure canvas anonymous content is always created before constructing the document element frame's children. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 12 Jun 2019 10:09:28 +0000 - rev 478407
Push 113419 by dluca@mozilla.com at Wed, 12 Jun 2019 12:45:34 +0000
Bug 1558352 - Ensure canvas anonymous content is always created before constructing the document element frame's children. r=TYLin Right now that doesn't happen, so you can run into problems like the one described in bug 1492582 comment 30 for popups. This is a bit annoying, but it's more consistent with how regular anonymous content works already: https://searchfox.org/mozilla-central/rev/0da35261b6789eec65476dbdd4913df6e235af6d/layout/base/nsCSSFrameConstructor.cpp#9644 It's still not 100% consistent, since the root element's frame would still end up first in the frame tree, but I think that's both less important and harder to change. I've left a comment to that effect in the code. Differential Revision: https://phabricator.services.mozilla.com/D34434
3eda0c8cf975171c9d1c1f2d4c2f555531b03e88: Bug 1552287 part 2: [css-contain] Adjust various reflow & baseline methods so that layout-contained frames behave as if they have no baseline. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 24 May 2019 04:46:17 +0000 - rev 475337
Push 113201 by csabou@mozilla.com at Fri, 24 May 2019 09:57:23 +0000
Bug 1552287 part 2: [css-contain] Adjust various reflow & baseline methods so that layout-contained frames behave as if they have no baseline. r=TYLin We previously (in bug 1491235) adjusted some utility code to make layout-contained frames behave as if they have no baseline. But that's not sufficient. To make frames fully report lack-of-a-baseline, we now do the following for layout-contained frames, as of this patch: (a) We now leave the ReflowOutput outparam's BlockStartAscent member at its default value (which is what we do for frames without a baseline like e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares about the baseline, it'll then ask directly, using a baseline getter. (b) We now return 'false' in more implementations of bool-returning baseline-getter-methods (where 'false' indicates 'no baseline'). (c) We now return the margin-box-bottom edge, in the nscoord-returning 'GetLogicalBaseline()' getter method. (We typically do this by deferring to the inherited method, which ultimately comes from nsFrame's implementation). It's appropriate to use the margin-box-bottom edge when there's no baseline, per the definition of 'vertical-align: baseline', here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align Depends on D32182 Differential Revision: https://phabricator.services.mozilla.com/D32183
9360fef47426b836880d8a0cdf99b9357d1273c9: Bug 1552287 part 1: [css-contain] Fix some CSS layout-containment web-platform-tests to make their assumptions more valid. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 24 May 2019 04:46:07 +0000 - rev 475336
Push 113201 by csabou@mozilla.com at Fri, 24 May 2019 09:57:23 +0000
Bug 1552287 part 1: [css-contain] Fix some CSS layout-containment web-platform-tests to make their assumptions more valid. r=TYLin In particular: - In contain-layout-suppress-baseline-002.html, the test currently indirectly relies on the 50px-tall-canvas being the tallest thing in each flex container. This isn't robustly true (and in fact on windows, the textarea is taller at 50.8px tall). So I'm adjusting this test so that it no longer has a hardcoded flex container size and no longer depends on this. - In contain-layout-baseline-005.html and its reference case, we need to explicitly specify 'vertical-align:baseline' to test baseline-alignment, because some of its tested form controls have other UA-stylesheet-provided default values of 'vertical-align'. (e.g. <select multiple> defaults to 'vertical-align:text-bottom") - Also: in that same test, we need to reduce the width of the an <input> textfield -- otherwise, it and the other elements on its line may not fit and may linewrap, which prevents us from effectively testing baseline-alignment on the linewrapped element. - In contain-layout-button-001.html, the expectation was not correct. Before this patch, the test expects that a layout-contained button will have the same baseline as an empty button, and that's an invalid expectation. An empty button uses a point inside of its content-box as its baseline, whereas a layout-contained element *has no baseline*, which means that it does 'vertical-align:baseline' alignment by aligning its own margin-bottom edge with the parent's baseline, per https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align So, I'm amending the test to have this expectation and updating its meta tags to reference the updated expectation and with a reference to that spec text. Firefox fails the amended contain-layout-button-001.html test, so this patch adds a .ini file to reflect that failure. The next patch in this series will fix our implementation to make us pass the test, and will remove the .ini file. Chrome also fails the amended contain-layout-button-001.html tests, and I filed https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an explanation. Differential Revision: https://phabricator.services.mozilla.com/D32182
815c6657d164d34b215a39d233cc60b2e6f546fa: Bug 1552287 part 2: [css-contain] Adjust various reflow & baseline methods so that layout-contained frames behave as if they have no baseline. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Thu, 23 May 2019 21:41:35 +0000 - rev 475301
Push 113198 by aciure@mozilla.com at Fri, 24 May 2019 04:03:55 +0000
Bug 1552287 part 2: [css-contain] Adjust various reflow & baseline methods so that layout-contained frames behave as if they have no baseline. r=TYLin We previously (in bug 1491235) adjusted some utility code to make layout-contained frames behave as if they have no baseline. But that's not sufficient. To make frames fully report lack-of-a-baseline, we now do the following for layout-contained frames, as of this patch: (a) We now leave the ReflowOutput outparam's BlockStartAscent member at its default value (which is what we do for frames without a baseline like e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares about the baseline, it'll then ask directly, using a baseline getter. (b) We now return 'false' in more implementations of bool-returning baseline-getter-methods (where 'false' indicates 'no baseline'). (c) We now return the margin-box-bottom edge, in the nscoord-returning 'GetLogicalBaseline()' getter method. (We typically do this by deferring to the inherited method, which ultimately comes from nsFrame's implementation). It's appropriate to use the margin-box-bottom edge when there's no baseline, per the definition of 'vertical-align: baseline', here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align Depends on D32182 Differential Revision: https://phabricator.services.mozilla.com/D32183
888c32d2a32e849046cfe945593fe684c79e9ffa: Bug 1552287 part 1: [css-contain] Fix some CSS layout-containment web-platform-tests to make their assumptions more valid. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Thu, 23 May 2019 21:41:24 +0000 - rev 475300
Push 113198 by aciure@mozilla.com at Fri, 24 May 2019 04:03:55 +0000
Bug 1552287 part 1: [css-contain] Fix some CSS layout-containment web-platform-tests to make their assumptions more valid. r=TYLin In particular: - In contain-layout-baseline-005.html and its reference case, we need to explicitly specify 'vertical-align:baseline' to test baseline-alignment, because some of its tested form controls have other UA-stylesheet-provided default values of 'vertical-align'. (e.g. <select multiple> defaults to 'vertical-align:text-bottom") - Also: in that same test, we need to reduce the width of the an <input> textfield -- otherwise, it and the other elements on its line may not fit and may linewrap, which prevents us from effectively testing baseline-alignment on the linewrapped element. - In contain-layout-button-001.html, the expectation was not correct. Before this patch, the test expects that a layout-contained button will have the same baseline as an empty button, and that's an invalid expectation. An empty button uses a point inside of its content-box as its baseline, whereas a layout-contained element *has no baseline*, which means that it does 'vertical-align:baseline' alignment by aligning its own margin-bottom edge with the parent's baseline, per https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align So, I'm amending the test to have this expectation and updating its meta tags to reference the updated expectation and with a reference to that spec text. Firefox fails the amended contain-layout-button-001.html test, so this patch adds a .ini file to reflect that failure. The next patch in this series will fix our implementation to make us pass the test, and will remove the .ini file. Chrome also fails the amended contain-layout-button-001.html tests, and I filed https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an explanation. Differential Revision: https://phabricator.services.mozilla.com/D32182
afb705ca89e170f53f0a64e1339e9b5e6d5f84a8: Bug 1553548: [css-contain] Make table-wrapper-box inherit CSS "contain" from table box. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Thu, 23 May 2019 16:52:28 +0000 - rev 475227
Push 113196 by aciure@mozilla.com at Thu, 23 May 2019 22:38:40 +0000
Bug 1553548: [css-contain] Make table-wrapper-box inherit CSS "contain" from table box. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D32179
7286e18fbc1775558b8653bb63576a47b31a5f3e: Bug 1553772 - Bug 1549812 - Try to assert a bit harder about stuff not flushing under our nose. r=TYLin,mats
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 23 May 2019 09:45:56 +0000 - rev 475180
Push 113196 by aciure@mozilla.com at Thu, 23 May 2019 22:38:40 +0000
Bug 1553772 - Bug 1549812 - Try to assert a bit harder about stuff not flushing under our nose. r=TYLin,mats I think these should hold, everything that runs under them should just schedule other stuff to some later date: * Synth mouse events -> scheduled as refresh driver observers. * Scroll events -> Scheduled as well. * Caret state change events -> Also scheduled after last patch. * IME and accessibility stuff -> I don't think they can reenter layout. We can always revert this if it causes troubles, plus it shouldn't crash on release so should be fine. Differential Revision: https://phabricator.services.mozilla.com/D31090
58d40da713559f200d7ea651f2df0c434acee108: Bug 1553772 - Bug 1549812 - Don't run arbitrary script from AccessibleCaretManager callbacks. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 23 May 2019 09:45:47 +0000 - rev 475179
Push 113196 by aciure@mozilla.com at Thu, 23 May 2019 22:38:40 +0000
Bug 1553772 - Bug 1549812 - Don't run arbitrary script from AccessibleCaretManager callbacks. r=TYLin Instead, post the event for the next turn of the event loop. In this case, what killed the frame is ActionBarHandler.jsm via Selection.toString(). Depends on D31088 Differential Revision: https://phabricator.services.mozilla.com/D31089
32d724d2312caa420601b9cb7e3ef4bf1769b14e: Bug 1553772 - Bug 1549812 - fix testAccessibleCarets.js to account for more async event dispatching. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 23 May 2019 09:47:00 +0000 - rev 475178
Push 113196 by aciure@mozilla.com at Thu, 23 May 2019 22:38:40 +0000
Bug 1553772 - Bug 1549812 - fix testAccessibleCarets.js to account for more async event dispatching. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D32194
3c6b640e364f1eb7fc920ed1737de089631882b3: Bug 1552636 - Remove eStyleImageType_URL. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 22 May 2019 11:34:23 +0000 - rev 474949
Push 113181 by shindli@mozilla.com at Wed, 22 May 2019 15:39:08 +0000
Bug 1552636 - Remove eStyleImageType_URL. r=TYLin It was introduced in bug 1352096 to reduce complexity with Stylo (apparently). Right now it doesn't look like it reduces any complexity, and it's a bit annoying with some of the patches that I'm writing at the moment. So unless there's any objection I think it should go away. Differential Revision: https://phabricator.services.mozilla.com/D31708
00afc705d4eef04a1d71cea44953d0ba232a3794: Bug 1549812 - Try to assert a bit harder about stuff not flushing under our nose. r=TYLin,mats
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 17 May 2019 13:22:39 +0000 - rev 474341
Push 113149 by rgurzau@mozilla.com at Fri, 17 May 2019 21:50:06 +0000
Bug 1549812 - Try to assert a bit harder about stuff not flushing under our nose. r=TYLin,mats I think these should hold, everything that runs under them should just schedule other stuff to some later date: * Synth mouse events -> scheduled as refresh driver observers. * Scroll events -> Scheduled as well. * Caret state change events -> Also scheduled after last patch. * IME and accessibility stuff -> I don't think they can reenter layout. We can always revert this if it causes troubles, plus it shouldn't crash on release so should be fine. Differential Revision: https://phabricator.services.mozilla.com/D31090
cbc5c04bd3e4fb6cbfa04dc02f3f1e3cfd6c05a1: Bug 1549812 - Don't run arbitrary script from AccessibleCaretManager callbacks. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 17 May 2019 03:25:02 +0000 - rev 474340
Push 113149 by rgurzau@mozilla.com at Fri, 17 May 2019 21:50:06 +0000
Bug 1549812 - Don't run arbitrary script from AccessibleCaretManager callbacks. r=TYLin Instead, post the event for the next turn of the event loop. In this case, what killed the frame is ActionBarHandler.jsm via Selection.toString(). Depends on D31088 Differential Revision: https://phabricator.services.mozilla.com/D31089