[Webkit-unassigned] [Bug 50331] ASSERT failing restoring scroll position from HistoryItem after reload

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50331





--- Comment #18 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-01-25 09:14:41 PST ---
(In reply to comment #17)
> > this seems like the wrong direction to go.  you have identified a case
> > where we can get a null m_currentItem.  perhaps we should instead try
> > to fix that case to not have a null m_currentItem?
> > 
> > i think it needlessly complicates HistoryController to have to support
> > a null m_currentItem as we sort of do today.
> 
> That was my first approach (to avoid getting a null m_currentItem when calling that function), but in comment #10 Darin (well, "the other Darin") pointed out that it would be better to make the change right inside restoreScrollPositionAndViewState(), so I did.
> 
> Not sure what to do now, perhaps I'm missing something and there's a third way to fix this, but I can't clearly see it at this moment.

Yes, I was referring to a different approach.  Instead of null checking m_currentItem, I think it would be better to ensure that webkit_web_view_load_string actually creates a HistoryItem.  Why doesn't it create one?

webkit_web_view_load_string looks a lot like WebKit::WebFrame::loadData() in the Chromium WebKit API.  Perhaps you can compare your implementation of webkit_web_view_load_string to that to see how they compare.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.