Able to reproduce this issue on Windows 10, Mac OS 10.13.3, Ubuntu 14.04 on the latest Canary 68.0.3436.0 and latest Stable 66.0.3359.181 as per the original comment.

Bisect Information:
===================
Good Build: 61.0.3143.0
Bad Build : 61.0.3144.0

By running the per-revision bisect script, below is the Changelog URL.

https://chromium.googlesource.com/chromium/src/+log/93846275952fa28f83a4ea318e56c4f494bf7005..334b4846828ceb697785b466619a1f1b96592a3b

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/548379

As rune@opera.com and meade@chromium.org are not in use anymore, assigning the bug to the reviewer.
mstensho@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks

rune@opera.com -> futhark@chromium.org

The expected behavior in the description is wrong as the spec clearly says that the writing mode of the root (html) element is not affected by the body writing-mode[1], so the two iframes in the test case are clearly different.

However, we render this differently from Gecko. Gecko renders the vertical-rl body on the left side of the horizontal-tb html element, while Blink renders it to the right. I suspect Gecko is right about it since it looks like positioning the box with the orthogonal flow within its container is done according to the writing-mode of the container[1]. If this difference is a bug in Blink, it is a layout issue, I think.

[1] https://drafts.csswg.org/css-writing-modes-3/#principal-flow
[2] https://www.w3.org/TR/css-writing-modes-3/#orthogonal-flows

Gecko's bug about "writing-mode: vertical-rl" applied to a body element is https://bugzilla.mozilla.org/show_bug.cgi?id=1102175

I was wrong about "the principal writing mode is not taken from a body element." In https://jsfiddle.net/agc3zjcz/ the values of `left` and `bottom` are ignored since they are over-constrained. So, the writing-mode of the initial containing block will be `vertical-rl`, which is taken from the body element.

However, I still think current Blink's behavior is something unexpected.

css-writing-modes-3 chapter 8 says:

> Note that this does not affect the values of writing-mode or direction on the root element itself.

I think this sentence means that the result of `window.getComputedStyle(document.documentElement).writingMode` is not affected by the writing-mode of a body element, as Koji Ishii said in review[1][2].

[1] https://chromium-review.googlesource.com/c/chromium/src/+/548379#message-a11ea5acd18a4e71a9c516df1a9bda999e7d9ce5
> There should be no difference whether author sets writing-mode to html or body

[2] https://chromium-review.googlesource.com/c/chromium/src/+/548379#message-65020cacbb47a82cf52947e33131203ff0a343af
> "No difference" I meant "no difference other than computed value of html element.

That's not what the spec says (getComputedStyle). The spec may be unexpected, but our implementation follows what the spec and Gecko does wrt propagation. You can try to bring this up as a spec issue again, but I'll close this as wontfix now.

Regarding comment #4, after discussing with mstensho, we concluded Gecko is wrong.