Bug 19249 – Assertion failure in FrameView::scheduleRelayout() (m_frame->view() == this) clicking an image from the Phoenix Mars mission

• Component: Layout and Rendering
• Status: RESOLVED FIXED

Clicking a thumbnail in the URL leads to

ASSERTION FAILED: m_frame->view() == this
(/WebCore/page/FrameView.cpp:778 void WebCore::FrameView::scheduleRelayout())

I think the key is Document::updateDocumentsRendering() in the backtrace. The old document has changed children but it is no longer in the frame, so it should not update. Perhaps the function that puts a document into the page cache should take it out of the changedDocuments set.

The bug doesn't happen when the back/forward cache is disabled.

The URL is already dead and I cannot reproduce with other image galleries on the site :-(

(In reply to comment #2)
> I cannot reproduce with other image galleries on the site :-(

Turns out disabling the back/forward cache is a sticky setting :-)
I can reproduce with other galleries. URL updated.

Created attachment 21345 [details]
Reduction (save as a file and open; will ASSERT)

While the page is in the back/forward cache, the link changes to visited, which changes the document and triggers a style recalc in the cached document.

Comment on attachment 21345 [details]
Reduction (save as a file and open; will ASSERT)

Note: the reduction doesn't work when served over https from Bugzilla, because secure pages never enter the page cache.

The issue appears to be more general: a script can hold a reference to a document in the back/forward cache and modify it, requiring relayout.

Created attachment 21350 [details]
Reduction without visited links (will ASSERT)

An example of the same problem with a script modifying a document in the back/forward cache. A script can conceivably retroactively make the page ineligible for the back/forward cache, too.

<rdar://problem/5963470>

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

[Brady Eidson]

This no longer reproduces.