Title: [113379] trunk/Source/WebCore
- Revision
- 113379
- Author
- [email protected]
- Date
- 2012-04-05 14:15:01 -0700 (Thu, 05 Apr 2012)
Log Message
<rdar://problem/9359029> and https://bugs.webkit.org/show_bug.cgi?id=83311 Crashes in WebProcess at WebCore::HistoryController::recursiveSetProvisionalItem when restoring previous session
Reviewed by Sam Weinig.
It's possible to hit a race condition between the UIProcess and the WebProcess where the UIProcess records for a
page have been cleared out but the WebProcess is still trying to perform a history navigation within that page.
In this situation HistoryController code that expects there to always be a current history item in the back/forward
controller is wrong.
No new tests. (The race conditions involved have proven making a test impractical)
* loader/HistoryController.cpp:
(WebCore::HistoryController::recursiveSetProvisionalItem): Don't ASSERT the fromItem. We now know there might not be one.
(WebCore::HistoryController::recursiveGoToItem): Ditto
(WebCore::HistoryController::itemsAreClones): Always return false if either item is null, as a null item and a non-null
item cannot possible be clones of each other.
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (113378 => 113379)
--- trunk/Source/WebCore/ChangeLog 2012-04-05 21:11:28 UTC (rev 113378)
+++ trunk/Source/WebCore/ChangeLog 2012-04-05 21:15:01 UTC (rev 113379)
@@ -1,3 +1,24 @@
+2012-04-05 Brady Eidson <[email protected]>
+
+ <rdar://problem/9359029> and https://bugs.webkit.org/show_bug.cgi?id=83311
+ Crashes in WebProcess at WebCore::HistoryController::recursiveSetProvisionalItem when restoring previous session
+
+ Reviewed by Sam Weinig.
+
+ It's possible to hit a race condition between the UIProcess and the WebProcess where the UIProcess records for a
+ page have been cleared out but the WebProcess is still trying to perform a history navigation within that page.
+
+ In this situation HistoryController code that expects there to always be a current history item in the back/forward
+ controller is wrong.
+
+ No new tests. (The race conditions involved have proven making a test impractical)
+
+ * loader/HistoryController.cpp:
+ (WebCore::HistoryController::recursiveSetProvisionalItem): Don't ASSERT the fromItem. We now know there might not be one.
+ (WebCore::HistoryController::recursiveGoToItem): Ditto
+ (WebCore::HistoryController::itemsAreClones): Always return false if either item is null, as a null item and a non-null
+ item cannot possible be clones of each other.
+
2012-04-05 Adam Klein <[email protected]>
Crash in MutationObservers due to an invalid HashSet iterator
Modified: trunk/Source/WebCore/loader/HistoryController.cpp (113378 => 113379)
--- trunk/Source/WebCore/loader/HistoryController.cpp 2012-04-05 21:11:28 UTC (rev 113378)
+++ trunk/Source/WebCore/loader/HistoryController.cpp 2012-04-05 21:15:01 UTC (rev 113379)
@@ -685,7 +685,6 @@
void HistoryController::recursiveSetProvisionalItem(HistoryItem* item, HistoryItem* fromItem, FrameLoadType type)
{
ASSERT(item);
- ASSERT(fromItem);
if (itemsAreClones(item, fromItem)) {
// Set provisional item, which will be committed in recursiveUpdateForCommit.
@@ -711,7 +710,6 @@
void HistoryController::recursiveGoToItem(HistoryItem* item, HistoryItem* fromItem, FrameLoadType type)
{
ASSERT(item);
- ASSERT(fromItem);
if (itemsAreClones(item, fromItem)) {
// Just iterate over the rest, looking for frames to navigate.
@@ -740,7 +738,9 @@
// a reload. Thus, if item1 and item2 are the same, we need to create a
// new document and should not consider them clones.
// (See http://webkit.org/b/35532 for details.)
- return item1 != item2
+ return item1
+ && item2
+ && item1 != item2
&& item1->itemSequenceNumber() == item2->itemSequenceNumber()
&& currentFramesMatchItem(item1)
&& item2->hasSameFrames(item1);
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
