Comment 1 Andrey Loskutov 2018-04-13 08:07:40 EDT

rpm -qa | grep webkit
webkitgtk4-jsc-2.14.7-2.el7.x86_64
webkitgtk4-plugin-process-gtk2-2.14.7-2.el7.x86_64
webkitgtk4-2.14.7-2.el7.x86_64
webkitgtk3-2.4.11-2.el7.x86_64

Comment 2 Andrey Loskutov 2018-04-13 08:11:01 EDT

Created attachment 273590 [details]
second JVM crash dump

Second crash had a slightly different stack, but seem to be rooted at the same code:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fffbe0eff74, pid=29777, tid=0x00007ffff7fcd700
#
# JRE version: OpenJDK Runtime Environment (8.0_131-b12) (build 1.8.0_131-b12)
# Java VM: OpenJDK 64-Bit Server VM (25.131-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libgobject-2.0.so.0+0x31f74]  g_type_check_instance_is_a+0x44
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /data2/eclipse4.8/eclipse/hs_err_pid29777.log


Stack: [0x00007ffff7ecd000,0x00007ffff7fce000],  sp=0x00007ffff7fca698,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgobject-2.0.so.0+0x31f74]  g_type_check_instance_is_a+0x44
J 4980 C1 org.eclipse.swt.internal.gtk.GTK.gtk_widget_get_parent(J)J (29 bytes) @ 0x00007fffe1f47eec [0x00007fffe1f47e60+0x8c]
j  org.eclipse.swt.browser.WebKit.FindBrowser(J)Lorg/eclipse/swt/browser/Browser;+9
j  org.eclipse.swt.browser.WebKit.Proc(JJJ)J+134
v  ~StubRoutines::call_stub
V  [libjvm.so+0x66bb4a]
V  [libjvm.so+0x67d1ea]
V  [libjvm.so+0x6901af]
C  [libswt-gtk-4871.so+0x374ba]  callback+0x2da

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 4945  org.eclipse.swt.internal.gtk.GTK._gtk_widget_get_parent(J)J (0 bytes) @ 0x00007fffe1f23501 [0x00007fffe1f234c0+0x41]
J 4980 C1 org.eclipse.swt.internal.gtk.GTK.gtk_widget_get_parent(J)J (29 bytes) @ 0x00007fffe1f47eec [0x00007fffe1f47e60+0x8c]
j  org.eclipse.swt.browser.WebKit.FindBrowser(J)Lorg/eclipse/swt/browser/Browser;+9
j  org.eclipse.swt.browser.WebKit.Proc(JJJ)J+134
v  ~StubRoutines::call_stub
J 1997  org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(JZ)Z (0 bytes) @ 0x00007fffe174ff44 [0x00007fffe174ff00+0x44]
J 31930 C2 org.eclipse.swt.widgets.Display.readAndDispatch()Z (71 bytes) @ 0x00007fffe1766430 [0x00007fffe17661e0+0x250]
J 31624% C1 org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run()V (703 bytes) @ 0x00007fffe60635ac [0x00007fffe605d0a0+0x650c]

Comment 3 Andrey Loskutov 2018-04-13 08:23:08 EDT

I have now core dump (~5GB), so if some additional info is needed, I can provide it. But as far as I can see this is pretty stable and seem to crash every second time at least. 

Funny enough, if it does NOT crash, it opens the *empty* browser editor AND a file dialog pre-selected with that file I'm trying to open!?!

Comment 4 Andrey Loskutov 2018-04-13 08:29:03 EDT

gdb /usr/bin/java core.2147

Program terminated with signal 6, Aborted.
#0  0x00007ffff72081f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos ...

(gdb) bt
#0  0x00007ffff72081f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff72098e8 in __GI_abort () at abort.c:90
#2  0x00007ffff6ac1eb9 in os::abort(bool) (dump_core=<optimized out>)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1513
#3  0x00007ffff6cc0c46 in VMError::report_and_die() (this=this@entry=0x7ffff7fc9f50)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1060
#4  0x00007ffff6acbb17 in JVM_handle_linux_signal(int, siginfo_t*, void*, int) (sig=11, info=0x7ffff7fca1f0, ucVoid=0x7ffff7fca0c0, abort_if_unrecognized=<optimized out>)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:556
#5  0x00007ffff6abf2d8 in signalHandler(int, siginfo_t*, void*) (sig=11, info=0x7ffff7fca1f0, uc=0x7ffff7fca0c0)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4440
#6  0x00007ffff7bce5e0 in <signal handler called> () at /lib64/libpthread.so.0
#7  0x00007fff7fa7d4e6 in gtk_widget_get_parent () at /lib64/libgtk-3.so.0
#8  0x00007fff5b4e9553 in Java_org_eclipse_swt_internal_gtk_GTK__1gtk_1widget_1get_1parent ()
    at /data2/eclipse4.8/eclipse/configuration/org.eclipse.osgi/218/0/.cp/libswt-pi3-gtk-4871.so
