searching for reviewer(TYLin)
6f67f28b1f0928c31c6366db2f82f11a6f718bae: Bug 1591947 - Fix style changes from list-style-image to -moz-appearance for XUL images. r=TYLin a=pascalc
Emilio Cobos Álvarez <emilio@crisal.io> - Sat, 09 Nov 2019 16:48:04 +0000 - rev 563306
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +0000
Bug 1591947 - Fix style changes from list-style-image to -moz-appearance for XUL images. r=TYLin a=pascalc 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
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 562019
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +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 561955
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +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 559845
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +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 559844
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +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 559735
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +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 554704
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 553293
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 550821
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 550820
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 550819
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 550500
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 550474
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549810
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549809
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549808
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549807
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549553
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549552
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549551
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 549550
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 546437
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 546436
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 546435
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 546036
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 545470
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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 545439
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +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
b6dae45b2816bd16076dc736562964aba65d2ae5: Bug 1487493: Remove early-beta restriction on CSS Containment (i.e. let it ride the trains to release). r=TYLin a=RyanVM
Daniel Holbert <dholbert@cs.stanford.edu> - Mon, 08 Jul 2019 21:11:54 +0000 - rev 544458
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1487493: Remove early-beta restriction on CSS Containment (i.e. let it ride the trains to release). r=TYLin a=RyanVM Differential Revision: https://phabricator.services.mozilla.com/D37303
b38ee676c48b833f5913bb16645dbb2fac927317: Bug 1563050: Treat table-cells with contain:layout as if they had no baseline. r=TYLin a=RyanVM
Daniel Holbert <dholbert@cs.stanford.edu> - Mon, 08 Jul 2019 17:41:35 +0000 - rev 544457
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1563050: Treat table-cells with contain:layout as if they had no baseline. r=TYLin a=RyanVM 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 543857
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 543440
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 543096
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 541232
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538157
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538156
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538124
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538123
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538058
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538011
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538010
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 538009
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 537742
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +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 536229
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +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 536228
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +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
fe11fc11ec5b0ee0111351c01cf601109798ca85: Bug 1548691 - Use the owned slice type for basic shape polygon coordinates. r=TYLin,heycam
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 09 May 2019 11:24:57 +0000 - rev 535087
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1548691 - Use the owned slice type for basic shape polygon coordinates. r=TYLin,heycam This enables destructors for tagged unions in cbindgen, implemented in: * https://github.com/eqrion/cbindgen/pull/333 Which allow us to properly generate a destructor for the cbindgen-generated StyleBasicShape (which now contains an OwnedSlice). For now, we still use the glue code to go from Box<BasicShape> to UniquePtr<BasicShape>. But that will change in the future when we generate even more stuff and remove all the glue. I could add support for copy-constructor generation to cbindgen for tagged enums, but I'm not sure if it'll end up being needed, and copy-constructing unions in C++ is always very tricky. Differential Revision: https://phabricator.services.mozilla.com/D29769
129dafe816e8bd27d75f0eb051f343871df5e744: Bug 1548985: Don't let 'contain:size' suppress the intrinsic size of document-root SVG elements. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Wed, 08 May 2019 23:05:04 +0000 - rev 535028
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1548985: Don't let 'contain:size' suppress the intrinsic size of document-root SVG elements. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D30259
7e12e84c87164186044c7a06a72494b469fed1a0: Bug 1508441 part 1: Adjust button reflow to suppress baseline for contain:layout, instead of for contain:size. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 26 Apr 2019 21:56:39 +0000 - rev 533708
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1508441 part 1: Adjust button reflow to suppress baseline for contain:layout, instead of for contain:size. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D28909
792aae9f893aeebd2f8e20cb4e10948278b6de75: Bug 1544121: Make size-contained replaced elements behave as if they had 0x0 intrinsic size and ratio. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Fri, 26 Apr 2019 00:18:32 +0000 - rev 533469
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1544121: Make size-contained replaced elements behave as if they had 0x0 intrinsic size and ratio. r=TYLin Spec quote from https://drafts.csswg.org/css-contain/#containment-size : "Replaced elements must be treated as having an intrinsic width and height of 0" To achieve that, we just need to: (a) make all of these frame classes' GetPrefISize and GetMinISize methods return 0 if they're styled with contain:size. (b) make all of these frame classes' GetIntrinsicSize() and GetIntrinsicRatio() methods return 0,0. In some cases, these methods are implemented in terms of common helper methods (and sometimes member variables). For those cases, this patch adjusts the helper methods (and variables) rather than the getters themselves. Also: in one case (nsHTMLCanvasFrame), I needed to update its ComputeSize method to remove a dependency on the "real" intrinsic size & ratio. I believe the other classes' ComputeSize implementations do the right thing automatically by sharing code & data with their intrinsic-size codepaths. Differential Revision: https://phabricator.services.mozilla.com/D28159
1a704e5e6a3c34f12e4a4ae8f9f02777923e6637: Bug 1547126: Give nsIFrame::IntrinsicSize a convenience constructor that takes nscoord-valued width and height. r=TYLin
Daniel Holbert <dholbert@cs.stanford.edu> - Thu, 25 Apr 2019 23:44:53 +0000 - rev 533281
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1547126: Give nsIFrame::IntrinsicSize a convenience constructor that takes nscoord-valued width and height. r=TYLin This patch shouldn't affect behavior; it's just simplifying existing code with a new convenience constructor. Differential Revision: https://phabricator.services.mozilla.com/D28918
1855d66f55a56c6e1e8dd86e3d2eb6a54f49ec8a: Bug 1546046 - Remove support for XBL resources. r=TYLin
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 23 Apr 2019 16:43:15 +0000 - rev 532492
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1546046 - Remove support for XBL resources. r=TYLin So much unsound code going away :-) Differential Revision: https://phabricator.services.mozilla.com/D28380