Created attachment 162299 [details] Reproduces the problem. This issue repros easily when repainting selections in a table with sub-pixel offsets, but can likely occur elsewhere. The issue arrises due to repainting being triggered outside of normal paint or layout flow, and thus missing the context from the containing block chain, which leads to differing pixel-snapping. Eventually, I think this should be fixed by preserving the context during layout in something like a FractionalBoxExtent.
Created attachment 162327 [details] Patch
Comment on attachment 162327 [details] Patch Attachment 162327 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13764581 New failing tests: fast/repaint/repaint-across-writing-mode-boundary.html
Comment on attachment 162327 [details] Patch LGTM
I wonder if this will fix bug 94128.
Committed r128346: <http://trac.webkit.org/changeset/128346>
(In reply to comment #2) > (From update of attachment 162327 [details]) > Attachment 162327 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/13764581 > > New failing tests: > fast/repaint/repaint-across-writing-mode-boundary.html Just as it did on cr-ews, this is failing on the chromium bots: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Frepaint%2Frepaint-across-writing-mode-boundary.html Levi, can you take a look?
Thanks for the heads up. Fixing now.