In particular, this is because nsComputedDOMStyle::UpdateCurrentStyleSources makes no attempt to set mInnerFrame and mOuterFrame when mPseudo is non-null.
I believe Emilio mentioned verbally that Chrome behaves differently from us, i.e., it does return layout-based computed styles for pseudo-elements.

Yup, it does.
I'm interested in adding an API to get a given generated content pseudo for an element. We need it for stylo to handle properly restyles of ::before and ::after with display: contents elements (we use the frame tree to get it for other elements, but that's a no-go for display: contents), so I'll probably give this a shot too on the way.

Confirmed that Chrome reports 50px, as does Safari. Edge reports 50%, though. The CSSOM spec doesn't treat ::before / ::after computed style any differently from regular elements. So I think it makes sense to make this change.

So, the reason I thought we couldn't use it was display: contents stuff, because we didn't have a real _parent_ frame.
But looking at the frame constructor and restyle manager stuff, giving the closest ancestor parent frame will work. I find this more elegant that walking up the frame tree, but I guess I can do that too.

So, I'm pushing back on this one, sorry Cameron.
There are a lot of places that assume that an element must have a frame to have pseudos, which is wrong. This patch fixes it, in a few places, and simplifies a lot of that code.
Also, right now there are only one remaining accessor of nsIFrame::GenConProperty(). I tried to remove it, but that check is hiding a bug when display: contents is used inside a fieldset, so I preferred to keep it for now and address it in a followup.
I also tried to fix nsLayoutUtils::IsGeneratedContentFor (because right now it's bogus, see bug 1251799), but that's hiding even more bugs and needs a more elaborate fix, so I'll look into it in a followup too.

I think I want to land this with the two test expectation changes for animations in stylo, since it's directly related to us now using the frame style, and is only exposing the fact that we were not correctly updating the frame style in the first place, which I intend to fix in bug 1331047.

Comment on attachment 8858762[details]Bug 1355351: Look for the frame for ::before and ::after pseudos.
https://reviewboard.mozilla.org/r/130802/#review136078
::: layout/style/nsComputedDOMStyle.cpp:718
(Diff revision 2)
> +static bool
> +HasToReResolveStyle(const nsStyleContext* aContext)
Please add some comments in here describing what the point of these checks are.
Small nit: "MustReresolveStyle" sounds a bit better to me. (I can see a bunch of other functions named "MustDoWhatever", but no "HaveTo"/"HasTo".)
::: layout/style/nsComputedDOMStyle.cpp:730
(Diff revision 2)
> + return aContext->GetParent() &&
> + aContext->GetParent()->HasPseudoElementData();
This one I don't quite get. Why are we not just checking for ::before / ::after specifically, and returning false in that case?

Comment on attachment 8858762[details]Bug 1355351: Look for the frame for ::before and ::after pseudos.
https://reviewboard.mozilla.org/r/130802/#review136078> Please add some comments in here describing what the point of these checks are.
>
> Small nit: "MustReresolveStyle" sounds a bit better to me. (I can see a bunch of other functions named "MustDoWhatever", but no "HaveTo"/"HasTo".)
Ok, will change the name and add a comment.
> This one I don't quite get. Why are we not just checking for ::before / ::after specifically, and returning false in that case?
The point of that check is to re-resolve the style if the style context is inside a ::first-line frame, for example, so the computed style doesn't include ::first-line styles.
That's why we need that check. See bug 505515.