GNOME Bugzilla – Bug 663823
Make the browser plugin work under WebKit-based browsers like Chromium
Last modified: 2011-12-03 19:20:16 UTC
Right now, the browser plugin does not work under WebKit-based browsers like Chromium and Epiphany. This is due to two main issues, both of which are fixed by these patches.
Created attachment 201210 [details] [review] browser-plugin: Set that we need XEmbed This makes the plugin work under WebKit-based browsers such as Chromium and Epiphany. See http://code.google.com/p/chromium/issues/detail?id=38229 and WindowedCreatePlugin() in http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/npapi/webplugin_delegate_impl_gtk.cc?revision=86823&content-type=text%2Fplain for more information.
Created attachment 201211 [details] [review] browser-plugin: Use g_strndup to get a string property WebKit-based browsers like Chromium and Epiphany may insert extra junk at the end of NPStrings, so we cannot depend on the strlen matching.
Created attachment 201212 [details] [review] browser-plugin: Move "entry points" comment
Review of attachment 201210 [details] [review]: Makes sense. (Did you test it?)
Review of attachment 201211 [details] [review]: Might be interesting to know why they'd to that but looks fine.
Review of attachment 201212 [details] [review]: Looks good.
Attachment 201210 [details] pushed as 2c2729f - browser-plugin: Set that we need XEmbed Attachment 201211 [details] pushed as 9bc1a68 - browser-plugin: Use g_strndup to get a string property Attachment 201212 [details] pushed as 363bd04 - browser-plugin: Move "entry points" comment Yes, I have tested these patches
*** Bug 665370 has been marked as a duplicate of this bug. ***
One simple question, why do we need an external plugin in order for Chrome to work? Is this a temporary fix or permanent?
Web browsers don't give us the API to do random system thing, so we need to build a browser plugin so that you can install, uninstall, enable, disable extensions.
There are many other places where the plugin ignores UTF8Length and assume the string is nul-terminated. They'll like have the same problem. Mostly the code that deals with UUID strings; do a search for UTF8Characters. They also want to be fixed. NPStrings are not guaranteed to be nul-terminated, which is why they have a length field. It'd also be good to get rid of all those synchronous DBus calls. Modern browsers do push things out-of-process, but you still end up blocking the page and potentially bits of the browser.
(In reply to comment #11) > There are many other places where the plugin ignores UTF8Length and assume the > string is nul-terminated. They'll like have the same problem. Mostly the code > that deals with UUID strings; do a search for UTF8Characters. They also want to > be fixed. NPStrings are not guaranteed to be nul-terminated, which is why they > have a length field. See bug #665261. > It'd also be good to get rid of all those synchronous DBus calls. Modern > browsers do push things out-of-process, but you still end up blocking the page > and potentially bits of the browser. Implementing an asynchronous callback mechanism would make the code a lot more complicated. I don't think it's worth the increased complexity. If you want to implement it, be my guest. Patches welcome.