Bug 1247540

stacktrace:

[jvanek@jvanek ~]$ epiphany 

(epiphany:20868): GLib-GObject-WARNING **: The property GtkSettings:gtk-button-images is deprecated and shouldn't be used anymore. It will be removed in a future version.

(epiphany:20868): GLib-GObject-WARNING **: The property GtkSettings:gtk-menu-images is deprecated and shouldn't be used anymore. It will be removed in a future version.

(epiphany:20868): GLib-GObject-WARNING **: The property GtkCellRendererPixbuf:follow-state is deprecated and shouldn't be used anymore. It will be removed in a future version.

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied

** (epiphany:20868): WARNING **: Error saving session: Error opening file '/home/jvanek/.config/epiphany/session_state.xml': Permission denied
#
# There is insufficient memory for the Java Runtime Environment to continue.
# pthread_getattr_np
# An error report file with more information is saved as:
# /home/jvanek/hs_err_pid27038.log
[thread 140127576131328 also had an error]
[thread 140127575078656 also had an error]
[thread 140127574025984 also had an error]
[thread 140127572973312 also had an error]
#
# There is insufficient memory for the Java Runtime Environment to continue.
# pthread_getattr_np
# An error report file with more information is saved as:
# /home/jvanek/hs_err_pid27042.log
[thread 139998928439040 also had an error]
[thread 139998927386368 also had an error]
[thread 139998926333696 also had an error]
[thread 139998925281024 also had an error]
[thread 140127570867968 also had an error]
[thread 140127571920640 also had an error]
openjdk version "1.8.0_51"
OpenJDK Runtime Environment (build 1.8.0_51-b16)
[thread 139998924228352 also had an error]OpenJDK 64-Bit Server VM (build 25.51-b03, mixed mode)


The not enough memory is suspicious, because it is probably thrown before actual pluginis lunch (during disovery of plugin perhaps?)

[jvanek@jvanek ~]$epiphany  http://www.walter-fendt.de/ph14e/resultant.htm

to speedup your debugging. Also note - pushing  the -Xmx (ex -Xmx1g) to plugin jvm command do not help.  The appelt above do not need 1m of ram anyway....

Web process gets stuck waiting for a sync message from the plugin process:

#0  0x00007f871f6a2540 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f87205c0e0b in WTF::ThreadCondition::timedWait(WTF::Mutex&, double) () at /lib64/libjavascriptcoregtk-4.0.so.18
#2  0x00007f87221d6c71 in WTF::BinarySemaphore::wait(double) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#3  0x00007f8720dbc616 in IPC::Connection::waitForSyncReply(unsigned long, std::chrono::duration<long, std::ratio<1l, 1000l> >, unsigned int) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#4  0x00007f8720dbcb75 in IPC::Connection::sendSyncMessage(unsigned long, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, std::chrono::duration<long, std::ratio<1l, 1000l> >, unsigned int) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#5  0x00007f8720ee4ffc in bool IPC::Connection::sendSync<Messages::WebProcessProxy::GetPluginProcessConnection>(Messages::WebProcessProxy::GetPluginProcessConnection&&, Messages::WebProcessProxy::GetPluginProcessConnection::Reply&&, unsigned long, std::chrono::duration<long, std::ratio<1l, 1000l> >, unsigned int) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#6  0x00007f8720ee4bcd in WebKit::PluginProcessConnectionManager::getPluginProcessConnection(unsigned long) () at /lib64/libwebkit2gtk-4.0.so.37
#7  0x00007f8720ee6a54 in WebKit::PluginProxy::initialize(WebKit::Plugin::Parameters const&) () at /lib64/libwebkit2gtk-4.0.so.37
#8  0x00007f87216252bc in WebCore::Page::setCanStartMedia(bool) ()
---Type <return> to continue, or q <return> to quit---
    at /lib64/libwebkit2gtk-4.0.so.37
