Bug 87543
Summary: | [Win] ~1/2 of all the iframe seamless tests fail | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jessie Berlin <jberlin> |
Component: | Frames | Assignee: | Eric Seidel (no email) <eric> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | abarth, jberlin, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar, LayoutTestFailure |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | Windows 7 | ||
URL: | http://build.webkit.org/results/Windows%207%20Release%20(WebKit2%20Tests)/r118550%20(18596)/results.html | ||
Bug Depends on: | |||
Bug Blocks: | 45950 |
Jessie Berlin
First noticed on r118555
fast/frames/seamless/seamless-basic.html
--- /home/buildbot/slave/win-release-tests-wk2/build/layout-test-results/fast/frames/seamless/seamless-basic-expected.txt 2012-05-25 03:11:10.442730500 -0700
+++ /home/buildbot/slave/win-release-tests-wk2/build/layout-test-results/fast/frames/seamless/seamless-basic-actual.txt 2012-05-25 03:11:10.441730400 -0700
@@ -3,6 +3,6 @@
PASS window.getComputedStyle(iframe).display is "block"
PASS window.getComputedStyle(iframe).width is "200px"
PASS window.getComputedStyle(iframe).height is "100px"
-PASS window.getComputedStyle(iframe).height is "200px"
+FAIL window.getComputedStyle(iframe).height should be 200px. Was 100px.
PASS window.getComputedStyle(iframe).width is "100px"
fast/frames/seamless/seamless-css-cascade.html
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
I will check in the failing expected results for now
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/11538352>
Jessie Berlin
Added expected failing results in http://trac.webkit.org/changeset/118588
Eric Seidel (no email)
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
Adam Barth
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.
Eric Seidel (no email)
Perhaps there is a more generic trouble of some sort of race around computing the "can we be seamless" bit. Donno.
Adam Barth
That would be consistent with the results of those navigation tests, which (on the surface) show navigation occurring as if seamless wasn't active.
Eric Seidel (no email)
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.
Eric Seidel (no email)
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?
Jessie Berlin
(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.
Jessie Berlin
Fixed in http://trac.webkit.org/changeset/118817