Closed
Bug 553156
Opened 15 years ago
Closed 2 years ago
WARNING: NS_ENSURE_TRUE(item) failed in HistoryDataSource OnTitleChanged when loading certain types of pages
Categories
(Camino Graveyard :: History, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: alqahira, Unassigned)
Details
Attachments
(2 files)
hendy and I have both seen this, but not all pages seem to trigger it. The forum does, as does the url in bug 553151:
http://forums.mozillazine.org/viewforum.php?f=12
http://www.sophiestication.com/articles/
It happens on both branches.
Reporter | ||
Updated•14 years ago
|
Summary: WARNING: NS_ENSURE_TRUE(item) failed (HistoryDataSource.mm, line 664) when loading certain types of pages → WARNING: NS_ENSURE_TRUE(item) failed in HistoryDataSource OnTitleChanged when loading certain types of pages
Reporter | ||
Comment 1•14 years ago
|
||
This also happens on file:// URLs; I ran into it there while logging for another bug.
For whatever reason, |HistoryItemFromURI| is failing *a lot* (this caused problems in bug 506345 when Stuart tried to remove the safety checks).
I did a little bit of extra logging, and I really don't know what's happening that's causing |HistoryItemFromURI| to fail; I don't understand what that code is doing well enough to follow it down the rabbit hole. We make the identifierString just fine, but |return [mDataSource itemWithIdentifier:identifierString];| appears to always return null for these sites in OnVisit (where we'd expect null on a first visit, and therefore go make an item) and OnTitleChanged, where we presumably don't expect it, and get the NS_ENSURE(foo) failed.
Here's some logging I did, but again, it doesn't really show the interesting stuff (why, for whatever reason, we're failing when we call |HistoryItemFromURI| in OnTitleChanged.
Reporter | ||
Comment 2•14 years ago
|
||
This is a second log, showing me loading the local file and then loading the file again. Note for the second load, the Gecko logging isn't entirely interleaved with the NSLogging where it should be (the childCount check).
Things that disturb me:
In the second load, in OnVisit, we again fail to fetch the HistorySiteItem we created first visit, so we end up in the |else| block there ("Making a new HistorySiteItem?") and then bail, I presume, when we hit WARNING: NS_ENSURE_TRUE(childCount == 1) failed.
Given this is the second visit, we never should be in this |else| to begin with, and since we are, the childCount check should certainly fail. But this means, for the third time since it was created in the first OnVisit, we still don't end up with our HistorySiteItem created in the first OnVisit.
Reporter | ||
Updated•14 years ago
|
Flags: camino2.1?
Reporter | ||
Comment 3•13 years ago
|
||
I'd still like to know what's going on here (but that does seem unlikely).
Flags: camino2.1?
Flags: camino2.1.1?
Flags: camino2.1-
Reporter | ||
Updated•13 years ago
|
Flags: camino2.1.2?
Flags: camino2.1.1?
Flags: camino2.1.1-
Comment 4•2 years ago
|
||
This bug lies at rest in the graveyard.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•