#9  0x00007f87221d7abd in std::_Function_handler<bool (), WTF::RunLoop::TimerBase::start(double, bool)::{lambda()#1}>::_M_invoke(std::_Any_data const&) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#10 0x00007f87205c7b2a in WTF::GMainLoopSource::boolCallback() ()
    at /lib64/libjavascriptcoregtk-4.0.so.18
#11 0x00007f87205c3b7a in WTF::GMainLoopSource::boolSourceCallback(WTF::GMainLoopSource*) () at /lib64/libjavascriptcoregtk-4.0.so.18
#12 0x00007f871d2da4e3 in g_timeout_dispatch (source=0x7f8724bab400, callback=<optimized out>, user_data=<optimized out>) at gmain.c:4545
#13 0x00007f871d2d9a8a in g_main_context_dispatch (context=0x7f872447f030)
    at gmain.c:3122
#14 0x00007f871d2d9a8a in g_main_context_dispatch (context=context@entry=0x7f872447f030) at gmain.c:3737
#15 0x00007f871d2d9e20 in g_main_context_iterate (context=0x7f872447f030, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#16 0x00007f871d2da142 in g_main_loop_run (loop=0x7f872457dab0) at gmain.c:4002
#17 0x00007f87221d8190 in WTF::RunLoop::run() ()
    at /lib64/libwebkit2gtk-4.0.so.37
#18 0x00007f8720fc4daa in int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) () at /lib64/libwebkit2gtk-4.0.so.37
#19 0x00007f8717b34700 in __libc_start_main (main=
    0x7f8722c96c10 <main>, argc=2, argv=0x7ffe2098f4d8, init=<optimized out>, fi---Type <return> to continue, or q <return> to quit---
ni=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe2098f4c8)
    at libc-start.c:289
#20 0x00007f8722c96c69 in _start ()

Plugin process hang:

#0  0x00007f4ece202cdd in open64 () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f4ecbe7c77e in g_io_channel_new_file (__oflag=<optimized out>, __path=<optimized out>) at /usr/include/bits/fcntl2.h:59
        fid = <optimized out>
        flags = <optimized out>
        create_mode = 438
        channel = <optimized out>
        mode_num = <optimized out>
        buffer = 
            {st_dev = 0, st_ino = 139976404595976, st_nlink = 139976502628032, st_mode = 0, st_uid = 0, st_gid = 2310562784, __pad0 = 32767, st_rdev = 139976496798656, st_size = 139975934227304, st_blksize = 139976496747476, st_blocks = 225, st_atim = {tv_sec = 139976404974765, tv_nsec = 139976442330644}, st_mtim = {tv_sec = 303, tv_nsec = 139976442330784}, st_ctim = {tv_sec = 139976316730144, tv_nsec = 0}, __glibc_reserved = {0, 139975936965008, 139975934790232}}
        __func__ = "g_io_channel_new_file"
#2  0x00007f4ecbe7c77e in g_io_channel_new_file (filename=<optimized out>, mode=<optimized out>, error=0x7f4eaffff990) at giounix.c:527
        fid = <optimized out>
        flags = <optimized out>
        create_mode = 438
        channel = <optimized out>
        mode_num = <optimized out>
---Type <return> to continue, or q <return> to quit---
        buffer = 
            {st_dev = 0, st_ino = 139976404595976, st_nlink = 139976502628032, st_mode = 0, st_uid = 0, st_gid = 2310562784, __pad0 = 32767, st_rdev = 139976496798656, st_size = 139975934227304, st_blksize = 139976496747476, st_blocks = 225, st_atim = {tv_sec = 139976404974765, tv_nsec = 139976442330644}, st_mtim = {tv_sec = 303, tv_nsec = 139976442330784}, st_ctim = {tv_sec = 139976316730144, tv_nsec = 0}, __glibc_reserved = {0, 139975936965008, 139975934790232}}
        __func__ = "g_io_channel_new_file"
