I've done some testing in other browsers. In Firefox I can't see any cues at all with this input, maybe the end up off screen or something. Safari has the same behavior as we did. Edge not tested.

I'd imagine https://chromium-review.googlesource.com/c/chromium/src/+/845462 would make a difference in this case. (I suspect right now we'll just fall through a lot and not actually compute positions correctly... =/)

I've prepared a revert in https://chromium-review.googlesource.com/c/chromium/src/+/931481 in case we need it, running it through a dry run.

I haven't looked very closely at the changes yet, but given position:19% this is a non-snap-to-lines cue, so do you think the brokenness of that was exposed?

Would it make sense to revert and try to reland together with https://chromium-review.googlesource.com/c/chromium/src/+/845462, or is there a smaller piece that could be reverted?

It's position:...% - not line:...%, so it'll be a snap-to-lines cue. I think the problem is that the 'start' value of 'align' doesn't end up mapping to 'line-left' (which the CL in c#3 changes/fixes), so we end up with some form of initial values (0) for x-position.
I don't think it would make sense to revert anything smaller, but if reverting, then relanding with said CL folded in would be the reasonable (only?) thing to do.

+1 for landing it together and i assume that we will do it only after concluding https://github.com/w3c/webvtt/issues/425 which should make things even more clear.

Thanks both, I'm submitting the revert CL now.

https://chromium-review.googlesource.com/c/chromium/src/+/931481 has landed, will reopen the original bug.

verified the issue by applying the 
https://chromium-review.googlesource.com/c/chromium/src/+/845462 patch, it is working properly. 

Once https://github.com/w3c/webvtt/issues/425 is resolved from webvtt spec, i will submit one patch by combining the two patchs.

Excellent, thank you!