Community
Participate
Working Groups
Snippet 330 has 'set headers' and 'post data' button. Sending data over 'postData' isn't working on webkit2. - On webkit1, bugzilla can be queries with postData - On webkit2, bugzilla opens with an error message about missing post data. Upon code inspection, it seems that postData has not been ported to webkit2. (but headers button seems to work.)
i.e, setUrl(... postData ... ). (but would be good to check headers also).
One slight blocker for this is the lack of API for accessing the HTTP body itself in WebKitURIRequest (https://webkitgtk.org/reference/webkit2gtk/stable/WebKitURIRequest.html). We can access the HTTP Headers (as SoupMessageHeaders), and even the HTTP method (which we can change from GET to POST), but the POST data must be added to the body of the message and we don't have access to that. In WebKit1, there was a method that gave us the SoupMessage, which contained the method, headers, and body of the request. I'll see if there's some workaround.
Looks like Sami discovered the same issue, and made pretty much the same request at https://bugs.webkit.org/show_bug.cgi?id=129379 . I don't see any progress though.
From what I gather in the following discussion: http://webkit-gtk.webkit.narkive.com/kppfqah2/networkrequest-and-networkresponse-in-webkit2-api It was decided not to expose SoupMessage, only some of it's properties.
One possible short term hack-around while we wait for webkitgtk folks to implement api is to put POST-data into URL (i.e GET). E.g: > ..... > @Override > public boolean setUrl (String url, String postData, String[] headers) { > this.postData = postData; > this.headers = headers; > if (WEBKIT2) { > if (postData != null) { > // Print some warning about unfinished api here. > url = url + "?" + postData; // append > } > } > ... With this Snippet330 works. It'll work so long as postData is less than 2,048 characters long. (where as post can be up to 2GB). This is far from ideal, but might be better than nothing, especially considering SWT Webrowser is only used for smaller/simple apps, it might cover a lot of use cases.
(In reply to Leo Ufimtsev from comment #5) > One possible short term hack-around while we wait for webkitgtk folks to > implement api is to put POST-data into URL (i.e GET). > > E.g: > > ..... > > @Override > > public boolean setUrl (String url, String postData, String[] headers) { > > this.postData = postData; > > this.headers = headers; > > if (WEBKIT2) { > > if (postData != null) { > > // Print some warning about unfinished api here. > > url = url + "?" + postData; // append > > } > > } > > ... > > With this Snippet330 works. > It'll work so long as postData is less than 2,048 characters long. (where as > post can be up to 2GB). > > This is far from ideal, but might be better than nothing, especially > considering SWT Webrowser is only used for smaller/simple apps, it might > cover a lot of use cases. This definitely seems like it's better than nothing but I wonder by how much. I believe bugzilla supports sending a query string over a GET request but not all services will accept data as both POST or GET, and in the case of file uploads, it won't be possible.
New Gerrit change created: https://git.eclipse.org/r/112732
Implemented via workaround. (use java http request). We will request api from webkitgtk folks and track enchancement via: 528550 – [Webkit2] Implement setUrl(..postData..) via webkitgtk api instead of java when/if webkitgtk api becomes available. https://bugs.eclipse.org/bugs/show_bug.cgi?id=528550
@Roland. Kudos for creative workaround.
Gerrit change https://git.eclipse.org/r/112732 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d8fca1df5fd4712c60aca821d48bec6f9359f1a4
New Gerrit change created: https://git.eclipse.org/r/113501
Gerrit change https://git.eclipse.org/r/113501 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e381d207cb461db072e6cc75b35c048984347aa6
The added unit test org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser test_setUrl_remote_with_post fails for me on Windows 10 if I ran the AllTests test suite. org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser test_setUrl_remote_with_post(org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser) java.lang.AssertionError: Response data contained 247 chars. @Roland, AFAICS the test is from you. Can you please have a look?
This test grabs page contents without waiting for it to load completely. (Instead it waits for the page title to change). For local pages this isn't noticeable, but test_setUrl_remote_with_post hits a slow loading remote page (bugs.eclipse.org).
Thanks for noticing this. We'll take a look.
(In reply to Nikita Nemkin from comment #14) > This test grabs page contents without waiting for it to load completely. > (Instead it waits for the page title to change). > > For local pages this isn't noticeable, but test_setUrl_remote_with_post hits > a slow loading remote page (bugs.eclipse.org). Yes, this sounds familiar. I remember having a lot of difficulty finding some kind of content/request listener which actually would get activated when the page load was complete, so ultimately I had to use a status listener. Going from my memory it may have been specific to windows would have to look again to see.
There is Browser.addProgressListener() with ProgressListener.completed() callback. Looks exactly like what's needed here (assuming it works).
New Gerrit change created: https://git.eclipse.org/r/120283
(In reply to Nikita Nemkin from comment #17) > There is Browser.addProgressListener() with ProgressListener.completed() > callback. Looks exactly like what's needed here (assuming it works). Yes, I can confirm his will work on Linux. In fact I can see ProgressListener used in other places as well. Let me just confirm it also works on win32 and macos. Maybe I simply used it incorrectly the first time.
(In reply to Roland Grunberg from comment #19) > (In reply to Nikita Nemkin from comment #17) > > There is Browser.addProgressListener() with ProgressListener.completed() > > callback. Looks exactly like what's needed here (assuming it works). > > Yes, I can confirm his will work on Linux. In fact I can see > ProgressListener used in other places as well. > > Let me just confirm it also works on win32 and macos. Maybe I simply used it > incorrectly the first time. Works as well on win32 and macos, so should be fine to review now.
Thanks, Roland, Nikita and Leo. This fixes the Test_org_eclipse_swt_browser_Browser test for me.
Gerrit change https://git.eclipse.org/r/120283 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=5ef2d9520a5705bf1ba0faeb74ef5cffb1b9bcc7
