Now, iframe2.html actually started working "correctly" (read: as Firefox) after that change.

Deleted: iframe2.html 443 bytes

iframe2.html 443 bytes View Download

Attached failing test where explicitly changing from display:none -> display:inline on iframe from a clean state.

Deleted: iframe3.html 506 bytes

iframe3.html 506 bytes View Download

Hah, I was about to report this today while I was touching the firefox code that deals with this: https://bugzilla.mozilla.org/show_bug.cgi?id=1443483

Note that there's nothing in Document::NeedsLayoutTreeUpdateForNode that walks up the document chain, so I'm not sure how this could ever work, even with DisplayNoneIFrameCreatesNoLayoutObject disabled.

Testcase that fails in Firefox (but passes if you use frm.contentWindow.getComputedStyle instead).

Arg, cross-doc computed style is such a mess... Will file one for this one :)

Deleted: t.html 752 bytes

t.html 752 bytes View Download

Thanks Emilio!

So, I wrote wpt for this:

https://chromium-review.googlesource.com/c/chromium/src/+/951248

Chime in if you think I should've used frm.contentWindow.getComputedStyle.

Oh my. Seeing https://github.com/w3c/csswg-drafts/issues/2403 and the spec, I should really change those tests.

Well, your tests only check stuff set by the style attribute, so I suspect they match the spec.

But yeah, all the getComputedStyle stuff for any kind of edge case (included cross-doc) is super-broken, see the linked issues from that one.

Note that in https://bugzilla.mozilla.org/show_bug.cgi?id=1443492 I submitted a patch that will test something that doesn't match the spec (pointing to that issue).

Let me know if you think it should not be in WPT though.

Using contentWindow.getComputedStyle() actually made another test start failing in Firefox nightly ...

Huh, which one? If it's returning null in a display: none iframe, it is expected, unfortunately: https://bugzilla.mozilla.org/show_bug.cgi?id=548397

@emilio: yes, display:none. I've removed the test parts which was relying on undefined behavior for computed style inside display:none iframes now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/52bbe5980872c9232085b4b281f49e283936964c

commit 52bbe5980872c9232085b4b281f49e283936964c
Author: Rune Lillesveen <futhark@chromium.org>
Date: Sat Mar 10 10:17:51 2018

Computed style inside iframe depends on parent layout.

Make sure we layout the parent document when it's dirty.

Bug:  819189 
Change-Id: I3835aa913e20abdd4adaab072567191b3ca25c20
Reviewed-on: https://chromium-review.googlesource.com/951248
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542372}
[add] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/LayoutTests/external/wpt/css/cssom/computed-style-002.html
[add] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/LayoutTests/external/wpt/css/cssom/computed-style-003.html
[add] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/LayoutTests/external/wpt/css/cssom/computed-style-004.html
[modify] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/Source/build/scripts/core/css/properties/templates/CSSProperty.h.tmpl
[modify] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/Source/build/scripts/core/css/properties/templates/CSSPropertySubclass.h.tmpl
[modify] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/Source/core/css/CSSComputedStyleDeclaration.cpp
[modify] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/Source/core/css/CSSProperties.json5
[modify] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/Source/core/css/StyleEngine.h
[modify] https://crrev.com/52bbe5980872c9232085b4b281f49e283936964c/third_party/WebKit/Source/core/css/properties/CSSPropertyMethods.json5

Why wasn't the fix merged to Chrome 65/66 as the bug was introduced in 65?

This issue was reported by an internal developer (me) without any known real world reports, so I did not consider it important enough compared to the risk of causing other regressions by introducing the fix on branches closer to release.

 Issue 825726  says the bug has broken Sencha Touch applications.

 Issue 825726  has been merged into this issue.

Any hopes of getting this released sooner on Chrome 66? I just found another bug in my Sencha Touch app that happens on 65 and not on 64, and this time I can't work around it. Chances are it's the same underlying cause.
Cheers

Still an issue on Chrome 66.

Yes, the fix was committed in v67 and wasn't backported so it's present only in Chrome 67+.

Confirmed fixed on Chrome 67 for desktop, Sencha Touch applications are now functional on desktop. Still waiting for Play Store release of Android System WebView