diff options
author | Eric Williams | 2018-07-12 20:14:54 +0000 |
---|---|---|
committer | Eric Williams | 2018-08-14 14:51:19 +0000 |
commit | f0fe56670826e5b46e2c9a52c132ec39f531e136 (patch) | |
tree | f6d509251f92ea8e583bd09986c1e0ec1ae88e17 /bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h | |
parent | dfb0cb3dbe3b038908c695231ad8a8f200ee1500 (diff) | |
download | eclipse.platform.swt-f0fe56670826e5b46e2c9a52c132ec39f531e136.tar.gz eclipse.platform.swt-f0fe56670826e5b46e2c9a52c132ec39f531e136.tar.xz eclipse.platform.swt-f0fe56670826e5b46e2c9a52c132ec39f531e136.zip |
Bug 536141: [Webkit2][Gtk] BrowserFunction lost after page reload on
Linux/GTK
The main cause of this bug is that web pages load too quickly -- by the
time the BrowserFunctions are re-registered asynchronously from Java,
the extension has loaded the page.
BEFORE THIS PATCH:
BrowserFunctions were registered asynchronously from Java into the web
extension (C). This was done either at the outset
(WebBrowser.createFunction()), or after every page load
(Webkit.webkit_load_changed() callback).
AFTER THIS PATCH:
The fix is relatively straightforward, yet GDBus adds a lot of overhead.
Instead of constantly registering BrowserFunctions from Java, we load
them into the web extension on creation. This hands off the
responsibility of re-registering BrowserFunctions to the web extension,
which reduces overhead and ensures the functions are registered/executed
before the page loads. The BrowserFunctions are stored at the C level in
the extension, using a linked list. Whenever the "object-cleared"
callback is triggered in the extension, the linked list is iterated over
and any BrowserFunctions for that page are re-registered.
Chronological ordering of information flow from SWT -> web extension via
GDBus.
1) SWT Webkit class is loaded. SWT GDBus server is created.
2) SWT Webkit creates the extension, passing it the information of the
SWT Webkit GDBus server.
3) The extension's initialization callback is called in C.
4) In this callback the extension contacts the SWT Webkit GDBus server
and provides it with information such as its PID and name.
5) SWT Webkit acknowledges this information, and sends back any
BrowserFunctions that were created before the extension loaded.
6) The extension adds these BrowserFunctions to its linked list.
7) Any subsequent BrowserFunctions are added to the extension's linked
list by calling the extension's GDBus server synchronously. In the event
of a GDBus timeout (happens sometimes when running tests), the GDBus
call is made asynchronously.
This functionality can be tested with the attached snippet.
AllBrowserTests pass without issue, and there are no visible Browser
issues in the IDE. The plugin attached to the initial bug report is now
functional.
Change-Id: Iddc5f2e69f0a7fd4500bd8228f0bc46c4b3a6322
Signed-off-by: Eric Williams <ericwill@redhat.com>
Diffstat (limited to 'bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h')
-rw-r--r-- | bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h index bcce6b32a0..9ccc85811c 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h +++ b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_custom.h @@ -67,6 +67,7 @@ #define g_thread_init_LIB LIB_GTHREAD #define ubuntu_menu_proxy_get_LIB LIB_GTK #define FcConfigAppFontAddFile_LIB LIB_FONTCONFIG +#define g_dbus_proxy_call_LIB LIB_GLIB // GTK3 only #define g_bytes_new_LIB LIB_GLIB |