1169311 - tests for position:absolute with writing-mode:vertical-rl fail intermittently on Android

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Jonathan Kew [:jfkthame]]

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.

Comment 1

[Jonathan Kew [:jfkthame]]

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.

Comment 2

[Jonathan Kew [:jfkthame]]

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.

Comment 3

[Jonathan Kew [:jfkthame]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=af846c22b89d

Comment 4

[Jonathan Kew [:jfkthame]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=eeac28fc6779

Comment 5

[Jonathan Kew [:jfkthame]]

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.

Comment 6

[Jonathan Kew [:jfkthame]]

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