return { top, left }; -> return { left, top }; This is so error prone and should find a way to enforce left/top vs. top/left.
Created attachment 342785 [details] Patch
Comment on attachment 342785 [details] Patch Attachment 342785 [details] did not pass gtk-wk2-ews (gtk-wk2): Output: http://webkit-queues.webkit.org/results/8195225 New failing tests: http/tests/misc/char-encoding-bocu-1-blacklisted.html
Created attachment 342802 [details] Archive of layout-test-results from ltilve-gtk-wk2-ews for gtk-wk2 The attached test failures were seen while running run-webkit-tests on the gtk-wk2-ews. Bot: ltilve-gtk-wk2-ews Port: gtk-wk2 Platform: Linux-4.16.0-0.bpo.1-amd64-x86_64-with-debian-9.4
Comment on attachment 342785 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=342785&action=review > Source/WebCore/ChangeLog:8 > + In visual formatting model, we normally go like [top, left] while LayoutPoint takes [x, y]. Let's make this less error prone. Couldn't we use [left, top] [x, y] consistently?
Comment on attachment 342785 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=342785&action=review > Source/WebCore/layout/FormattingContext.h:86 > + LayoutUnit y; // top > + LayoutUnit x; // left Maybe we could have something like LayoutUnit<Vertical> and LayoutUnit<Horizontal> so mixing would require explicit conversions?
(In reply to Antti Koivisto from comment #5) > Comment on attachment 342785 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=342785&action=review > > > Source/WebCore/layout/FormattingContext.h:86 > > + LayoutUnit y; // top > > + LayoutUnit x; // left > > Maybe we could have something like LayoutUnit<Vertical> and > LayoutUnit<Horizontal> so mixing would require explicit conversions? Great idea. Yeah, we should do something like that.
Committed r232876: <https://trac.webkit.org/changeset/232876>
<rdar://problem/41161567>