Summary: Inline PDF that are cached fail to appear in iframe 1) Launch Webkit revision 103908 under Mac OS X 10.7.2 and go to http://www.cs.tut.fi/~jkorpela/html/iframe-pdf.html 2) Notice inline PDFs load in the iframes 3) Press Back button to navigate away from page 4) Press forward to navigate back to page. Notice the pdf file doesn't render in iframe I have also attached a simple iframe test.
Created attachment 120895 [details] Simple iframe test that uses a inline PDF Simple iframe test that uses a inline PDF
This sounds like a regression from enabling page cache for pages with plug-ins. An assertion fails in debug builds: ASSERTION FAILED: m_frameCount + 1 == frameCount /Users/ap/Safari/OpenSource/Source/WebCore/page/Page.cpp(1058) : void WebCore::Page::checkFrameCountConsistency() const 1 0x104e0a79a WebCore::Page::checkFrameCountConsistency() const 2 0x103f59f39 WebCore::Page::frameCount() const 3 0x1045fcfa3 WebCore::HTMLPlugInImageElement::allowedToLoadFrameURL(WTF::String const&) 4 0x104596bb9 WebCore::HTMLEmbedElement::updateWidget(WebCore::PluginCreationOption)
<rdar://problem/10637392>
This is still an issue.
It looks like we miss some initialisation when we load the content with loadDifferentDocumentItem() instead of loadURL(). When the loader is changed so that it ignores the existing history item for the <iframe>, the pdf renders fine. While looking into this, I found another (somewhat related) history bug -> bug 121009
The actual reason for the blank pdf content is that when we recreate the PDFPlugin (while restoring the cached frame), we forget to re-initialize the object properly. What happens here is: 1. Initial load -> Frame loading ends up calling PDFPlugin::pdfDocumentDidLoad() which creates and initializes the pdf document using the rawData() (m_data) 2. While navigating away, we destroy the plugin renderers -> PDFPlugin object gets deleted. 3. Navigating back -> new PDFPlugin object is created but we never pass the raw data back -> no pdf document -> blank content. (When the raw data is kept around and assigned it back to the newly created PDFPlugin object, the PDF content renders fine)
WebFrameLoaderClient::m_frameCameFromPageCache does not get set to true for subframes. Patch is coming up.
Created attachment 211323 [details] Patch
Created attachment 211428 [details] Patch
Comment on attachment 211428 [details] Patch ews testing
Comment on attachment 211428 [details] Patch Clearing flags on attachment: 211428 Committed r155615: <http://trac.webkit.org/changeset/155615>
All reviewed patches have been landed. Closing bug.
This caused a lot of test flakiness, filed bug 121245. Not a fault with this patch. However, I'm also seeing the test fail sometimes locally on WK1 10.8. The actual result is white subframe instead of green. For whatever reason, bots only see fast/history/history-back-while-pdf-in-pagecache.html fail on Lion. Zalan, could you please look into this?
(In reply to comment #13) > This caused a lot of test flakiness, filed bug 121245. Not a fault with this patch. > > However, I'm also seeing the test fail sometimes locally on WK1 10.8. The actual result is white subframe instead of green. > > For whatever reason, bots only see fast/history/history-back-while-pdf-in-pagecache.html fail on Lion. > > Zalan, could you please look into this? It could be a timing issue (on history.back()). I'll look into it.
I can make it fail on Mountain Lion (locally), if I set the notifyDone timeout short enough. I suspect that this timeout value makes the testcase flaky. Unfortunately I can't confirm it on Lion. Any suggestion? (or does the bug 121245 take care of the Lion failure?)
(In reply to comment #15) > I can make it fail on Mountain Lion (locally), if I set the notifyDone timeout short enough. I suspect that this timeout value makes the testcase flaky. Unfortunately I can't confirm it on Lion. Any suggestion? Given that test bots have the opposite issue - they only see this on Lion - I'd suggest just taking care of what you can reproduce, and seeing if that helps. > (or does the bug 121245 take care of the Lion failure?) It won't, that fix only prevents PDF tests from affecting drawing in subsequent tests.
Any update on this? Turns out that Windows was also affected, until marked as failing in r156007.
(In reply to comment #17) > Any update on this? Turns out that Windows was also affected, until marked as failing in r156007. Trying to modify the testcase to make it non-flaky instead of adding new functionality to the test framework. (->internal event to signal the iframe pdf load on history back)
flaky testcase is tracked here: bug 121628