WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
159294
[css-grid] Handle min-content/max-content with orthogonal flows
https://bugs.webkit.org/show_bug.cgi?id=159294
Summary
[css-grid] Handle min-content/max-content with orthogonal flows
Javier Fernandez
Reported
2016-06-30 03:53:26 PDT
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
Details
Formatted Diff
Diff
Patch
(86.71 KB, patch)
2016-07-14 10:38 PDT
,
Javier Fernandez
no flags
Details
Formatted Diff
Diff
Patch
(35.67 KB, patch)
2016-07-14 15:28 PDT
,
Javier Fernandez
no flags
Details
Formatted Diff
Diff
Missing layout tests
(52.05 KB, patch)
2016-07-21 02:46 PDT
,
Javier Fernandez
no flags
Details
Formatted Diff
Diff
Missing Layout tests
(50.61 KB, patch)
2016-07-21 02:53 PDT
,
Javier Fernandez
no flags
Details
Formatted Diff
Diff
Missing Layout tests
(50.56 KB, patch)
2016-07-21 04:05 PDT
,
Javier Fernandez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Javier Fernandez
Comment 1
2016-06-30 04:03:25 PDT
Created
attachment 282429
[details]
Patch
Darin Adler
Comment 2
2016-07-13 09:16:57 PDT
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
2016-07-13 23:23:28 PDT
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
2016-07-14 10:23:22 PDT
(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
2016-07-14 10:25:28 PDT
(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
2016-07-14 10:38:55 PDT
Created
attachment 283659
[details]
Patch
Javier Fernandez
Comment 7
2016-07-14 15:28:26 PDT
Created
attachment 283692
[details]
Patch
WebKit Commit Bot
Comment 8
2016-07-14 16:34:02 PDT
Comment on
attachment 283692
[details]
Patch Clearing flags on attachment: 283692 Committed
r203252
: <
http://trac.webkit.org/changeset/203252
>
WebKit Commit Bot
Comment 9
2016-07-14 16:34:07 PDT
All reviewed patches have been landed. Closing bug.
Javier Fernandez
Comment 10
2016-07-21 02:41:17 PDT
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
2016-07-21 02:46:10 PDT
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
2016-07-21 02:53:05 PDT
Created
attachment 284201
[details]
Missing Layout tests
WebKit Commit Bot
Comment 13
2016-07-21 03:51:49 PDT
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
2016-07-21 04:05:12 PDT
Created
attachment 284204
[details]
Missing Layout tests
WebKit Commit Bot
Comment 15
2016-07-21 04:37:06 PDT
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
2016-07-21 04:37:12 PDT
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.
Top of Page
Format For Printing
XML
Clone This Bug