Bug 100141 – REGRESSION (r131680): Crash when trying to save a PDF

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Sveto]

Created attachment 170186 [details]
Crash Report

I strongly doubt the issue that was causing the crashes in r131735 has been completely resolved. More likely has been partially remedied. Now with r132210 Webkit seems to work relatively stable, but if you load let say a one page PDF in a tab and try to save it, the window below the "Save as" dialog starts reloading and although one manages to save the document, ultimately it triggers a crash. Even after the file has been saved and before the window crashes it is very easy to see how the document is been reloaded in a constant loop.

[Sveto]

To this bug might be related also a change you implemented some time ago, where with multiple tabs only the visible one is retained in cache, and if one switches to another tab it is reloaded before displaying. I don't know if is due to sandboxing or what, but boy how irritating that is and there is no other browser that behaves like this.

[Sveto]

The tab reloading seems to happen mainly for tabs that have not been visited for a while, so it keeps in a cache, I guess, some limited amount of tabs. Especially visible is this behavior if one has let say 2 windows with some 10 tabs each.

[Sveto]

The 2 problems - windows reloading and crashing when "Save as" command is used and the reloading of other tabs seem to be quite related. Here is what I experience.
I try to save the automatically generated Fedex PDF label from a .php page. As explained the tab with the PDF starts reloading below the "save as" dialogue and continues after the PDF has been saved. It eventually crashes the tab only (I see that for the first time). As a result I'm logged out of the page which provided the PDF in another tab on the same window and although I had only 2 more tabs again in the same window, each of those 3 tabs reloads when selected as if it was never in a cache.  When the tab crashed and triggered a report, the containing window, which had 3 more tabs did not close, nor did webkit altogether. This I saw for the first time. Usually the entire Webkit is crashing and closing and not only a tab in a window. That might be sandboxing working, I don't know but it is seemingly closely related to the previously described bug.

[Alexey Proskuryakov]

My testing shows that this regressed in this range: <http://trac.webkit.org/log/trunk/?rev=131682&stop_rev=131676>. r131680 looks responsible.

[Simon Fraser (smfr)]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.WebCore             	0x0000000111102534 WebCore::RenderView::usesCompositing() const + 4
1   com.apple.WebCore             	0x000000011083ebc8 WebCore::Document::windowScreenDidChange(unsigned int) + 40
2   com.apple.WebCore             	0x0000000110f76643 WebCore::Page::windowScreenDidChange(unsigned int) + 51
3   com.apple.WebKit2             	0x000000010ffba404 void CoreIPC::handleMessage<Messages::WebPage::WindowScreenDidChange, WebKit::WebPage, void (WebKit::WebPage::*)(unsigned long long)>(CoreIPC::MessageDecoder&, WebKit::WebPage*, void (WebKit::WebPage::*)(unsigned long long)) + 59

[Alexey Proskuryakov]

<rdar://problem/12559147>

[Sveto]

With r132317 the problem persists. I'm attaching the "crash report#2.txt" that was triggered by this build. It looks like it keeps reloading but with a lesser frequency. If I would go out of focus on a tab that has a .php page and than go back to that tab it immediately tries to reload and is asking if I want to submit the form data on the page. Saving a PDF triggers the attached crash report, than to end the saving it reloads again the file and the page. In general it enters into a constant loop of reloading thereafter.

[Sveto]

Created attachment 170416 [details]
crash report#2.txt

[Simon Fraser (smfr)]

New crash reports are not interesting. This hasn't been fixed yet, so it's not surprising that it's still crashing.

[Sveto]

None of the above problems exist on r131571, or at least I'm not able to reproduce. That build feels very stable compared to the latest once. So the regression must have been introduced, or some how made to trigger with changes after r131571

[Sveto]

Ok I went ahead and tested r131628 and similar to r131571 it just works rock sold. That narrows down the search to only within the changes made in r131735
It also proves my original suspicion that the big regression in r131735 has not been corrected, but somehow partially remedied.

[Simon Fraser (smfr)]

*** Bug 100293 has been marked as a duplicate of this bug. ***

[Simon Fraser (smfr)]

Created attachment 170477 [details]
Patch

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/132409