87687 2012-05-28 18:48:17 -0700 Check for GTK2/GTK3 symbol mismatch earlier 2012-05-30 12:08:31 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 0 dsd webkit-unassigned cgarcia mario mrobinson oldest_to_newest 635504 0 144423 dsd 2012-05-28 18:48:17 -0700 Created attachment 144423 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! 635668 1 mario 2012-05-29 00:29:45 -0700 (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. 635721 2 mario 2012-05-29 01:41:05 -0700 (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 636036 3 144423 mrobinson 2012-05-29 08:10:50 -0700 Comment on attachment 144423 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! 637514 4 mrobinson 2012-05-30 12:08:31 -0700 Committed r118949: <http://trac.webkit.org/changeset/118949> 144423 2012-05-28 18:48:17 -0700 2012-05-29 08:10:50 -0700 patch plugindebug.patch text/plain 2111 dsd SW5kZXg6IFdlYktpdC1yMTE4NTE1LWd0azMvU291cmNlL1dlYkNvcmUvcGx1Z2lucy9ndGsvUGx1 Z2luUGFja2FnZUd0ay5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViS2l0LXIxMTg1MTUtZ3RrMy5vcmln L1NvdXJjZS9XZWJDb3JlL3BsdWdpbnMvZ3RrL1BsdWdpblBhY2thZ2VHdGsuY3BwCisrKyBXZWJL aXQtcjExODUxNS1ndGszL1NvdXJjZS9XZWJDb3JlL3BsdWdpbnMvZ3RrL1BsdWdpblBhY2thZ2VH dGsuY3BwCkBAIC0xMTksNiArMTE5LDE2IEBAIHN0YXRpYyBpbnQgd2Via2l0Z3RrWEVycm9yKERp c3BsYXkqIHhkaXMKIH0KICNlbmRpZgogCitzdGF0aWMgYm9vbCBtb2R1bGVNaXhlc0d0a1N5bWJv bHMoR01vZHVsZSogbW9kdWxlKQoreworICAgIGdwb2ludGVyIHN5bWJvbDsKKyNpZmRlZiBHVEtf QVBJX1ZFUlNJT05fMgorICAgIHJldHVybiBnX21vZHVsZV9zeW1ib2wobW9kdWxlLCAiZ3RrX2Fw cGxpY2F0aW9uX2dldF90eXBlIiwgJnN5bWJvbCk7CisjZWxzZQorICAgIHJldHVybiBnX21vZHVs ZV9zeW1ib2wobW9kdWxlLCAiZ3RrX29iamVjdF9nZXRfdHlwZSIsICZzeW1ib2wpOworI2VuZGlm Cit9CisKIGJvb2wgUGx1Z2luUGFja2FnZTo6bG9hZCgpCiB7CiAgICAgaWYgKG1faXNMb2FkZWQp IHsKQEAgLTE1MCw2ICsxNjAsMTEgQEAgYm9vbCBQbHVnaW5QYWNrYWdlOjpsb2FkKCkKICAgICAg ICAgcmV0dXJuIGZhbHNlOwogICAgIH0KIAorICAgIGlmIChtb2R1bGVNaXhlc0d0a1N5bWJvbHMo bV9tb2R1bGUpKSB7CisgICAgICAgIExPRyhQbHVnaW5zLCAiTW9kdWxlICclcycgbWl4ZXMgR1RL KyAyIGFuZCBHVEsrIDMgc3ltYm9scywgaWdub3JpbmcgcGx1Z2luLlxuIiwgbV9wYXRoLnV0Zjgo KS5kYXRhKCkpOworICAgICAgICByZXR1cm4gZmFsc2U7CisgICAgfQorCiAgICAgbV9pc0xvYWRl ZCA9IHRydWU7CiAKICNpZiBkZWZpbmVkKFhQX1VOSVgpCkluZGV4OiBXZWJLaXQtcjExODUxNS1n dGszL1NvdXJjZS9XZWJDb3JlL3BsdWdpbnMvZ3RrL1BsdWdpblZpZXdHdGsuY3BwCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIFdlYktpdC1yMTE4NTE1LWd0azMub3JpZy9Tb3VyY2UvV2ViQ29yZS9wbHVnaW5zL2d0 ay9QbHVnaW5WaWV3R3RrLmNwcAorKysgV2ViS2l0LXIxMTg1MTUtZ3RrMy9Tb3VyY2UvV2ViQ29y ZS9wbHVnaW5zL2d0ay9QbHVnaW5WaWV3R3RrLmNwcApAQCAtODM0LDI2ICs4MzQsMTEgQEAgdm9p ZCBQbHVnaW5WaWV3OjpwbHVnQWRkZWRDYWxsYmFjayhHdGtTbwogICAgIHZpZXctPnVwZGF0ZVdp ZGdldEFsbG9jYXRpb25BbmRDbGlwKCk7CiB9CiAKLXN0YXRpYyBib29sIG1vZHVsZU1peGVzR3Rr U3ltYm9scyhHTW9kdWxlKiBtb2R1bGUpCi17Ci0gICAgZ3BvaW50ZXIgc3ltYm9sOwotI2lmZGVm IEdUS19BUElfVkVSU0lPTl8yCi0gICAgcmV0dXJuIGdfbW9kdWxlX3N5bWJvbChtb2R1bGUsICJn dGtfYXBwbGljYXRpb25fZ2V0X3R5cGUiLCAmc3ltYm9sKTsKLSNlbHNlCi0gICAgcmV0dXJuIGdf bW9kdWxlX3N5bWJvbChtb2R1bGUsICJndGtfb2JqZWN0X2dldF90eXBlIiwgJnN5bWJvbCk7Ci0j ZW5kaWYKLX0KLQogYm9vbCBQbHVnaW5WaWV3OjpwbGF0Zm9ybVN0YXJ0KCkKIHsKICAgICBBU1NF UlQobV9pc1N0YXJ0ZWQpOwogICAgIEFTU0VSVChtX3N0YXR1cyA9PSBQbHVnaW5TdGF0dXNMb2Fk ZWRTdWNjZXNzZnVsbHkpOwogCi0gICAgaWYgKG1vZHVsZU1peGVzR3RrU3ltYm9scyhtX3BsdWdp bi0+bW9kdWxlKCkpKSB7Ci0gICAgICAgIExPRyhQbHVnaW5zLCAiTW9kdWxlICclcycgbWl4ZXMg R1RLKyAyIGFuZCBHVEsrIDMgc3ltYm9scywgaWdub3JpbmcgcGx1Z2luLlxuIiwgbV9wbHVnaW4t PnBhdGgoKS51dGY4KCkuZGF0YSgpKTsKLSAgICAgICAgcmV0dXJuIGZhbHNlOwotICAgIH0KLQog I2lmIGRlZmluZWQoWFBfVU5JWCkKICAgICBpZiAobV9wbHVnaW4tPnBsdWdpbkZ1bmNzKCktPmdl dHZhbHVlKSB7CiAgICAgICAgIFBsdWdpblZpZXc6OnNldEN1cnJlbnRQbHVnaW5WaWV3KHRoaXMp Owo=