Created attachment 118475 [details]
If you have an element in a region with a percentage margin, and the region is followed by another region with a larger width, this affects the top margin display. If the element is displayed entirely within a single region its margins should only be affected by that single region. If an element spans regions the margins should be calculated for each segment using the local region dimensions.
In the test file it appears as if the size and margin calculations are using the widest region in the flow, then moving and clipping for display in the first region. The computed dimensions are reported as 240px by 50px with a 30px margin, but the displayed dimensions are 160px by 50px with left and right margins of 20px and a top margin of 30px. For this testfile I'd expect the displayed dimensions but with an overall margin of 20px.
Still repros on today's nightly (r151543)
Taking a look at this.
I have been debugging this, and found that during the layout stage, the computed values of the margins end up being 30px (left, right and top). If you use the web inspector, those are the reported values. However, as Alan says in comment 0, the displayed margins are 20px.
It is in the paint stage where the left and right margins get the 20px values they display, in the WebCore::RenderBox::borderBoxRectInRegion method. However, in that place the top margin is not updated.
I talked to Mihnea and he warned me that since at this point margins are/can be collapsed (http://www.w3.org/TR/CSS2/box.html#collapsing-margins), it can be complicated / impossible to simply update the top-margin there.
I am still trying to see if there's something we can do about the top margin (which doesn't break existing behaviour), but feel free to comment if you have some ideas or suggestions.
My feeling is that trying to fix this behaviour so that we actually compute the correct margins in the layout stage would be quite complicated and would require many changes, but I might be missing something.