| Summary: | [CSS Grid layout] Initial position in span not correctly computed sometimes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Sergio Villar Senin <svillar> | ||||
| Component: | CSS | Assignee: | Sergio Villar Senin <svillar> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | darin, dino, esprehn+autocc, glenn, hyatt, jfernandez, kling, kondapallykalyan, rego, simon.fraser, svillar, webkit-ews | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Sergio Villar Senin
2014-03-12 05:24:11 PDT
Created attachment 226497 [details]
Patch
Comment on attachment 226497 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=226497&action=review > Source/WebCore/rendering/RenderGrid.cpp:1035 > const size_t* firstLineBeforeOppositePosition = std::lower_bound(gridLines.begin(), gridLines.end(), resolvedOppositePosition); > - if (firstLineBeforeOppositePosition != gridLines.end()) > + if (firstLineBeforeOppositePosition != gridLines.end()) { > + if (*firstLineBeforeOppositePosition > resolvedOppositePosition && firstLineBeforeOppositePosition != gridLines.begin()) > + --firstLineBeforeOppositePosition; > + > firstLineBeforeOppositePositionIndex = firstLineBeforeOppositePosition - gridLines.begin(); > + } Awkward. Makes me think we should put this whole thing into a helper function rather than invoking lower_bound directly in-line. > LayoutTests/fast/css-grid-layout/grid-item-named-grid-line-resolution-expected.txt:26 > +PASS > +PASS > +PASS > +PASS > +PASS > +PASS > +PASS > +PASS > +PASS > +PASS Not great test output here. Worth thinking in the future about things we can include in tests to make it clear what we are testing rather than just a lot of PASS/FAIL. Helpful in many cases, for example, when some tests are failing it helps you see which ones they are. Naming that helper function would help clarify what this code is doing at a mechanical level. (In reply to comment #2) > (From update of attachment 226497 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=226497&action=review > > LayoutTests/fast/css-grid-layout/grid-item-named-grid-line-resolution-expected.txt:26 > > +PASS > > +PASS > > +PASS > > +PASS > > +PASS > > +PASS > > +PASS > > +PASS > > +PASS > > +PASS > > Not great test output here. Worth thinking in the future about things we can include in tests to make it clear what we are testing rather than just a lot of PASS/FAIL. Helpful in many cases, for example, when some tests are failing it helps you see which ones they are. Although I agree that the output is far from optimal, in this case the testing code is the one that is very descriptive. We're using checkLayout() to check the offsets and sizes of grid items. That allows us to test with great detail the positioning of grid items. In case of error, that JS helper prints the reason why the test fails (like expected 30 for width but found 50) and also the original testing code so it's quite easy to check the reason of the failure. Committed r165612: <http://trac.webkit.org/changeset/165612> (In reply to comment #4) > that JS helper prints the reason why the test fails (like expected 30 for width but found 50) and also the original testing code so it's quite easy to check the reason of the failure. If it just printed slightly more of the same when passing, I’d be happy. When a test fails it’s good to be reminded of the similar tests that are passing. |