[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 #19 from Mario Sanchez Prada <msanchez at igalia.com>  2011-01-26 06:12:15 PST ---
(In reply to comment #18)
> [...] 
> 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?

As far as I can see from the code and while debugging, it seems the problem is that such a function ends up calling webkit_web_frame_load_data () with zero in the unreachableURL param, meaning that no history item will be created later on in HistoryController::updateForStandardLoad(), as historyURL.isEmpty() will return true there.

I could probably use webkit_web_frame_load_alternate_string() from the unit test to workaround this problem (passing a dummy unreachableURL), but I don't think it's a good approach... still think that if that was the case the last proposed patch would be a better option, since it would be gracefully treating the (very strange) case of calling to restoreScrollPosition() with m_currentItem == 0.

But take this with a grain of salt, of course. I know can be wrong again

> 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.

I've spent all the morning debugging the code and deeply analyzing the code behind that function (and comparing it to webkit_web_view_load_string() in the GTK port), and I can't properly understand why that function in Chromium wouldn't be affected by the same problem... actually, hope you don't mind me explicitly asking this but: are you sure the same problem doesn't happen in Chromium? To be sure, it would be wonderful if you could try to reproduce it by:

  1. Compile a debug build, so ASSERTS will make WK crash if false.
  2. Create a new WebKit view in your test code.
  3. Load an static string with HTML content on it through WebKit::WebFrame::loadData(), as you said.
  4. Try to reload now.

If I'm right, you should be getting a crash as the result of the ASSERT failing in restoreScrollPositionAndViewState().

I of course understand that you could have no time to test this, but I'd appreciate at least some insight on these thoughts, they could be really helpful to me.

Thanks!

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