| Summary: | Check for GTK2/GTK3 symbol mismatch earlier | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Daniel Drake <dsd> | ||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | cgarcia, mario, mrobinson | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
(In reply to comment #0) > Created an attachment (id=144423) [details] > patch > > WebKit2 move plugins into their own process, but WebKit1 (built for GTK3) > is left with the limitation that if a plugin links against GTK2, it will > fail to run. Yes, that's a known issue :-( > nspluginwrapper could maybe work around this issue, by adding in a process > separation, but this doesn't work on current released WebKit. The affected > sites just show an empty box where the content should be. Hmm... In my case, I've been using epiphany 3.x and WebKit1 (linking against GTK3) without problems with the flash plugin thanks to nspluginwrapper, so I don't know if I'm missing something here. True to be told, my laptop is a 64bit system and works fine here, but I've never managed to make this "nspluginwrapper workaround" work in 32bit systems, which as far as I could read is a known limitation of nspluginwrapper. So, maybe your system is a 32bit one and yuo have found a fix even for those systems? Otherwise (if you're using it in a 64bit environment) I think I'm missing something, because nspluginwrapper should work fine. > Using Flash as an example, I dug down and found that the behaviour is > something like the following: > - Load both "real" libflashplayer and the wrapped libflashplayer > - Try to show the flash content using the real libflashplayer > - Abort because a mix of GTK2/GTK3 symbols was detected > > And that's it - it didn't even try the wrapped libflashplayer which > advertises support for the same mime types. > > I found a way to fix this: Move the GTK2/GTK3 symbol check earlier, and > don't even register plugins in the PluginDatabase if there is a symbol > mismatch. See attached patch. Nice! By the way, whenever you attach a patch and ask for review, you should take care of putting the "right" reviewers on CC, otherwise it might end up unattended. As per the output of git blame, it see Carlos could be a good reviewer for this one, so adding him o CC now. (In reply to comment #1) > [...] > Hmm... In my case, I've been using epiphany 3.x and WebKit1 (linking against GTK3) without problems with the flash plugin thanks to nspluginwrapper, so I don't know if I'm missing something here. > > True to be told, my laptop is a 64bit system and works fine here, but I've never managed to make this "nspluginwrapper workaround" work in 32bit systems, which as far as I could read is a known limitation of nspluginwrapper. > > So, maybe your system is a 32bit one and yuo have found a fix even for those systems? Otherwise (if you're using it in a 64bit environment) I think I'm missing something, because nspluginwrapper should work fine. I'm stupid. I've just read a mail of yours in webkit-gtk mailing list talking about this[1] and realized you are the same person I answered in the mailing list some time ago, where you already mentioned you had a 32bit system. So it seems you fixed the flash plugin issue with nspluginwrapper in 32bit systems too. \o/ [1] http://lists.webkit.org/pipermail/webkit-gtk/2012-May/001124.html Comment on attachment 144423 [details] patch I'll add a ChangeLog and land this one, but in the future when submitting patches take a look at http://www.webkit.org/coding/contributing.html which will show you how to make a proper patch with a ChangeLog. Thanks for your contribution! Committed r118949: <http://trac.webkit.org/changeset/118949> |
Created attachment 144423 [details] patch WebKit2 move plugins into their own process, but WebKit1 (built for GTK3) is left with the limitation that if a plugin links against GTK2, it will fail to run. nspluginwrapper could maybe work around this issue, by adding in a process separation, but this doesn't work on current released WebKit. The affected sites just show an empty box where the content should be. Using Flash as an example, I dug down and found that the behaviour is something like the following: - Load both "real" libflashplayer and the wrapped libflashplayer - Try to show the flash content using the real libflashplayer - Abort because a mix of GTK2/GTK3 symbols was detected And that's it - it didn't even try the wrapped libflashplayer which advertises support for the same mime types. I found a way to fix this: Move the GTK2/GTK3 symbol check earlier, and don't even register plugins in the PluginDatabase if there is a symbol mismatch. See attached patch. With this patch applied, I can finally view flash content in recent Epiphany versions, via nspluginwrapper!