Closed Bug 553156 Opened 13 years ago Closed 9 months ago

WARNING: NS_ENSURE_TRUE(item) failed in HistoryDataSource OnTitleChanged when loading certain types of pages


(Camino Graveyard :: History, defect)

Not set


(Not tracked)



(Reporter: alqahira, Unassigned)



(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:

It happens on both branches.
Summary: WARNING: NS_ENSURE_TRUE(item) failed (, line 664) when loading certain types of pages → WARNING: NS_ENSURE_TRUE(item) failed in HistoryDataSource OnTitleChanged when loading certain types of pages
Attached file Logging of three cases
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.
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.
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-
Flags: camino2.1.2?
Flags: camino2.1.1?
Flags: camino2.1.1-

This bug lies at rest in the graveyard.

Closed: 9 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.