Additional backend - WebKit/Gtk+

[GoogleCodeExporter]

Hi! Is it possible to have WebKit/Gtk+ as an optional backend to
SpiderMonkey? Since you're already using WebKit for the Qt port, it
shouldn't be that hard to support WebKit/Gtk.

Regards,

Jan

Original issue reported on code.google.com by jmalo...@gmail.com on 7 Jun 2008 at 6:04

[GoogleCodeExporter]

Original comment by james...@gmail.com on 7 Jun 2008 at 1:17

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

We'd appreciate if someone can help on it.

Original comment by james...@gmail.com on 7 Jun 2008 at 2:09

[GoogleCodeExporter]

I'm working on this now. But i'm not sure if this is dependent on Bug #151.

Original comment by jmalo...@gmail.com on 10 Jun 2008 at 4:27

[GoogleCodeExporter]

Great news!

There is no dependency between JavaScript runtime and browser element. What 
your are
working on would be a browser element similar than
extensions/qtwebkit_browser_element and gtkmoz_browser_element, which depends on
WebKit/Gtk+. The browser element is mainly for supporting iGoogle Gadgets and 
HTML
details view.

Original comment by james...@gmail.com on 10 Jun 2008 at 5:20

[GoogleCodeExporter]

Hi James

Thanks. Is there a way to find out, at runtime, if i'm *really* using a 
different browser element? 

Original comment by jmalo...@gmail.com on 10 Jun 2008 at 5:52

[GoogleCodeExporter]

Currently the module name of browser element is hard coded in host's source 
code.
Please look at hosts/gtk/main.cc and hosts/qt/main.cc.
So the host always knows which browser element implementation is currently used.

Original comment by james...@gmail.com on 10 Jun 2008 at 5:57

[GoogleCodeExporter]

Hi James

Thanks for your feedback. Attached is a patch to add a webkit browser element.
There's still a couple of FIXMEs which I'm hoping you can answer. 

1. I'm sharing DecodeJSONString with Qt. Is there a place where to put shared 
code
across port/host/browser_elements?

2. I'm loading the decoded JSON string as us-ascii. Is there a way to get the
encoding of the string?

Thanks and appreciate if you can review the patch as well.

Regards

Jan

Original comment by jmalo...@gmail.com on 10 Jun 2008 at 7:08

Attachments:

• ggl-webkit-browser.patch

[GoogleCodeExporter]

Thanks for your contribution. We'll review your patch and give you feedback 
asap.

Original comment by james...@gmail.com on 10 Jun 2008 at 8:00

[GoogleCodeExporter]

The patch doesn't quite work yet. But any feedback is definitely appreciated.

Thanks.

Original comment by jmalo...@gmail.com on 10 Jun 2008 at 8:06

[GoogleCodeExporter]

Some quick comments:

1. Coding style
  We usually use two space characters for indent, and the maximum line length is 80.

2. In configure.ac
following lines are not necessary:
+else
+  WEBKIT_LIBS="$WEBKIT_LIBS"
+  WEBKIT_CFLAGS="$WEBKIT_CFLAGS"
+  AC_SUBST(WEBKIT_LIBS)
+  AC_SUBST(WEBKIT_CFLAGS)

3. The pc file name of WebKit/Gtk
In openSUSE, the file name is WebKitGtk.pc. I'm wondering if there is a 
standard one.

I'll give you more feedback later.

Original comment by james...@gmail.com on 10 Jun 2008 at 8:20

[GoogleCodeExporter]

Hi Jan,

I tried your patch on Ubuntu8.04, The browser_element rendered nothing. I got 
errors
like below:

42:05.271: ../../../ggadget/gtk/single_view_host.cc:267:
SingleViewHost::EnableInputShapeMask(true)
42:05.559: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000

