[Webkit-unassigned] [Bug 40222] Use the new SoupURILoader API

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 6 10:22:53 PDT 2010


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





--- Comment #11 from Sergio Villar Senin <svillar at igalia.com>  2010-07-06 10:22:53 PST ---
(In reply to comment #9)
> >@@ -428,7 +404,7 @@ static bool startData(ResourceHandle* handle, String urlString)
> > 
> >     // If parseDataUrl is called synchronously the job is not yet effectively started
> >     // and webkit won't never know that the data has been parsed even didFinishLoading is called.
> >-    d->m_idleHandler = g_timeout_add(0, parseDataUrl, handle);
> >+    d->m_idleHandler = g_idle_add(parseDataUrl, handle);
> 
> This is not the same thing. Do you need to change it or you just felt it was better? Needs an explanation.

There is only 1 test that fails if I keep the timeout_add thing which is 
http/tests/security/dataURL/xss-DENIED-from-data-url-in-foreign-domain-subframe.html

This test (from the resources POV) does the following:
  * loads an HTML which then...
  * loads another HTML which...
  * loads a data URL with some code that finally calls notifyDone

The sequence of calls with the "old" g_timeout_add is

startHttp -> closeCallback -> startHttp -> startData -> parseDataURL -> closeCallback -> closeCallback -> startHttp -> closeCallback

The problem is that parseDataURL is called *before* the last startHttp is issued and thus the test keeps waiting forever for the notifyDone call which is called when parseDataURL finishes.

With the g_idle_add it looks like

startHttp -> closeCallback -> startHttp -> startData -> closeCallback -> startHttp ->  parseDataURL -> closeCallback -> closeCallback

In this case the parseDataURL is called after the last call to startHttp. This is pretty much what happens with master's ResourceHandleSoup. The reason why it currently works in master with a timeout is not clear to me yet but I suspect that with the new libsoup it fails because the amount of asynchronous calls increases. Don't know core guts enough to know why some callbacks are called before than others.

Thing is that the test works fine, I mean, the output of the test is OK, WebKit behaves as it should not allowing access to the root element from a dataURL loaded from another domain, it's just that the test framework don't get the events when it expects them to arrive, that's why it reaches the timeout. So maybe skipping the test is a possibility.

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



More information about the webkit-unassigned mailing list