Bug 159294

Summary: [css-grid] Handle min-content/max-content with orthogonal flows
Product: WebKit Reporter: Javier Fernandez <jfernandez>
Component: Layout and RenderingAssignee: Javier Fernandez <jfernandez>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, darin, esprehn+autocc, glenn, hyatt, jfernandez, kondapallykalyan, rego, simon.fraser, svillar
Priority: P2 Keywords: BlinkMergeCandidate
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 60731, 159295    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Missing layout tests
none
Missing Layout tests
none
Missing Layout tests none

Javier Fernandez
Reported Thursday, June 30, 2016 11:53:26 AM UTC
Grid Layout does not support orthogonal flows cases. It's not only the grid items are not aligned properly, but tracks are sizing incorrectly as well.
Attachments
Patch (86.71 KB, patch)
2016-06-30 04:03 PDT, Javier Fernandez
no flags
Patch (86.71 KB, patch)
2016-07-14 10:38 PDT, Javier Fernandez
no flags
Patch (35.67 KB, patch)
2016-07-14 15:28 PDT, Javier Fernandez
no flags
Missing layout tests (52.05 KB, patch)
2016-07-21 02:46 PDT, Javier Fernandez
no flags
Missing Layout tests (50.61 KB, patch)
2016-07-21 02:53 PDT, Javier Fernandez
no flags
Missing Layout tests (50.56 KB, patch)
2016-07-21 04:05 PDT, Javier Fernandez
no flags
Javier Fernandez
Comment 1 Thursday, June 30, 2016 12:03:25 PM UTC
Darin Adler
Comment 2 Wednesday, July 13, 2016 5:16:57 PM UTC
Comment on attachment 282429 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=282429&action=review > Source/WebCore/rendering/RenderGrid.cpp:245 > + void nextState() A function like this that creates side effects and has no return value should normally have a verb phrase as its name, not a noun phrase. So instead of "next state" it would be "advance to next state", or anything else that is a verb, not a noun. > Source/WebCore/rendering/RenderGrid.cpp:264 > + bool isValidTransitionForDirection(GridTrackSizingDirection direction) Not sure this needs "for direction" in its name, although I suppose it’s OK. > Source/WebCore/rendering/RenderGrid.cpp:268 > + return direction == ForColumns ? true : false; No need for the no-op "? true : false". > Source/WebCore/rendering/RenderGrid.cpp:270 > + return direction == ForRows ? true : false; Ditto. > Source/WebCore/rendering/RenderGrid.cpp:276 > + return direction == ForRows ? true : false; Ditto. > Source/WebCore/rendering/RenderGrid.h:208 > + bool m_hasAnyOrthogonalChild; I’m a little concerned that the lifetime of this data member is tricky. It’s valid only after placeItemsOnGrid is called. Is there an obvious guarantee that repeatTracksSizingIfNeeded is only called after placeItemsOnGrid?
Manuel Rego Casasnovas
Comment 3 Thursday, July 14, 2016 7:23:28 AM UTC
Comment on attachment 282429 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=282429&action=review >> Source/WebCore/rendering/RenderGrid.h:208 >> + bool m_hasAnyOrthogonalChild; > > I’m a little concerned that the lifetime of this data member is tricky. It’s valid only after placeItemsOnGrid is called. Is there an obvious guarantee that repeatTracksSizingIfNeeded is only called after placeItemsOnGrid? A quick idea would be to use an ASSERT(!m_gridIsDirty); in RenderGrid::repeatTracksSizingIfNeeded(). Also maybe it's worth to reset m_hasAnyOrthogonalChild in RenderGrid::clearGrid().
Javier Fernandez
Comment 4 Thursday, July 14, 2016 6:23:22 PM UTC
(In reply to comment #3) > Comment on attachment 282429 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=282429&action=review > > >> Source/WebCore/rendering/RenderGrid.h:208 > >> + bool m_hasAnyOrthogonalChild; > > > > I’m a little concerned that the lifetime of this data member is tricky. It’s valid only after placeItemsOnGrid is called. Is there an obvious guarantee that repeatTracksSizingIfNeeded is only called after placeItemsOnGrid? > > A quick idea would be to use an ASSERT(!m_gridIsDirty); in > RenderGrid::repeatTracksSizingIfNeeded(). I like this idea. > > Also maybe it's worth to reset m_hasAnyOrthogonalChild in > RenderGrid::clearGrid(). I think there is no need to clear the value, as it's initialized every time the placeItemsOnGrid function is called.
Javier Fernandez
Comment 5 Thursday, July 14, 2016 6:25:28 PM UTC
(In reply to comment #2) > Comment on attachment 282429 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=282429&action=review > > > Source/WebCore/rendering/RenderGrid.cpp:245 > > + void nextState() > > A function like this that creates side effects and has no return value > should normally have a verb phrase as its name, not a noun phrase. So > instead of "next state" it would be "advance to next state", or anything > else that is a verb, not a noun. > > > Source/WebCore/rendering/RenderGrid.cpp:264 > > + bool isValidTransitionForDirection(GridTrackSizingDirection direction) > > Not sure this needs "for direction" in its name, although I suppose it’s OK. > > > Source/WebCore/rendering/RenderGrid.cpp:268 > > + return direction == ForColumns ? true : false; > > No need for the no-op "? true : false". > > > Source/WebCore/rendering/RenderGrid.cpp:270 > > + return direction == ForRows ? true : false; > > Ditto. > > > Source/WebCore/rendering/RenderGrid.cpp:276 > > + return direction == ForRows ? true : false; > > Ditto. > > > Source/WebCore/rendering/RenderGrid.h:208 > > + bool m_hasAnyOrthogonalChild; > > I’m a little concerned that the lifetime of this data member is tricky. It’s > valid only after placeItemsOnGrid is called. Is there an obvious guarantee > that repeatTracksSizingIfNeeded is only called after placeItemsOnGrid? As rego suggested, I'll add an ASSERT to be sure the grid is not dirty, hence the placeItemsOnGrid completed its execution.
Javier Fernandez
Comment 6 Thursday, July 14, 2016 6:38:55 PM UTC
Javier Fernandez
Comment 7 Thursday, July 14, 2016 11:28:26 PM UTC
WebKit Commit Bot
Comment 8 Friday, July 15, 2016 12:34:02 AM UTC
Comment on attachment 283692 [details] Patch Clearing flags on attachment: 283692 Committed r203252: <http://trac.webkit.org/changeset/203252>
WebKit Commit Bot
Comment 9 Friday, July 15, 2016 12:34:07 AM UTC
All reviewed patches have been landed. Closing bug.
Javier Fernandez
Comment 10 Thursday, July 21, 2016 10:41:17 AM UTC
The last patch I've submitted for landing didn't have the layout tests, which were already reviewed in the first patch. I'll reopen this bug to land the tests.
Javier Fernandez
Comment 11 Thursday, July 21, 2016 10:46:10 AM UTC
Created attachment 284200 [details] Missing layout tests This patch complements the previous one, which somehow didn't contain the proper layout tests.
Javier Fernandez
Comment 12 Thursday, July 21, 2016 10:53:05 AM UTC
Created attachment 284201 [details] Missing Layout tests
WebKit Commit Bot
Comment 13 Thursday, July 21, 2016 11:51:49 AM UTC
Comment on attachment 284201 [details] Missing Layout tests Rejecting attachment 284201 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'validate-changelog', '--check-oops', '--non-interactive', 284201, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in LayoutTests/ChangeLog is not at the top of the file. Full output: http://webkit-queues.webkit.org/results/1723440
Javier Fernandez
Comment 14 Thursday, July 21, 2016 12:05:12 PM UTC
Created attachment 284204 [details] Missing Layout tests
WebKit Commit Bot
Comment 15 Thursday, July 21, 2016 12:37:06 PM UTC
Comment on attachment 284204 [details] Missing Layout tests Clearing flags on attachment: 284204 Committed r203501: <http://trac.webkit.org/changeset/203501>
WebKit Commit Bot
Comment 16 Thursday, July 21, 2016 12:37:12 PM UTC
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.