WebKit + D-Bus -> Instant Chrome-like browser for GNU/Linux
I was wondering how hard would it be to create a web-browser that is, like Google’s Chrome, separated in different processes for different tabs. You know, the whole “security problems and crashing are restrained to single tab” thing.
As it turned out, it is not all that difficult. Create the main window, start the WebKit (QWebView) in another program, then X-Embed the later in the former, and communicate via D-Bus. (I got the idea to do this from Embed Window plasmoid 
)
If the child crashes, only one tab is gone. If the main application crashes, tabs become independent windows.
I’m not sure whether I’ll continue to work on this, but if I find the time, you could see a Rekonq-based (http://rekonq.sourceforge.net/) browser that is similar to Chrome someday.
You could add this feature (as an option) in Arora.
Comment by Elv13 — 29 March 2009 @ 18:00
@Elv13: It is too much work for a /as an option/ feature.
Arora would need to be separated into two different parts, an interface between those would need to be created…
And, the current implementation works only for X, and Arora is a portable little beast.
It can be implemented for Windows easily (at least, it was easy in Win9x era – haven’t used Win since), but I don’t intend to do that.
Comment by Ivan Čukić — 29 March 2009 @ 18:31
http://code.google.com/p/arora/issues/detail?id=352
Comment by Yves — 29 March 2009 @ 18:32
Please continue this work or make a simple way to install it =)
Comment by QUASAR — 29 March 2009 @ 19:22
Hi, Ivan. I’m very interested on this feature for rekonq.
Sure I cannot implement it via threadweaver?
Comment by Andrea Diamantini — 29 March 2009 @ 21:11
@Andrea Diamantini: Threadweaver would make your application faster/better behaving but if one thread crashes, the application crashes… That is the main problem.
There may be a mechanism to sandbox threads, but I really don’t know of it.
Comment by Ivan Čukić — 29 March 2009 @ 21:58
Can you post the source to this little demo? I’d like to learn a little about xembed from it.
Comment by Jason — 30 March 2009 @ 00:57
Yes! The only reason I’m interested in Chrome is because of it’s security model, sandboxing and each “secure” instance.
Being so easy to do that really surprises me!
Comment by mauricio — 30 March 2009 @ 04:01
I can’t help but wonder – if it’s straightforward, and you were able to whip this up relatively quickly, what’s taking the Google crew so long with the Linux port?
Comment by Jeff — 30 March 2009 @ 05:53
@Jason: Will do when I polish it a bit. If you want a quick way to XEmbed (the way I used), just see http://doc.trolltech.com/4.5/qx11embedcontainer.html
@mauricio: Well, the value of Chrome (IMO) is the idea behind it. Separating processes in the same application is not difficult to do (as you could see), but the idea itself is something that you wouldn’t come up with easily.
And, for really paranoid ones, you could even put every browser instance into a chroot environment or activate SELinux/AppArmor on it
@Jeff: Chrome devels, surprisingly enough, didn’t use portable UI (and, possibly, some other) libraries for Chrome development (while they used Qt in some other projects) so I guess that it is the main reason behind the porting problems.
Then, again, they may have introduced some quirky and strange mechanisms for process handling, and inter-process communication.
Fortunately enough, Unix-like systems have always had awesome tools for inter-process communication – even before the D-Bus was invented.
Porting is always a difficult thing to do. Especially when you don’t think about multi-platformness (I know that this word doesn’t exist) from the start.
Comment by Ivan Čukić — 30 March 2009 @ 09:28
If KParts were implemented as multiprocess(maybe optional), Konqueror would become Khrome for free. How much possible is that?
Comment by David — 30 March 2009 @ 16:08
@David: It guess that is not difficult, … but that it would need some work. You’d need to convert KPart API into DPI (he, he, D-Bus App Interface) and make a scissor cut there.
I don’t know how hard would it be since I don’t know what KParts API look like
Comment by Ivan Čukić — 30 March 2009 @ 16:59
@Ivan: And, for really paranoid ones, you could even put every browser instance into a chroot environment or activate SELinux/AppArmor on it
Wouldn’t work. Chroot requires root privileges.
@Ivan Čukić: I don’t know how hard would it be since I don’t know what KParts API look like
I do. Besides XMLGUI, it wouldn’t be all that hard. It would be a BIC change, though.
Comment by Michael "Chroot" Howell — 31 March 2009 @ 04:35
@Michael “Chroot” Howell: It would work – dchroot and schroot provide ordinary users to start applications in a chroot environment.
For the second thing, I can just say ‘bummer’
Comment by Ivan Čukić — 31 March 2009 @ 08:31
Midori had this feature many months ago, it was a pain because XEmbed had lots of focus issues with focus, shortcuts and other things.
Chrome actually separates the *renderer*, not the whole view, which is eons cleaner and doesn’t have these issues.
Comment by Mark — 31 March 2009 @ 16:47
How about transmitting the pixmaps over dbus?
Comment by sandsmark — 31 March 2009 @ 23:47
@sandsmark: It is possible. I’m transmitting site’s favicon from the client to the main window. It needs to be sent as array of bytes though.
Comment by Ivan Čukić — 1 April 2009 @ 08:40
So , have you toyed around with flash support for
it, id like to hear from people is the nsplugin support actually works in Qt 4.5 and if it can be used with adobes flash or gnash
Comment by Moire — 2 April 2009 @ 11:48
@Moire: It (I’ve tested YouTube) works in Rekonq so I suppose it “actually works”…
Comment by Ivan Čukić — 2 April 2009 @ 12:16
I’ve stumbled upon this scary brainchild of yours in a featured article at ArsETechnica… glad to see you’re coming up in the world, though
Comment by Petar — 4 April 2009 @ 03:41
@Petar: Cool phrasing
Thanks. Do you have something agains Ars?
Comment by Ivan Čukić — 4 April 2009 @ 10:10
[...] ma ispirato direttamente ad una caratteristica di Google Chrome in quanto se una delle schede di Webbie va in crash, non uccide l’intera applicazione perché ogni tab è un processo a se stante. [...]
Pingback by Stato dei browser WebKit in KDE e GNOME « pollycoke :) — 1 December 2009 @ 12:04