<rdar://problem/11538352>

Added expected failing results in http://trac.webkit.org/changeset/118588

This is very strange. fast/frames/seamless/seamless-basic.html - This is the dynamic update test failing: http://trac.webkit.org/browser/trunk/LayoutTests/fast/frames/seamless/seamless-basic.html#L26 - Which suggests that somehow the layout() isn't occurring properly after the change. http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderIFrame.cpp#L163 fast/frames/seamless/seamless-css-cascade.html http://trac.webkit.org/browser/trunk/LayoutTests/fast/frames/seamless/seamless-css-cascade.html http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r118566%20(24163)/fast/frames/seamless/seamless-css-cascade-pretty-diff.html - This is possibly related to bug 86182. In this case it looks like the inner document has never inherited the styles from the outer. Possibly because the inner document is attached before the styles are resolved on the outer document? And then the inner document's style is not recalculated when the outer ones is? It's possible that I'm missing some style invalidation inside HTMLIFrameElement, but I would have expected this line of code to do the trick: http://trac.webkit.org/browser/trunk/Source/WebCore/html/HTMLIFrameElement.cpp#L128 It's possible I'm mssing a call to the superclass in that function? fast/frames/seamless/seamless-form-get-named.html fast/frames/seamless/seamless-form-get.html fast/frames/seamless/seamless-form-post-named.html fast/frames/seamless/seamless-form-post.html fast/frames/seamless/seamless-hyperlink-named.html fast/frames/seamless/seamless-hyperlink.html fast/frames/seamless/seamless-inherited-document-style.html fast/frames/seamless/seamless-window-location-href.html fast/frames/seamless/seamless-window-location-sandbox.html fast/frames/seamless/seamless-window-location.html fast/frames/seamless/seamless-window-open.html Those all look like seamless navigation is just failing (possibly due to Win-only loader differences?) Dr. Barth may know more. http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r118566%20(24163)/results.html

I'd have to look at the tests more closely to see if there's a pattern about which ones fail. It's surprising that they would work differently on Windows though.

Perhaps there is a more generic trouble of some sort of race around computing the "can we be seamless" bit. Donno.

That would be consistent with the results of those navigation tests, which (on the surface) show navigation occurring as if seamless wasn't active.

After further investigation, these tests are failing because ENABLE_IFRAME_SEAMLESS is somehow off on Windows. I guess I set it wrong in FeatureDefines.vsprops? http://trac.webkit.org/browser/trunk/WebKitLibraries/win/tools/vsprops/FeatureDefines.vsprops#L134 The reason why more tests didn't fail is because ENABLE_IFRAME_SEAMLESS was not properly disabling seamless all the way. I've fixed that in bug 87646.

It could also be the the Win builders just didn't properly rebuild when the vsprops file was changed? Do we know if visual studio will correctly notice those dependency changes?

(In reply to comment #8) > It could also be the the Win builders just didn't properly rebuild when the vsprops file was changed? Do we know if visual studio will correctly notice those dependency changes? Looks like it wasn't enabled properly in FeatureDefines.vsprops. I have a fix for that, I am just waiting to see if this entirely fixes the tests or if there are still issues.

Fixed in http://trac.webkit.org/changeset/118817