Refactor the current text position update in SVGTextLayoutEngine

third_party/WebKit/LayoutTests/TestExpectations

Index: third_party/WebKit/LayoutTests/TestExpectations
diff --git a/third_party/WebKit/LayoutTests/TestExpectations b/third_party/WebKit/LayoutTests/TestExpectations
index 4749007738b89e04abd2c3e42566be0701def8d3..5bab613ef186143d93541024475a170773d85c82 100644
--- a/third_party/WebKit/LayoutTests/TestExpectations
+++ b/third_party/WebKit/LayoutTests/TestExpectations
@@ -107,6 +107,9 @@ crbug.com/502531 fast/borders/border-antialiasing.html [ Failure ]
 crbug.com/538697 [ Win7 Debug ] virtual/threaded/printing/webgl-oversized-printing.html [ Crash ]
 crbug.com/538697 [ Win7 Debug ] printing/webgl-oversized-printing.html [ Crash ]
 
+crbug.com/486669 svg/batik/text/textOnPath2.svg [ NeedsRebaseline ]

[pdr., 2016/04/14 01:05:51]

Can you double-check that this isn't a regression? It's hard to say what should
happen here, but the new behavior differs from the batik expectations.

[fs, 2016/04/14 08:56:42]

I have, and I think this is a progression. (In my reading of the spec,
text-on-a-path layout should not have any effect on the current text position.
The new rendering/behavior matches Gecko [and Presto - so, yes, I'm biased...])

[fs, 2016/04/14 09:04:43]

(I should probably also mention the "ulterior motives", which is to avoid
fragmentation for text-paths [or at least do it as a deferred pass] to be able
to better support BiDi - and possibly even let Skia do the path-mapping [which
would allow us to support 'stretch' somewhat efficiently.])

+crbug.com/486669 svg/batik/text/verticalTextOnPath.svg [ NeedsRebaseline ]
+
 # Expected to fail until OffscreenCanvas can render on the gpu
 crbug.com/593514 virtual/gpu/fast/canvas/OffscreenCanvas-strokeRect-in-worker.html [ Failure ]
 crbug.com/593514 virtual/gpu/fast/canvas/OffscreenCanvas-paths-in-worker.html [ Failure ]