Due to ScrollView::visibleContentRect having different semantics on RTL pages than on LTR ones (width of the visibleContentRect goes towards negative x instead of towards positive x), RTL pages don't render properly when accelerated compositing is turned on in the Chromium compositor. There are some other assumptions in LayerTilerChromium and in TilingData where pages are only assumed to grow right and down instead of potentially growing left and down instead.
Created attachment 99403 [details]
Comment on attachment 99403 [details]
Clearing review flag since this needs some mergin' love now that the edge AA patch has landed.
There's a Chromium-OS bug related to this issue : http://crosbug.com/20666
Created attachment 120982 [details]
Attachment 120982 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/update-webkit']" exit_code: 9
Index mismatch: 3a7674dadd24ecd6a1b023eba203ecf2ed62fc59 != edb861612940a3244431d239dacdbc36317b627c
103950 = 8282a1d85ad097ce4064a5896912bdb211b115e6 already exists! Why are we refetching it?
at /usr/lib/git-core/git-svn line 5210
Died at Tools/Scripts/update-webkit line 158.
If any of these errors are false positives, please file a bug against check-webkit-style.
(In reply to comment #5)
> Attachment 120982 [details] did not pass style-queue:
> Failed to run "['Tools/Scripts/update-webkit']" exit_code: 9
I wonder if the git mirror needs to be kicked. Mine seems stuck at r103949 and these errors are files in r103950.
Comment on attachment 120982 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=120982&action=review
Sweet! That's so easy.
> +void NonCompositedContentHost::paintContents(const WebCore::GraphicsLayer* graphicsLayer, WebCore::GraphicsContext& context, WebCore::GraphicsLayerPaintingPhase, const WebCore::IntRect& clipRect)
nit: no need to name the graphicsLayer parameter here
Committed r103968: <http://trac.webkit.org/changeset/103968>