#3  0x00007f4eafd8f9bc in start_jvm_if_needed() ()
    at /usr/lib64/mozilla/plugins/libjavaplugin.so
#4  0x00007f4eafd968a5 in ITNP_New(char*, _NPP*, unsigned short, short, char**, char**, _NPSavedData*) () at /usr/lib64/mozilla/plugins/libjavaplugin.so
#5  0x00007f4ecfa5fe66 in WebKit::NetscapePlugin::initialize(WebKit::Plugin::Parameters const&) () at /lib64/libwebkit2gtk-4.0.so.37
#6  0x00007f4ecf91e361 in WebKit::PluginControllerProxy::initialize(WebKit::PluginCreationParameters const&) () at /lib64/libwebkit2gtk-4.0.so.37
#7  0x00007f4ecf9226ff in WebKit::WebProcessConnection::createPluginInternal(WebKit::PluginCreationParameters const&, bool&, bool&, unsigned int&) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#8  0x00007f4ecf922946 in WebKit::WebProcessConnection::createPlugin(WebKit::PluginCreationParameters const&, WTF::PassRefPtr<Messages::WebProcessConnection::CreatePlugin::DelayedReply>) () at /lib64/libwebkit2gtk-4.0.so.37
#9  0x00007f4ecfb2ba41 in void IPC::handleMessageDelayed<Messages::WebProcessCon---Type <return> to continue, or q <return> to quit---
nection::CreatePlugin, WebKit::WebProcessConnection, void (WebKit::WebProcessConnection::*)(WebKit::PluginCreationParameters const&, WTF::PassRefPtr<Messages::WebProcessConnection::CreatePlugin::DelayedReply>)>(IPC::Connection&, IPC::MessageDecoder&, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >&, WebKit::WebProcessConnection*, void (WebKit::WebProcessConnection::*)(WebKit::PluginCreationParameters const&, WTF::PassRefPtr<Messages::WebProcessConnection::CreatePlugin::DelayedReply>)) () at /lib64/libwebkit2gtk-4.0.so.37
#10 0x00007f4ecfb2b888 in WebKit::WebProcessConnection::didReceiveSyncWebProcessConnectionMessage(IPC::Connection&, IPC::MessageDecoder&, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >&) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#11 0x00007f4ecf921f41 in WebKit::WebProcessConnection::didReceiveSyncMessage(IPC::Connection&, IPC::MessageDecoder&, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >&) () at /lib64/libwebkit2gtk-4.0.so.37
#12 0x00007f4ecf918eab in IPC::Connection::dispatchSyncMessage(IPC::MessageDecoder&) () at /lib64/libwebkit2gtk-4.0.so.37
#13 0x00007f4ecf918f75 in IPC::Connection::dispatchMessage(std::unique_ptr<IPC::MessageDecoder, std::default_delete<IPC::MessageDecoder> >) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#14 0x00007f4ecf9190c7 in IPC::Connection::SyncMessageState::dispatchMessages(IPC::Connection*) () at /lib64/libwebkit2gtk-4.0.so.37
#15 0x00007f4ed0d30d31 in WTF::RunLoop::performWork() ()
    at /lib64/libwebkit2gtk-4.0.so.37
---Type <return> to continue, or q <return> to quit---
#16 0x00007f4ecf124955 in WTF::GMainLoopSource::voidCallback() ()
    at /lib64/libjavascriptcoregtk-4.0.so.18
#17 0x00007f4ecf120b5a in WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*) () at /lib64/libjavascriptcoregtk-4.0.so.18
#18 0x00007f4ecbe36a8a in g_main_context_dispatch (context=0x7f4ed1a6edf0)
    at gmain.c:3122
        dispatch = 0x7f4ecbe33530 <g_idle_dispatch>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x7f4eaf7ed0b0
        callback = 0x7f4ecf120b50 <WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*)>
        cb_funcs = 0x7f4ecc1258a0 <g_source_callback_funcs>
        cb_data = 0x7f4e68002330
        need_destroy = <optimized out>
        source = 0x7f4e680022a0
        current = 0x7f4ed1a58b00
        i = 2