#9  0x00007fffe223f6f9 in  ()
#10 0x000000000000006c in  ()
#11 0x00007ffeb570f2a5 in WTF::StringImpl::removeCharacters(bool (*)(unsigned short)) () at /lib64/libjavascriptcoregtk-4.0.so.18
#12 0x00000005c069eee0 in  ()
#13 0x00007ffff7fca788 in  ()
#14 0x00007fffe1007ffd in  ()
#15 0x00007ffff7fca798 in  ()
#16 0x00007fffe1007b10 in  ()
#17 0x00007fffe1007b10 in  ()
#18 0x00007ffff3ddc3f0 in  ()
#19 0x00007fff5b9a71f1 in  ()
#20 0x00007ffff7fca758 in  ()
#21 0x00007fff59a9b7a1 in  ()
#22 0x00007ffff7fca7c0 in  ()
#23 0x00007fff59aaa828 in  ()
#24 0x0000000000000000 in  ()

Comment 5 Leo Ufimtsev 2018-04-13 09:58:05 EDT

Thank you for bug report. Let me take a look.

Comment 6 Leo Ufimtsev 2018-04-13 10:53:41 EDT

Are you using Webkit1 or webkit2 btw?

Can you give me build info output? (btw, build info is useful for bug reports)

help > about -> right click on main white plane -> copy build information.
Should look something like this:
Eclipse SDK
Version: Photon (4.8)
Build id: I20180228-2000
OS: Linux, v.4.15.6-300.fc27.x86_64, x86_64 / gtk 3.22.26, WebKit 2.18.6

Build info shows what's running as oppose to what's installed.
Like you both have webkit1 and webkit2 installed, but I can't tell which
one is running based on stack trace.

Btw, doesn't reproduce on my Fedora 27 with build info above.
I might have to try with a RHEL vm or something.

Comment 7 Andrey Loskutov 2018-04-13 11:02:56 EDT

Eclipse SDK
Version: Photon (4.8)
Build id: I20180411-2000
OS: Linux, v.3.10.0-693.11.6.el7.x86_64, x86_64 / gtk 3.22.10

I don't know what webkit is used, because I haven't configured anything special. The libraries loaded by the JVM should be shown in the crash file.

Comment 8 Leo Ufimtsev 2018-04-13 12:18:28 EDT

(In reply to Andrey Loskutov from comment #7)
> Eclipse SDK
> Version: Photon (4.8)
> Build id: I20180411-2000
> OS: Linux, v.3.10.0-693.11.6.el7.x86_64, x86_64 / gtk 3.22.10
> 
> I don't know what webkit is used, because I haven't configured anything
> special. The libraries loaded by the JVM should be shown in the crash file.

Ah, thank you for tip. That's useful. Looks like you're on webkit2:
    $ cat hs_err_pid29777.log | grep webkit
    cat hs_err_pid29777.log | grep webkit
    ..... /usr/lib64/webkit2gtk-4.0/
    (webkit2gtk-4 == gtk3 with webkit2 bindings).

Issue doesn't occur in my testing thou.

I tried RHEL7.4 (which has webkit 2.14 similar to your setup):
   Eclipse SDK
   Version: Photon (4.8)
   Build id: I20180412-2000   (yours was from 11th april, this one is 12th April).
   OS: Linux, v.3.10.0-693.11.1.el7.x86_64, x86_64 / gtk 3.22.10, WebKit 2.14.7

My *exact* steps were as following:
- Fresh RHEL 7.4
- Download eclipse sdk as above from nightlies
- Import /org.eclipse.swt.cocoa.macosx.x86_64 as project
- open about.html
- Also tried importing other bundle projects and also try the html files.

~no fails here. Works fine. I tried opening/closing html files like 20 times.

At first, I thought that maybe my recent disposal fix was related:
https://git.eclipse.org/r/#/c/120730/
As that unparents the webkit instance. But that fix is guarded and only runs on webkit2.18+, so not on your system.

So I'm kinda wondering what's going on.

Well, if I can't reproduce it, it's a bit tricky to fix.
I could try to implement a fix based on what I think might be going wrong, but it would be better if
we're able to actually figure out what's broken.

We need to try and narrow down.
1) Maybe there is an issue in webkit logic. 
2) Maybe there is an issue in SWT logic.
3) Maybe there is an issue with your environment.

