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. ***
This no longer reproduces.