The testcases in writing-mode/abspos/s71-abs-pos-non-replaced-vrl-*.xht (but not their vlr counterparts) fail intermittently on Android. See for example the reftest oranges in https://treeherder.mozilla.org/#/jobs?repo=try&revision=0bd3d69d2ba5. In all cases, when the test fails it's because the abs-positioned element has been placed somewhat to the right of its proper position. It's as if it was placed using a containerWidth approximately twice as large as it should be. This seems to happen randomly to any of the -vrl- testcases, but when re-triggered, the same tests (or at least some random subset of them) will pass successfully.

I can reproduce what appears to be a version of this failure locally on desktop (OS X), using attachment 8610408 [details] from bug 1079151. Using a build that includes bugs 1167930, 1147834, and 1079151: Load the testcase, reduce the width of the browser window enough that one or more of the columns wraps to a new line, and then reload the testcase: often (though not invariably), most of the blue-bordered pos:abs test elements in the last two rows (with writing-mode:vertical-rl) will be rendered one column too far to the right. Repeatedly reloading the testcase shows that the failure is erratic but frequent.

The main requirement for reproducing this seems to be that a vertical scrollbar is present. Which makes me suspect it's got something to do with the repeated reflows that we do while figuring out which scrollbar(s) need to be shown.

Tryserver (and my local testing) says this is fixed by avoiding the use of blockFrame->GetSize().width in CalculateHypotheticalBox, as it won't have been set yet during the initial reflow. The result is that we get correct rendering only if a second reflow occurs, at which point the frame's width is already set. In fact, we don't need that width to convert the blockOffset value; in effect, it just serves to cancel out the containerWidth from above. I'm intending to fold the fix used in comment 4 directly into bug 1079151, as it's really an error in the patch there.

Closing this, as the fix has been incorporated into bug 1079151 prior to landing the patches there.