#19 0x00007f4ecbe36a8a in g_main_context_dispatch (context=context@entry=0x7f4ed1a6edf0) at gmain.c:3737
#20 0x00007f4ecbe36e20 in g_main_context_iterate (context=0x7f4ed1a6edf0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
        max_priority = 0
---Type <return> to continue, or q <return> to quit---
        timeout = 0
        some_ready = 1
        nfds = <optimized out>
        allocated_nfds = 3
        fds = 0x7f4ed1adba70
#21 0x00007f4ecbe37142 in g_main_loop_run (loop=0x7f4ed1baa260) at gmain.c:4002
        __func__ = "g_main_loop_run"
#22 0x00007f4ed0d35190 in WTF::RunLoop::run() ()
    at /lib64/libwebkit2gtk-4.0.so.37
#23 0x00007f4ecfaad707 in int WebKit::ChildProcessMain<WebKit::PluginProcess, WebKit::PluginProcessMain>(int, char**) () at /lib64/libwebkit2gtk-4.0.so.37
#24 0x00007f4ec6691700 in __libc_start_main (main=
    0x7f4ed17f3bd0 <main>, argc=3, argv=0x7fff89b86c88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff89b86c78)
    at libc-start.c:289
        result = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {0, 64352017776512830, 139976498953184, 140735503953024, 0, 0, 109826226826645310, 64371998886072126}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7fff89b86ca8, 0x7f4ed17f2148}, data = {prev = 0x0, cleanup = 0x0, canceltype = -1984402264}}}
        not_first_call = <optimized out>
#25 0x00007f4ed17f3c09 in _start ()

cgarcia:  start_jvm_if_needed() that's not our code
cgarcia:  it's plugin code
mcatanzaro:  Yeah but it is hanging in a syscall, which is pretty crazy.
mcatanzaro:  The call to open64 has not returned for like 5 minutes
mcatanzaro:  That is weird

cgarcia says it works in Debian, so maybe it's a Fedora problem. Jiri, are you able to 'sudo dnf downgrade webkitgtk4'? There is a chance this is a regression in 2.8.4-2.fc22, in which I added an address space limit of 5 GB, which was intended to stop the web process from running out of control, but also applies to the plugin process. It will be easy to remove the limit from the plugin process if that turns out to be the problem, but I'm not sure it's the problem. I can't test it myself because 'sudo dnf downgrade webkitgtk4' is trying to install a ton of i686 packages for me, which is really weird; I hope that's not broken for everyone, as I suspect....

BTW my theory is that the JVM tries to allocate a huge amount of address space, which WebKit prohibits, in order to have lots of room to perform ASLR. It could be a problem even for applets that use a very small portion of that address space. The only reason I suspect this is the insufficient memory error; it is a shot in the dark, really.

> webkitgtk-2.4.9-1.fc21.x86_64
> webkitgtk3-2.4.9-1.fc21.x86_64
> webkitgtk4-2.6.6-1.fc21.x86_64

worked

< webkitgtk-2.4.9-1.fc22.x86_64
< webkitgtk3-2.4.9-1.fc22.x86_64
< webkitgtk4-2.8.4-2.fc22.x86_64

not worked.


thats from my test logs, but in same transction epiphany was updated. Do you wont more granular research?

The webkitgtk and webkitgtk3 packages do not matter; they are obsolete. Any applications you have still using those (e.g. Evolution) are not safe to use, unfortunately. Epiphany only uses webkitgtk4.

Anyway, it would be really interesting to know if the problem exists in webkitgtk4-2.8.n with n < 2.8.4-2, as if my theory below is correct, then the problem must have been introduced for the first time in 2.8.4-2:


I see a log file was created in my home directory when the JVM failed to start. It includes:

---------------  S Y S T E M  ---------------

OS:Fedora release 22 (Twenty Two)

uname:Linux 4.0.8-300.fc22.x86_64 #1 SMP Fri Jul 10 21:04:56 UTC 2015 x86_64
libc:glibc 2.21 NPTL 2.21 
rlimit: STACK 8192k, CORE 0k, NPROC 4096, NOFILE 4096, AS 4882812k
load average:0.17 0.29 0.31

/proc/meminfo:
MemTotal:        8077808 kB
MemFree:         3587104 kB
MemAvailable:    5283772 kB
Buffers:          564056 kB
Cached:          1496816 kB
SwapCached:            0 kB
Active:          2991772 kB
Inactive:        1001244 kB
Active(anon):    1934388 kB
Inactive(anon):   372088 kB
Active(file):    1057384 kB
Inactive(file):   629156 kB
Unevictable:         136 kB
Mlocked:             136 kB
SwapTotal:       8126460 kB
SwapFree:        8126460 kB
Dirty:               300 kB
Writeback:             0 kB
AnonPages:       1932504 kB
Mapped:           475480 kB
Shmem:            374340 kB
Slab:             336236 kB
SReclaimable:     263544 kB
SUnreclaim:        72692 kB
KernelStack:       13712 kB
PageTables:        55744 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12165364 kB
Committed_AS:    8180936 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      390060 kB
VmallocChunk:   34359343416 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      137648 kB
DirectMap2M:     2910208 kB
DirectMap1G:     6291456 kB

rlimit: AS 4882812 kB is the new address space limit for plugins. 

If my rudimentary understanding is correct, this line:

VmallocTotal:   34359738367 kB

Indicates we're blowing waaay past the limit. So the JVM wants all the address space it can get and intends to make use of it. If I'm correct, I think this is my fault: it's reasonable for Java to use as much address space as it wants, so long as it stores data in only a very small portion of that address space. One reason to allocate such a huge amount of AS is to improve ASLR.

See [1] for why a very crude address space limit is desirable for WebKit's web process. I am going to try a build with the plugin process exempted from this limit, which will fix the problem, unless I have totally misread the above.

[1] https://bugs.webkit.org/show_bug.cgi?id=146793