I take it this is a regression. Can you bisect a bit and try something from march?
http://download.eclipse.org/eclipse/downloads/

And/or can you type up more detailed steps & info about environment that would be relevant for me to reproduce the issue?

I'm open to suggestions thou.

Thanks.

Comment 9 Leo Ufimtsev 2018-04-13 12:25:25 EDT

Btw, can you test an SWT patch with a child eclipse? (no native changes, just some change change, so no need to rebuild bindings).

If I can't reproduce the issue, then one option is I could still submit a  patch and have you test it.

Comment 10 Andrey Loskutov 2018-04-13 12:28:07 EDT

(In reply to Leo Ufimtsev from comment #9)
> Btw, can you test an SWT patch with a child eclipse? (no native changes,
> just some change change, so no need to rebuild bindings).
> 
> If I can't reproduce the issue, then one option is I could still submit a 
> patch and have you test it.

Sure, just push something to Gerrit :-)

Comment 11 Eclipse Genie 2018-04-13 15:35:32 EDT

New Gerrit change created: https://git.eclipse.org/r/121163

Comment 12 Leo Ufimtsev 2018-04-13 15:38:25 EDT

(In reply to Andrey Loskutov from comment #10)
> (In reply to Leo Ufimtsev from comment #9)
> > Btw, can you test an SWT patch with a child eclipse? (no native changes,
> > just some change change, so no need to rebuild bindings).
> > 
> > If I can't reproduce the issue, then one option is I could still submit a 
> > patch and have you test it.
> 
> Sure, just push something to Gerrit :-)

I did some code reading and thought-investigation based on what could be causing the segfault.

There's one spot where the webkit handle is being (temporarily?) replaced with user data:
webView = user_data;

It's possible that this somehow manages to reach FindBrowser(webView),
which then calls get parent(), and gtk has throws a segfault as userdata!=widget handle.

To test the theory, could you checkout this patch, launch a test eclipse and see if that stops the crash?
https://git.eclipse.org/r/#/c/121163/

If this stops the crash, then we will investigate a way to fix this.

Comment 13 Andrey Loskutov 2018-04-16 04:03:03 EDT

Created attachment 273619 [details]
File selection dialog?!?

(In reply to Leo Ufimtsev from comment #12)
> (In reply to Andrey Loskutov from comment #10)
> > (In reply to Leo Ufimtsev from comment #9)
> > > Btw, can you test an SWT patch with a child eclipse? (no native changes,
> > > just some change change, so no need to rebuild bindings).
> > > 
> > > If I can't reproduce the issue, then one option is I could still submit a 
> > > patch and have you test it.
> > 
> > Sure, just push something to Gerrit :-)
> 
> I did some code reading and thought-investigation based on what could be
> causing the segfault.
> 
> There's one spot where the webkit handle is being (temporarily?) replaced
> with user data:
> webView = user_data;
> 
> It's possible that this somehow manages to reach FindBrowser(webView),
> which then calls get parent(), and gtk has throws a segfault as
> userdata!=widget handle.
> 
> To test the theory, could you checkout this patch, launch a test eclipse and
> see if that stops the crash?
> https://git.eclipse.org/r/#/c/121163/
> 
> If this stops the crash, then we will investigate a way to fix this.

The patch fixes the crash, and I see in debugger on a *six* call to org.eclipse.swt.browser.WebKit.Proc(long, long, long) it crashes at line 819 (on master), where we do: Browser browser = FindBrowser (webView);

Do you have some ideas what I should check for?


BTW if the webkit does NOT crash, I see a file selection dialog (!?!?) with this backtrace (see screenshot):

Thread [main] (Suspended)	
	GTK._gtk_dialog_run(long) line: not available [native method]	
	GTK.gtk_dialog_run(long) line: 1769	
	FileDialog.openChooserDialog() line: 351	
	FileDialog.open() line: 302	
	WebKit.webkit_download_decide_destination(long, long) line: 2937	
	WebKit.webViewProc(long, long, long) line: 965	
	WebKit.Proc(long, long, long) line: 823	
	OS._g_main_context_iteration(long, boolean) line: not available [native method]	
	OS.g_main_context_iteration(long, boolean) line: 1565	
	Display.readAndDispatch() line: 4499

Comment 14 Andrey Loskutov 2018-04-16 04:35:33 EDT

What is also interesting, in ALL cases (with/without the patch), the browser shows totally *empty* page. Mozilla / Vivaldi / Konqueror show the content of the page without any problems. I've tried different about.html pages from all SWT projects with no luck :-(

Also entering the path manually into the (empty) webkit window doesn't work, browser stays empty.

It looks like webkit crashes on: 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">


This snippet is BAD (crash or empty browser):

####################
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>About</title>
</head>
<body lang="EN-US">
<h2>About This Content</h2>

<p>January 2, 2014</p>
<h3>License</h3>

</body>
</html>
####################


This snippet is OK (no crash, content is shown):

####################
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>About</title>
</head>
<body lang="EN-US">
<h2>About This Content</h2>

<p>January 2, 2014</p>
<h3>License</h3>

</body>
</html>
####################

Comment 15 Andrey Loskutov 2018-04-16 07:59:31 EDT

We are on RHEL 7.4 and I can reproduce the *crash* with 4.8 master but not with 4.7.3a, so this is obviously a regression.

On both 4.7.3a and 4.8 master *if* Eclipse does not crash, I see the "File Download" dialog on a trivial page.

On RHEL 7.2 I see the page as expected, but there is no webkit2.

So this is most likely a bug in webkit2 we have on RHEL 7.4 (webkitgtk4-2.14.7-2.el7.x86_64).

Looking around in code, I guess the fix for bug 525946 ([Webkit2] Port download functionality to WebKit2) could be part of the problem.

Marking this as a blocker & target to 4.8.

Comment 16 Leo Ufimtsev 2018-04-16 10:06:57 EDT

Thank you for investigation. 

Yea, I have a feeling it's caused by swapping user data and handle.

The patch I uploaded just blindly ignores that code, not taking into account the remaining download functionality. So some odd behavior can be expected. Sorry, I should have clarified.

I'm going to investigate now to see what we can do to improve this logic.

Comment 17 Leo Ufimtsev 2018-04-16 10:47:06 EDT

(In reply to Andrey Loskutov from comment #14)
> This snippet is BAD (crash or empty browser):
> 
> ####################
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
> <title>About</title>
> </head>
> <body lang="EN-US">
> <h2>About This Content</h2>
> 
> <p>January 2, 2014</p>
> <h3>License</h3>
> 
> </body>
> </html>
> ####################
> 

I tested with my RHEL 7.4 with the snippet above, but crash did not occur.
Eclipse SDK, Version: Photon (4.8), Build id: I20180412-2000
OS: Linux, v.3.10.0-693.11.1.el7.x86_64, x86_64 / gtk 3.22.10, WebKit 2.14.7

My webkit is very similar to yours:
Yours: webkitgtk4  2.14.7-2.el7
Mine:  webkitgtk4  2.14.7-3.el7

So it doesn't seem to be specific to that version of Webkit. Hmmm.

I think the source of issue is in the SWT 'handle' logic (rather than theme or desktop manager).
I think we can probably fix the issue without being able to reproduce it. 
But if I can reproduce the issue, it would help me test patches.

I recall I once fixed an issue that only occurred on Ubuntu, but my investigation turned out that
the fault also occurred on fedora/rhel, but on those systems the fault was 'swallowed'/ignored.
I have a feeling that we have the issue but in my setup it's being 'swallowed'/ignored


Questions:
I could try to make my RHEL more similar to your RHEL. 
a) Which desktop manager are you using, Gnome/KDE/mate etc..?
b) Did you change the theme to 'Clearlooks-Phenix' or did it come with the desktop manager that you're using?

If not too time consuming:
 are you able to test with:
1) default gnome desktop 
(https://linuxconfig.org/install-gnome-gui-on-rhel-7-linux-server)
2) Try default Adwaita theme.

Those would help me to setup a similar test environment.

Thank you.

Comment 18 Alexander Kurtakov 2018-04-16 10:53:16 EDT

Actually, it's worth trying with the latest webkit4 in this RHEL version as there might be some webkit fix in the rebuild that causes the difference for you. Andrey, can you please update?

Comment 19 Andrey Loskutov 2018-04-16 10:56:23 EDT

(In reply to Leo Ufimtsev from comment #17)
> Questions:
> I could try to make my RHEL more similar to your RHEL. 
> a) Which desktop manager are you using, Gnome/KDE/mate etc..?

KDE

> b) Did you change the theme to 'Clearlooks-Phenix' or did it come with the
> desktop manager that you're using?

