Bug 140190 – [Win] Assertions due to unexpected pageCache state

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKit Misc.

[Brent Fulgham]

The following tests fail in debug builds because the state of the pageCache is unexpected:

1. fast/loader/non-deferred-substitute-load.html

This test asserts in HistoryController::invalidateCurrentItemCachedPage because the cached page for the current time does NOT match the current frame's document.

When we are in this state, we do not remove the document from the page cache, causing the next failure.

2. fast/loader/empty-embed-src-attribute.html

fast/loader/about-blank-hash-change.html
fast/loader/about-blank-hash-kept.html
fast/loader/cancel-load-during-port-block-timer.html
fast/loader/charset-parse.html
fast/loader/child-frame-add-after-back-forward.html
fast/loader/crash-replacing-location-before-load.html
fast/loader/data-url-encoding-html.html
fast/loader/data-url-encoding-svg.html
fast/loader/display-image-unset-can-block-image-and-can-reload-in-place.html
fast/loader/document-destruction-within-unload.html
fast/loader/document-with-fragment-url-1.html
fast/loader/document-with-fragment-url-2.html
fast/loader/document-with-fragment-url-3.html
fast/loader/document-with-fragment-url-4.html
fast/loader/dynamic-iframe-extra-back-forward-item.html
fast/loader/early-load-cancel.html
fast/loader/empty-embed-src-attribute.html

This test only fails when the above list of tests is run. The assertion here is that the page being loaded is NOT already in the page cache.

[Brent Fulgham]

These tests fail for the same reason:

fast/events/keypress-insert-tab.html
fast/events/drag-parent-node.html
fast/events/mousedown-inside-dragstart-should-not-cause-crash.html
fast/events/onblur-remove.html
fast/events/change-overflow-on-overflow-change.html

[Radar WebKit Bug Importer]

<rdar://problem/19609010>

[Hyungwook Lee]

I've started look at this issue.

[Brent Fulgham]

(In reply to comment #3)
> I've started look at this issue.

Excellent!

While getting the Windows bots green, I noticed that the following tests seem to leave the page cache in a bad state, triggering this bug:

[ Debug ] editing/selection/select-all-iframe.html [ Skip ] # Causes later tests to fail
[ Debug ] fast/dom/access-key-iframe.html [ Skip ] # Causes later tests to fail with a Debug assertion.
[ Debug ] fast/dom/HTMLAnchorElement/anchor-in-noscroll-iframe.html [ Skip ] # Causes later tests to fail with a Debug assertion.
[ Debug ] fast/dom/HTMLDocument/active-element-frames.html [ Skip ] # Causes later tests to fail.
[ Debug ] fast/events/change-frame-focus.html [ Skip ] # Causes later tests to fail
[ Debug ] fast/events/keypress-focus-change.html [ Skip ] # Causes later tests to fail
[ Debug ] fast/events/mousedown-in-subframe-scrollbar.html [ Skip ] # Causes later tests to fail
[ Debug ] fast/events/onbeforeunload-focused-iframe.html [ Skip ] # Causes later tests to fail
[ Debug ] fast/events/page-scaled-mouse-click-iframe.html [ Skip ] # Causes later tests to fail

These all seem to exercise the frame and loading code, so they are probably a reasonable place to start.

[Hyungwook Lee]

In my investigation, this issue is related to queueLoadHTMLString().

When we call queueLoadHTMLString() in the page, queueLoadHTMLString() leads another page loading within same Page instance.

By this reason, we fall in crash in HistoryController::invalidateCurrentItemCachedPage()

I found that there is only two test case using queueLoadHTMLString()
1) fast/loader/non-deferred-substitute-load.html
2) http/tests/navigation/go-back-to-error-page.html

http/tests/navigation/go-back-to-error-page.html doesn't make crash that using unreachableURL.
Please see https://bugs.webkit.org/show_bug.cgi?id=52388.

Hence here is three options to fix this issue as followed.
1) Disable PageCache in DumpRenderTree
2) Disable PageCache only in non-deferred-substitute-load.html using testRunner.overridePreference("WebKitUsesPageCachePreferenceKey", 0);
3) Put unreachableURL as same as http/tests/navigation/go-back-to-error-page.html 

I think we'd better to disable PageCache in DumpRenderTree because I suspect that another port also may be disabled PageCache which didn't make crash in non-deferred-substitute-load.html.

[Brent Fulgham]

(In reply to comment #5)
> In my investigation, this issue is related to queueLoadHTMLString().
> 
> When we call queueLoadHTMLString() in the page, queueLoadHTMLString() leads
> another page loading within same Page instance.
> 
> By this reason, we fall in crash in
> HistoryController::invalidateCurrentItemCachedPage()

[...]

> I think we'd better to disable PageCache in DumpRenderTree because I suspect
> that another port also may be disabled PageCache which didn't make crash in
> non-deferred-substitute-load.html.

Thank you for looking into this!

Chris Dumez arrived at a similar conclusion a couple of days ago while debugging a new crash (Debug Assertion) in pageCache after he added a new test. See Bug 143799.

I think your analysis is correct.

Chris updated DumpRenderTree to deactivate the pageCache between runs in <http://trac.webkit.org/changeset/182844>.

I think this change will also resolve this bug, but I haven't tried since his change landed.

[Hyungwook Lee]

Thanks for your feedback.
I will move another windows port issue.

[Ahmad Saleem]

I took some sample tests from Comment 0 to see if they have any 'Windows' (win-cairo) specific expectation but it seems that it isn't the case.

Do we need to track it anymore?

Could it be 'AppleWin' specific and was resolved based on Comment 06?

[Fujii Hironori]

I don't know. But, fixed by any commit.