(In reply to Michael Catanzaro from comment #8)
> The webkitgtk and webkitgtk3 packages do not matter; they are obsolete. Any
> applications you have still using those (e.g. Evolution) are not safe to
> use, unfortunately. Epiphany only uses webkitgtk4.
> 
> Anyway, it would be really interesting to know if the problem exists in
> webkitgtk4-2.8.n with n < 2.8.4-2, as if my theory below is correct, then
> the problem must have been introduced for the first time in 2.8.4-2:

Yes.  2.8.4-1 works fine.

And confirming again, update to 2.8.4.2 and it is failing again. SO at least it was catch quickly.

Thanks for testing Jiri. I have a fix building now, and will try to get a test update out later today. Fedora is having trouble with updates right now so it might take a few days to reach updates-testing, but when it does, please try it to make sure I didn't screw up the fix.

Please share the build links here. I will test (and kepp my slave machine updated as I need this testsuite to be working)

OK:

F22: http://koji.fedoraproject.org/koji/taskinfo?taskID=10511108
F23: http://koji.fedoraproject.org/koji/taskinfo?taskID=10511208
rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=10511210

webkitgtk4-2.8.4-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/webkitgtk4-2.8.4-3.fc22

I was not studying updates in details, but why only f22? I guess also f21 (and of course f23 and rawhide) would be affected

yup. update fixed an issue. Karemd++

(In reply to jiri vanek from comment #15)
> I was not studying updates in details, but why only f22? I guess also f21
> (and of course f23 and rawhide) would be affected

rawhide never requires updates; simply build the package successfully and it makes its way into rawhide the next day. That currently applies for F23 as well, until bodhi is enabled (which should happen any day now).

Unfortunately we're not providing any WebKitGTK+ updates for F21 anymore. There is disagreement over whether the high risk of regressions outweighs the cost of never fixing any security bugs. So you just have to stay on the latest Fedora if you want a safe version of WebKitGTK+. I know this is a problem; we need to find a way to better communicate this to users.

(In reply to Michael Catanzaro from comment #17)
> Unfortunately we're not providing any WebKitGTK+ updates for F21 anymore.

To be clear, F21 was never affected by this regression.

(In reply to Michael Catanzaro from comment #17) 
> rawhide never requires updates; simply build the package successfully and it
> makes its way into rawhide the next day. That currently applies for F23 as
> well, until bodhi is enabled (which should happen any day now).

As a heads-up, your plugin is going to break in F23 again, since we have no plans to support NPAPI under Wayland, unless someone volunteers to implement it. See: https://bugs.webkit.org/show_bug.cgi?id=147297

Package webkitgtk4-2.8.4-3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing webkitgtk4-2.8.4-3.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-12313/webkitgtk4-2.8.4-3.fc22
then log in and leave karma (feedback).

(In reply to Michael Catanzaro from comment #19)
> (In reply to Michael Catanzaro from comment #17) 
> > rawhide never requires updates; simply build the package successfully and it
> > makes its way into rawhide the next day. That currently applies for F23 as
> > well, until bodhi is enabled (which should happen any day now).
> 
> As a heads-up, your plugin is going to break in F23 again, since we have no
> plans to support NPAPI under Wayland, unless someone volunteers to implement
> it. See: https://bugs.webkit.org/show_bug.cgi?id=147297

tahnx for this info ;(

(In reply to jiri vanek from comment #21)
> (In reply to Michael Catanzaro from comment #19)
> > (In reply to Michael Catanzaro from comment #17) 
> > > rawhide never requires updates; simply build the package successfully and it
> > > makes its way into rawhide the next day. That currently applies for F23 as
> > > well, until bodhi is enabled (which should happen any day now).
> > 
> > As a heads-up, your plugin is going to break in F23 again, since we have no
> > plans to support NPAPI under Wayland, unless someone volunteers to implement
> > it. See: https://bugs.webkit.org/show_bug.cgi?id=147297
> 
> tahnx for this info ;(

btw - what plugin apis will be supported?

(In reply to Michael Catanzaro from comment #19)
> (In reply to Michael Catanzaro from comment #17) 
> > rawhide never requires updates; simply build the package successfully and it
> > makes its way into rawhide the next day. That currently applies for F23 as
> > well, until bodhi is enabled (which should happen any day now).
> 
> As a heads-up, your plugin is going to break in F23 again, since we have no
> plans to support NPAPI under Wayland, unless someone volunteers to implement
> it. See: https://bugs.webkit.org/show_bug.cgi?id=147297

There is an patch attached to the upstream bug. It was not working?

(In reply to jiri vanek from comment #22) 
> btw - what plugin apis will be supported?

None; I don't think we intend to support browser plugins going forward, sorry. It's possible this could happen if someone either contributes NPAPI support for Wayland or if a company wants to pay for the development, but many of us are unenthusiastic about plugins.

(In reply to jiri vanek from comment #23)
> There is an patch attached to the upstream bug. It was not working?

That patch is to disable the NPAPI support cleanly, so that WebKit doesn't attempt to run X11-specific code and crash.

My knowledge of IcedTea-Web and Wayland is pretty limited, but, as I understand it, even if there was an NPAPI implementation on top of Wayland, I can't see how it would help with IcedTea-Web anyway, as OpenJDK doesn't yet have any way to draw on Wayland surfaces anyway; it relies on XEmbed support.

webkitgtk4-2.8.4-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.