We did. BTW, Simeon, looks like we didn't pushed latest patches to https://github.com/iloveeclipse/clearlooks-phenix/commits/master?
 
> If not too time consuming:
>  are you able to test with:
> 1) default gnome desktop 

No idea how to install it, I believe it is not there in our environment (we are KDE only).

> (https://linuxconfig.org/install-gnome-gui-on-rhel-7-linux-server)
> 2) Try default Adwaita theme.

I will try this tomorrow.

Comment 20 Andrey Loskutov 2018-04-16 10:58:15 EDT

(In reply to Alexander Kurtakov from comment #18)
> Actually, it's worth trying with the latest webkit4 in this RHEL version as
> there might be some webkit fix in the rebuild that causes the difference for
> you. Andrey, can you please update?

webkit*4*? How do I get it?

I'm not sure if our Linux admins allow us to see "latest greatest" repos from RHEL, we are pretty locked here. Also if this is not available for RHEL 7.4 we will not rollout it on our workstations anyway (even if I manage to update it locally).

Comment 21 Leo Ufimtsev 2018-04-16 17:00:53 EDT

I setup a RHEL 7.4 with KDE.
I downloaded eclipse I20180411-2000 (as per bug report).
I observed that this RHEL has webkit 2.14.7-2.el7, which is exactly the same as what you reported to have.

I tried to open an html file with the content that you reported would crash your eclipse:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>About</title>
</head>
<body lang="EN-US">
<h2>About This Content</h2>

<p>January 2, 2014</p>
<h3>License</h3>

</body>
</html>

However, crash still did not occur.

Can you think of anything else that is different in your environment that could be related to this crash?
(Think desktop manager configuration, additional packages related to gtk/webkit).
(btw, can you try with the default theme that shipps with RHEL 7.4/KDE, does crash occur? If not, how do I setup your custom theme?).

In the mean time, I will inspect the webkit2PortDownload patch and look for a way to improve it.
When I have a patch ready, I will upload it for you to try out.

Comment 22 Andrey Loskutov 2018-04-16 17:12:25 EDT

I have a dual monitor setup, which seem to confuse GTK3 a bit (in the another bug I could reproduce GTK3 issues on second monitor only). Beside this, I don't have an idea why it is not crashing for you. BTW, do you observe *empty* browser window with "File download" dialog if you open this file?

Comment 23 Leo Ufimtsev 2018-04-16 17:56:45 EDT

(In reply to Andrey Loskutov from comment #22)
> I have a dual monitor setup, which seem to confuse GTK3 a bit (in the
> another bug I could reproduce GTK3 issues on second monitor only). Beside
> this, I don't have an idea why it is not crashing for you. BTW, do you
> observe *empty* browser window with "File download" dialog if you open this
> file?

I can't imagine dual monitors would cause webkit issues.
No, I don't see 'File download' dialogue, but I haven't tested with the patch, just with a vanilla eclipse Build I20180411-2000.

Ok, well, I'll look for a way to update the download port that doesn't switch user data and handle, which should hopefully fix this issue.

I'll upload a patch for testing when ready.

Comment 24 Andrey Loskutov 2018-04-17 03:03:32 EDT

Just tried with Adwaita, with same crash as before. So this isn't theme related, I guess this is webkit / download thing related. Are there some additional packages webkit requires, which could be missing on my workstation?

I still can't understand why on earth webkit wants to *download* something for *bad* html file?

(In reply to Leo Ufimtsev from comment #23)
> No, I don't see 'File download' dialogue, but I haven't tested with the
> patch, just with a vanilla eclipse Build I20180411-2000.

I think you misunderstand me. 

1) There is no need in a specific SDK build. I'm running latest SWT master from debugger and it crashes.
2) The "File download" is not the effect of your attached patch, it is a symptom of something broken in my webkit, same as the empty window I see in the case it does not crash some times.

So even it does not crash, can you see *any* content in the browser for the provided "BAD" html example, or is the browser window empty?

Just wondering: where except SWT webkit is used on RHEL? Can I open some "Gnome" browser using it, and see if it crashes too?

Comment 25 Alexander Kurtakov 2018-04-17 03:23:10 EDT

Try with epiphany - it's the gnome browser based on webkit.

Comment 26 Alexander Kurtakov 2018-04-17 03:25:48 EDT

Another thought - do you have additional browser plugins installed? I remember the times when google talk and bluejeans plugins were causing crashes. 
Does the issue happen with different user on same machine? Just to rule out some possible user installed and/or stalled config.

Comment 27 Andrey Loskutov 2018-04-17 03:37:24 EDT

(In reply to Alexander Kurtakov from comment #25)
> Try with epiphany - it's the gnome browser based on webkit.

epiphany is not available in our RHEL 7.4 or we have no repositories configured containing this package.

(In reply to Alexander Kurtakov from comment #26)
> Another thought - do you have additional browser plugins installed? 

Not that I know.

rpm -qa | grep webkit
webkitgtk4-jsc-2.14.7-2.el7.x86_64
webkitgtk4-plugin-process-gtk2-2.14.7-2.el7.x86_64
webkitgtk4-2.14.7-2.el7.x86_64
webkitgtk3-2.4.11-2.el7.x86_64

> Does the issue happen with different user on same machine? Just to rule out
> some possible user installed and/or stalled config.

Will try. @Simeon: can *you* please also check on my machine?

Comment 28 Andrey Loskutov 2018-04-17 03:53:43 EDT

OK, this seems to be user specific. I have no idea where to look for, I have never touched anything related to webkit. Are there some webkit specific settings of GTK somewhere?

Comment 29 Alexander Kurtakov 2018-04-17 04:19:07 EDT

(In reply to Andrey Loskutov from comment #28)
> OK, this seems to be user specific. I have no idea where to look for, I have
> never touched anything related to webkit. Are there some webkit specific
> settings of GTK somewhere?

IIRC webkit and firefox share the cache for browser plugins so if you have installed smth for firefox it might be borking webkit.

Comment 30 Andrey Loskutov 2018-04-17 07:51:27 EDT

(In reply to Alexander Kurtakov from comment #29)
> (In reply to Andrey Loskutov from comment #28)
> > OK, this seems to be user specific. I have no idea where to look for, I have
> > never touched anything related to webkit. Are there some webkit specific
> > settings of GTK somewhere?
> 
> IIRC webkit and firefox share the cache for browser plugins so if you have
> installed smth for firefox it might be borking webkit.

renaming ~/.mozilla did not help.

I found also
~/.local.kde4/share/webkitgtk 
~/.local.kde4/share/webkit
~/.cache.kde4/webkit 
~/.cache.kde4/webkitgtk

renaming this folders did not help either :-(

Comment 31 Alexander Kurtakov 2018-04-17 10:37:30 EDT

Not a crash but the file selection dialog shows on Fedora also when right click on about.html and Open with/Web browser.

Comment 32 Alexander Kurtakov 2018-04-17 12:34:12 EDT

The download dialog seems to be webkit default behavior for some reason (verified with Epiphany). See https://bugzilla.redhat.com/show_bug.cgi?id=1568493 for details, let's see what will webkit guys tell us.

Comment 33 Leo Ufimtsev 2018-04-18 14:32:23 EDT

@ Andrey Loskutov,

I wrote a patch that should prevent the situation where FindBrowser(..) get's the wrong handle and should stop the crash.

Could you please try your eclipse with this patch:
https://git.eclipse.org/r/#/c/121373/

Please let me know if this stops the crash and if so let me know if there are any further issues that you experience.

Comment 34 Andrey Loskutov 2018-04-19 04:10:11 EDT

Created attachment 273681 [details]
Crazy behavior of webkit while opening "bad" html file

(In reply to Leo Ufimtsev from comment #33)
> @ Andrey Loskutov,
> 
> I wrote a patch that should prevent the situation where FindBrowser(..)
> get's the wrong handle and should stop the crash.
> 
> Could you please try your eclipse with this patch:
> https://git.eclipse.org/r/#/c/121373/
> 
> Please let me know if this stops the crash and if so let me know if there
> are any further issues that you experience.

Yep, the crash is gone now! Thanks!

Offtopic (probably another bug).

Fun is, now this webkit opens some random number of download dialogs (!?!) (I don't see any reason to show even one), and independently of clicking on OK or Cancel it seem to want to download things again and again. After ~15-20 times of "downloading" it seem to be happy, but one really has hard time to click away all the popups it shows. Afterwards, the browser window still shows NOTHING.
I've attached a video of my fight with webkit :-)

I know, the rendering thing is not SWT problem, but I wonder why webkit devs mean (https://bugzilla.redhat.com/show_bug.cgi?id=1568493#c3) that this is something what a user would expect? If I open a *local* file in browser, what is the reason to *download* it *many times*???

Also I don't see why a "good" html file does NOT open any download dialogs, but a "bad" one opens. This seem to be just a stupid bug somewhere in webkit.

Or is this depending on the way *how* SWT tells webkit to open an URL? Should we open a separated ticket for this in SWT?

After all, I expect that we are able to show our own about.html files :-)

Comment 35 Alexander Kurtakov 2018-04-19 06:32:08 EDT

I don't think it is related to SWT usage of webkit as exactly the same behavior I observe with epiphany.

Comment 36 Eclipse Genie 2018-04-19 10:30:32 EDT

New Gerrit change created: https://git.eclipse.org/r/121420

Comment 37 Leo Ufimtsev 2018-04-19 10:43:18 EDT

@ Andrey, 

Can you try this guy?
https://git.eclipse.org/r/#/c/121420/

Also, it should print something into the console:
System.out.println("SWT INFO: mime type: " + getString(mime_type) + "  canShow?:"+ canShow);

Can you let me know what you get?

Comment 38 Leo Ufimtsev 2018-04-19 11:11:46 EDT

@ Andrey, in your terminal, can you type:

file ~/aboutBroken.html 

& let me know what is your output?
Mine is: about.html: HTML document, ASCII text

Btw, on my system I don't get the 20 download popups, not even with epihany. meh.

#########################
Notes to self:

RHEL file open report:
https://bugzilla.redhat.com/show_bug.cgi?id=1568493

jUnit where I tested DOCTYPE:
https://git.eclipse.org/r/#/c/100648/3/tests/org.eclipse.swt.tests/JUnit+Tests/org/eclipse/swt/tests/junit/Test_org_eclipse_swt_browser_Browser.java

Related vimb issue that also has a download popup:
https://github.com/fanglingsu/vimb/issues/264
(webkit_web_view_load_uri  was blamed for xhtml files, issue in webkit1. Doesn't mention webkit2).

Webkit2 policy decision:
https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html
WEBKIT_POLICY_DECISION_TYPE_RESPONSE (see webkit_policy_decision_download() )

Getting mime type:
https://webkitgtk.org/reference/webkit2gtk/stable/WebKitURIResponse.html#webkit-uri-response-get-mime-type

Spot where we determine if we should download or render:
https://git.eclipse.org/r/#/c/121420/

Adding meme types:
(gnome) https://developer.gnome.org/integration-guide/stable/mime.html.en
Mimes loctaed in:  /usr/share/mime . In particular ../mime/text/plain
(kde) https://docs.kde.org/trunk5/en/kde-workspace/kcontrol5/filetypes/index.html

List of mime types that webkit likes:
https://github.com/WebKit/webkit/blob/master/Websites/webkit.org/demos/calendar/mime.types

Broken:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
..

Ok:
<!DOCTYPE html>
..

Comment 39 Leo Ufimtsev 2018-04-19 13:57:39 EDT

Fixed. Will remove remaining instance checks in:

533833 – [Webkit2] Should not use G_TYPE_CHECK_INSTANCE_TYPE(..)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=533833

Comment 40 Leo Ufimtsev 2018-04-19 13:58:16 EDT

(In reply to Leo Ufimtsev from comment #39)
> Fixed. Will remove remaining instance checks in:
> 
> 533833 – [Webkit2] Should not use G_TYPE_CHECK_INSTANCE_TYPE(..)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=533833

Closed wrong bug. Was suppose to close this:  525946

Comment 41 Andrey Loskutov 2018-04-20 03:34:16 EDT

(In reply to Leo Ufimtsev from comment #38)
> @ Andrey, in your terminal, can you type:
> 
> file ~/aboutBroken.html 
> 
> & let me know what is your output?
> Mine is: about.html: HTML document, ASCII text

Same as yours for both files.

(In reply to Leo Ufimtsev from comment #37)
> @ Andrey, 
> 
> Can you try this guy?
> https://git.eclipse.org/r/#/c/121420/
> 
> Also, it should print something into the console:
> System.out.println("SWT INFO: mime type: " + getString(mime_type) + " 
> canShow?:"+ canShow);
> 
> Can you let me know what you get?

aboutGOOD.html:
SWT INFO: mime type: text/html  canShow?:true

aboutBAD.html
SWT INFO: mime type: application/x-extension-html  canShow?:false

System does not crash and I get no "File download" dialogs anymore.

Testing on master now: interesting observation: the number of "Download file" dialogs directly depends on the "open file" count. First time open html file: 2 dialogs. Second: three. Next: four, etc. The number of dialogs increases by one also if I open a different html file and then open the bad one.

This sounds like a listener/callback handler for some webkit events leaks in SWT, so that every time on opening a new file all old listeners still receive some events.

Comment 42 Leo Ufimtsev 2018-04-20 10:56:23 EDT

(In reply to Andrey Loskutov from comment #41)
> aboutGOOD.html:
> SWT INFO: mime type: text/html  canShow?:true
> 
> aboutBAD.html
> SWT INFO: mime type: application/x-extension-html  canShow?:false

Could you attach these two html files to the bug?
I just want to make sure there isn't a glitch with copy & paste from bugzilla's comment field (unicode stuff can get muddled up).

Comment 43 Andrey Loskutov 2018-04-20 11:08:37 EDT

Created attachment 273709 [details]
BAD file

Comment 44 Andrey Loskutov 2018-04-20 11:09:10 EDT

Created attachment 273710 [details]
GOOD file

Comment 45 Leo Ufimtsev 2018-04-23 11:38:58 EDT

(In reply to Andrey Loskutov from comment #43)
> Created attachment 273709 [details]
> BAD file

(In reply to Andrey Loskutov from comment #44)
> Created attachment 273710 [details]
> GOOD file

Danke. I'll investigate.

Comment 46 Leo Ufimtsev 2018-04-24 11:54:38 EDT

(In reply to Andrey Loskutov from comment #43)
> Created attachment 273709 [details]
> BAD file

@ Andrey:
If you download this file (as attached to this bug), what is your output for:

xdg-mime query filetype ~/Download/aboutBAD.html 

And also for:
xdg-mime query filetype ~/Download/aboutGOOD.html 

(mine being text/html for both)


Note to self:
Reference on how to use xdg-mime 
https://unix.stackexchange.com/questions/154552/how-an-application-is-chosen-over-others-to-open-a-particular-filetype-in-linux
(found via "RHEL how are mime determined")

Comment 47 Andrey Loskutov 2018-04-26 10:13:58 EDT

(In reply to Leo Ufimtsev from comment #46)
> (In reply to Andrey Loskutov from comment #43)
> > Created attachment 273709 [details]
> > BAD file
> 
> @ Andrey:
> If you download this file (as attached to this bug), what is your output for:
> 
> xdg-mime query filetype ~/Download/aboutBAD.html 
> 
> And also for:
> xdg-mime query filetype ~/Download/aboutGOOD.html 
> 
> (mine being text/html for both)

xdg-mime query filetype ~/Downloads/aboutBAD.html
application/xhtml+xml

xdg-mime query filetype ~/Downloads/aboutGOOD.html
text/html

Comment 48 Leo Ufimtsev 2018-04-26 15:35:02 EDT

(In reply to Andrey Loskutov from comment #47)
> (In reply to Leo Ufimtsev from comment #46)
> > (In reply to Andrey Loskutov from comment #43)
> > > Created attachment 273709 [details]
> > > BAD file
> > 
> > @ Andrey:
> > If you download this file (as attached to this bug), what is your output for:
> > 
> > xdg-mime query filetype ~/Download/aboutBAD.html 
> > 
> > And also for:
> > xdg-mime query filetype ~/Download/aboutGOOD.html 
> > 
> > (mine being text/html for both)
> 
> xdg-mime query filetype ~/Downloads/aboutBAD.html
> application/xhtml+xml
> 
> xdg-mime query filetype ~/Downloads/aboutGOOD.html
> text/html

Ok, this bug is getting a bit long.
afaik, the crash is now fixed (let me know if not).

We can investigate the problem with the MIME type assosiation in a separate bug:
534113 – [Webkit] (On one client) Webkit opens an html file for download due to incorrect mime configuration on system.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534113

Closing this for now.

Comment 49 Leo Ufimtsev 2018-05-08 11:26:00 EDT

I cannot verify directly as that specific crash never occurred for me.

But I can verify that with May 8th build there is no crash when you open an html file.

Comment 50 Andrey Loskutov 2018-05-08 11:32:51 EDT

(In reply to Leo Ufimtsev from comment #49)
> I cannot verify directly as that specific crash never occurred for me.
> 
> But I can verify that with May 8th build there is no crash when you open an
> html file.

I can verify in I20180507-2205 that the crash is gone (and replaced with multiple dialogs shown, see bug 534113).

Comment 51 Leo Ufimtsev 2018-05-08 11:39:47 EDT

(In reply to Andrey Loskutov from comment #50)
> (In reply to Leo Ufimtsev from comment #49)
> > I cannot verify directly as that specific crash never occurred for me.
> > 
> > But I can verify that with May 8th build there is no crash when you open an
> > html file.
> 
> I can verify in I20180507-2205 that the crash is gone (and replaced with
> multiple dialogs shown, see bug 534113).

Thanks Andrey,