(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_widget_reparent: assertion 
`widget->parent
!= NULL' failed

(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_fixed_move_internal: assertion
`widget->parent == GTK_WIDGET (fixed)' failed
42:05.564: ../../ggadget/small_object.cc:584: FixedAllocator Stat: 16 30000 
14930
15070 60 0.984967
42:05.606: ../../ggadget/small_object.cc:584: FixedAllocator Stat: 16 30067 
15000
15067 60 0.984771
42:05.736: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000

(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_widget_reparent: assertion 
`widget->parent
!= NULL' failed

(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_fixed_move_internal: assertion
`widget->parent == GTK_WIDGET (fixed)' failed
42:06.093: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000

(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_widget_reparent: assertion 
`widget->parent
!= NULL' failed

(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_fixed_move_internal: assertion
`widget->parent == GTK_WIDGET (fixed)' failed
42:06.480: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000

Original comment by idlecat...@gmail.com on 11 Jun 2008 at 9:46

[GoogleCodeExporter]

Hi James

3. The pc file name of WebKit/Gtk
In openSUSE, the file name is WebKitGtk.pc. I'm wondering if there is a 
standard one.

The old qmake build used to build a WebKitGtk.pc but since we moved to 
autotools (a few months ago), this 
has been renamed to webkit-1.0.pc.

idlecat511,

Yeah. I realized it doesn't work at all. I'll try to come up with a patch 
sometime this week or next. Thanks for 
trying it out.

Feedback appreciated.

Original comment by jmalo...@gmail.com on 11 Jun 2008 at 11:26

[GoogleCodeExporter]

In order to make browser element work properly, signals "onGetProperty",
"onSetProperty", "onCallback" and "onOpenURL" must be implemented. Please refer 
to
the source code of gtkmoz_browser_element.

The qtwebkit_browser_element hasn't implemented them yet.

Original comment by james...@gmail.com on 11 Jun 2008 at 12:06

[GoogleCodeExporter]

Attached is an updated (and tested!) patch. It doesn't contain implementation 
of the
signals James mentioned in the previous comment (yet). Is there anything else 
I'm
missing? 

Cheers

Original comment by jmalo...@gmail.com on 12 Jun 2008 at 4:59

Attachments:

• ggl-webkit-browser.patch

[GoogleCodeExporter]

Hi Jan,

I've just tried the patch. It works great. But without the signals James 
mentioned, a
lot of functions are not there. For example, your browser element can't load a 
page
with an external browser.

--
Tiger

Original comment by idlecat...@gmail.com on 20 Jun 2008 at 2:57

[GoogleCodeExporter]

Hi James, idlecat511

Where can I find documentation of those signals? What should the implementation 
do?

Thanks.

Original comment by jmalo...@gmail.com on 22 Jun 2008 at 11:30

[GoogleCodeExporter]

We have no direct docs for the signals, but you can see related documentation in
extensions/gtkmoz_browser_element/browser_child.h about kXXXXXFeedback 
constants,
each of which (except for kPingFeedback) corresponds each of the signals. At 
least
onOpenURL signal should be implemented, but others are also required when
window.external is used in HTML details views.

Original comment by phnix...@gmail.com on 23 Jun 2008 at 12:47

[GoogleCodeExporter]

I just found that webkit gtk port 1.0.1 contains api to access JavaScript 
context,
and ubuntu 8.10 already ships webkit 1.0.1 package. Now, it might be possible to
implement those signals.

Hi jmalonzo, can you please help update the implementation to support those 
signals?

And I'm wondering if it's worth to implement a script runtime based on
JavaScriptCore, then we can get rid off the dependency to xulrunner completely.

Original comment by james...@gmail.com on 21 Oct 2008 at 11:04

[GoogleCodeExporter]

Hi James

Is there a reason why gtkmoz uses a gtksocket instead of just embedding the 
widget
into a container? Is this the way moz embedders should work or it's just a ggl 
design
decision? I noticed that gtkmoz and qtwebkit have different approaches and 
wondering
which path I should take for gtkwebkit.

As for the script runtime, it would be nice if we can just use JavaScriptCore 
for
webkit. Using xulrunner eventhough webkit's the engine is I think superfluous.

Original comment by jmalo...@gmail.com on 23 Oct 2008 at 12:32

[GoogleCodeExporter]

It's a design decision based on following reasons:
1. Gecko is huge, we don't want to pollute host's symbol table by linking to 
Gecko
dynamically.
2. It's easy to debug gtkmoz-browser-child separately.
3. smjs-script-runtime may be able to use different libmozjs than the one in 
Gecko.
4. The ABI of Gecko is not stable, gtkmoz-browser-child might not work due to 
ABI
incompatibility. We don't want it to break whole GGL.

I think gtk webkit doesn't have such issues, so taking the qtwebkit approach is 
just ok.

For script runtime, I'm wondering if you are interested in writing a script 
runtime
extension based on JavaScriptCore? Then we can get rid off Gecko dependency
completely, it's really awful, due to ABI compatibility issue.

Original comment by james...@gmail.com on 23 Oct 2008 at 2:29

[GoogleCodeExporter]

I think the main reason why I can't do OpenUrl yet is because there's no way I 
would
be able to know if a link was clicked or if a new window's been requested. 
There are
patches in the webkit bugzilla but not yet in the mainline trunk. Once the 
patches
have been landed, I would be able to do this.

For the script runtime, I'll check it out. No promises though.

Cheers

Original comment by jmalo...@gmail.com on 23 Oct 2008 at 9:46

[GoogleCodeExporter]

This is just an update to the previous patch for it to apply cleanly with HEAD. 

Cheers

Original comment by jmalo...@gmail.com on 23 Oct 2008 at 11:10

Attachments:

• ggl-webkit-browser.patch

[GoogleCodeExporter]

I'm working on a script runtime extension based on WebKit/JavaScriptCore. Hope 
we
will have a full webkit port soon (including this webkit browser element).

Original comment by james...@gmail.com on 23 Feb 2009 at 6:38

• Changed state: Accepted

[GoogleCodeExporter]

full webkit support has been committed to trunk.

Original comment by james...@gmail.com on 24 May 2009 at 1:23

• Changed state: Fixed