The Acid2- and the Acid3-test don't load with the http-backend soup on WebKit Gtk
*** Bug 18301 has been marked as a duplicate of this bug. ***
Created attachment 20336 [details] fixes the issue and implement missing features The issue was that the data url wasn't loaded, since didFinishLoading was called inside the start of the job and webkit didn't recognize the data loading.
Created attachment 20344 [details] fixes the issue and implement missing features Forgot a line of code which i thought not important.
Created attachment 20350 [details] fix response urls and only catch transport errors I think client errors and server errors can be shown instead of fail, so i left only transport errors such as network errors or soup errors to fail. Also set the effective url of the response, this fixes several problems i don't know how to explain because of my poor English ;)
The patch works fine for me. I have no problems with loading additional files (stylesheets, images) anymore. But there is a problem left, and I m not sure to open a new bug-report or if it is related to this bug. If you load sites like the acid2-test, http://www.msn.com , http://www.phoronix.com the site starts to load, but GtkLauncher quits with a segmentation fault.
Created attachment 20355 [details] fix re-entrancy cancellation Fixed re-entrancy on job cancellation, this time without deferring the cancellation. Soup headers are not in UTF8, in fact it crashes while loading msn. I just removed the String::fromUTF8 and pass the plain value.
Created attachment 20364 [details] add WebKitResourceError Fixes failure on unknown protocol. I thought it was time to add some errors and created WebKitResourceError. Anyway i can't see a crash in g_signal_emit_valist, when called from dispatchDidFailLoading. I don't know how it can crash, if please anyone who can test and help finding this one.
Created attachment 20366 [details] add WebKitResourceError Didn't store the return value of load-failed emission.
Created attachment 20367 [details] alternative using GError As suggested by kalikiana.
We had a brief conversation in the IRC about this. I suggested that it should be a good idea to use GError and also that the default error implementation should not be a dialog. It's nice to see you already proposed a patch for GError in no time, thanks for that. As for the error message, we do not want a modal dialog. This is a mistake firefox/ gecko made initially as well until Mozilla switched to HTML error pages. Other browsers do this as well. For what I want, it doesn't matter much how that page looks, we can work out a design for any WebKit internal informational pages in a separate patch/ bug.
(In reply to comment #10) > We had a brief conversation in the IRC about this. I suggested that it should > be a good idea to use GError and also that the default error implementation > should not be a dialog. > > It's nice to see you already proposed a patch for GError in no time, thanks for > that. > > As for the error message, we do not want a modal dialog. This is a mistake > firefox/ gecko made initially as well until Mozilla switched to HTML error > pages. Other browsers do this as well. For what I want, it doesn't matter much > how that page looks, we can work out a design for any WebKit internal > informational pages in a separate patch/ bug. > I totally agree, but for the HTML pages even simple would be another bug. I won't work anymore on that for this bug context. Once the patch is landed i'll open a bug for that and work on it as well.
Created attachment 20373 [details] fill response headers on redirects Response headers were not filled in restartedCallback. Missing enum name for network errors. Some styling issues fixed. Added further comments.
(In reply to comment #12) > Created an attachment (id=20373) [edit] > fill response headers on redirects > > Response headers were not filled in restartedCallback. > Missing enum name for network errors. > Some styling issues fixed. > Added further comments. > The public API additions provide an important feature but it'd be best to do that separately so we can get the main fixes in your patch without having to figure out how http errors are passed up at the same time. I think there are a few possible ways of exposing the errors and not sure this approach is the best one.
Created attachment 20379 [details] remove errors Hopefully this is the final one :)
Landed in r31682.