[Webkit-unassigned] [Bug 86182] [Qt] fast/frames/seamless/seamless-inherited-document-style.html fails

Mon May 28 16:13:14 PDT 2012

https://bugs.webkit.org/show_bug.cgi?id=86182

--- Comment #10 from Eric Seidel <eric at webkit.org>  2012-05-28 16:13:14 PST ---
This behavior is all controlled by one line in StyleResolver::styleForDocument:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/StyleResolver.cpp#L1538

Presumably, Qt (due to Widget/ScrollView/FrameView) differences, is causing the style on the document to be resolved at a time when the document does not yet know if it's seamless with its parent.  And then when it's later decided that it should be, the StyleResolver is not updated.

Someone with a Qt build could set a breakpoint on that line and see it returning "false" there when we should expect it to return true. We should figure out what the stacktrace is when that is resolved.

http://trac.webkit.org/browser/trunk/Source/WebCore/html/HTMLIFrameElement.cpp#L90
is supposed to invalidate the StyleResolver (as well as the Document node's RenderStyle) when the seamless attribute is parsed/changed, but it's possible additional invalidations are necessary to cover some case Qt is tickling here.

It's possible that fixing this FIXME:
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.cpp#L1729
could fix this bug, as it's possible that the time at which the child document's style is resolved, the parent's style is not yet resolved.  (That FIXME would just be "if (ownerElement()) ownerElement()->document()->recalcStyle(NoChange);", except that's known to cause a crash in some tests.  If someone wanted to try replacing that fixme with those two lines and running this seamless test on Qt, that data would also be useful.)

Basically, for some reason the Document's style is not being inherited in this case, yet since all the other seamless tests are passing, document's style is being inherited at other times.  Suggesting some sort of race condition in the code, improper invalidation, or other weirdness.

It's also possible that changing from srcdoc="" to src="about:blank" (or src="some_blank_page.html" in the test could fix things, as it's possible Qt's loader is somehow handling srcdoc differently.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.