BrowserFunction does not work with Content Security Policies

[Lukas-Habring]

Describe the bug A content security policy can restrict the use of BrowserFunctions.

To Reproduce 1) Add a BrowserFunction. 2) Access a webpage with a restrictive content security policy header. 3) Listen for the page-loaded-event in your java-code. 4) After the page is loaded, inject some Javascript via org.eclipse.swt.browser.Browser.evaluate() and call your BrowserFunction. You get an exception, but if you catch it you can see in the debugger inside the browser that the request was blocked by the CSP.

Expected behavior Always allow BrowserFunctions to be called ignoring the CSP that is currently active.

Environment:

1. Select the platform(s) on which the behavior is seen:

   • • [ ] All OS
   • • [ ] Windows
   • • [ X ] Linux
   • • [ ] macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc) Fedora 36, gtk

3. JRE/JDK version 1.18

Version since 4.24

[mickaelistria]

Access a webpage with a restrictive content security policy header.

Do you have a good and simple example of such a page available publicly?

[Lukas-Habring]

No, unfortunately I have not. But I invested some time to create a simple test-case for you. The test-case places the CSP into the html-head, but as I said, the issue is the same when the CSP is retrieved in the http-headers. SWTBrowserBug.zip

[Lukas-Habring]

The bug may also appear on other operating systems. Unfortunately, I don't have a Windows-PC or Mac. Can someone test that?

[Phillipus]

Tested on Mac:

Bug is fixed!
java.lang.NullPointerException
    at org.eclipse.swt.browser.WebKit.execute(WebKit.java:479)
    at org.eclipse.swt.browser.WebBrowser.nonBlockingExecute(WebBrowser.java:400)
    at org.eclipse.swt.browser.WebBrowser.evaluate(WebBrowser.java:451)
    at org.eclipse.swt.browser.WebBrowser.evaluate(WebBrowser.java:406)
    at org.eclipse.swt.browser.Browser.evaluate(Browser.java:666)
    at org.eclipse.swt.browser.Browser.evaluate(Browser.java:615)
    at util.bugs.SWTBrowserBug.pageLoaded(SWTBrowserBug.java:52)
    at util.bugs.SWTBrowserBug$2.completed(SWTBrowserBug.java:28)
    at org.eclipse.swt.browser.WebKit.webView_didFinishLoadForFrame(WebKit.java:816)
    at org.eclipse.swt.browser.WebKit.browserProc(WebKit.java:322)
    at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
    at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(Display.java:5501)
    at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5901)
    at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
    at org.eclipse.swt.internal.cocoa.NSApplication.nextEventMatchingMask(NSApplication.java:92)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3935)
    at util.bugs.SWTBrowserBug.run(SWTBrowserBug.java:32)
    at util.bugs.SWTBrowserBug.main(SWTBrowserBug.java:16)

Tested on Windows:

Bug is fixed!
java.lang.NullPointerException
    at org.eclipse.swt.browser.IE._getUrl(IE.java:1282)
    at org.eclipse.swt.browser.IE.execute(IE.java:1159)
    at org.eclipse.swt.browser.WebBrowser.nonBlockingExecute(WebBrowser.java:400)
    at org.eclipse.swt.browser.WebBrowser.evaluate(WebBrowser.java:451)
    at org.eclipse.swt.browser.WebBrowser.evaluate(WebBrowser.java:406)
    at org.eclipse.swt.browser.Browser.evaluate(Browser.java:666)
    at org.eclipse.swt.browser.Browser.evaluate(Browser.java:615)
    at SWTBrowserBug.pageLoaded(SWTBrowserBug.java:50)
    at SWTBrowserBug$2.completed(SWTBrowserBug.java:26)
    at org.eclipse.swt.browser.IE.lambda$6(IE.java:656)
    at org.eclipse.swt.ole.win32.OleEventTable.sendEvent(OleEventTable.java:58)
    at org.eclipse.swt.ole.win32.OleEventSink.notifyListener(OleEventSink.java:160)
    at org.eclipse.swt.ole.win32.OleEventSink.Invoke(OleEventSink.java:128)
    at org.eclipse.swt.ole.win32.OleEventSink$1.method6(OleEventSink.java:79)
    at org.eclipse.swt.internal.ole.win32.COMObject.callback6(COMObject.java:120)
    at org.eclipse.swt.internal.win32.OS.DispatchMessage(Native Method)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3643)
    at SWTBrowserBug.run(SWTBrowserBug.java:30)
    at SWTBrowserBug.main(SWTBrowserBug.java:14)

Commenting out this line and it runs OK:

window.dispose();

So, ignoring the NPE, I'd say it's a Linux issue.

[Phillipus]

I tidied up the Snippet so it runs on all platforms. Fails as per the OP only on Linux.

SWTBrowserBug.zip

[Lukas-Habring]

@Phillipus Nope, I can confirm that the bug still occurs. Furthermore, I cannot see any difference between your version and mine that is significant regarding this bug. Your version is just a little bit cleaner, but this is not a programming exercise, it's just a quick-and-dirty demonstration of a bug. And for that it is ok to ignore some coding guidelines in my opinion. Regarding the dispose-call in the callback-method: This is another (Windows- and Mac-)bug, right? Because it should be possible to terminate the application from within a BrowserFunction or am I wrong? And even if I'm wrong, this should not end in a NullPointerException, right?

[Phillipus]

@Lukas-Habring You asked:

The bug may also appear on other operating systems. Unfortunately, I don't have a Windows-PC or Mac. Can someone test that?

I did that.

But the snippet throws a NPE on Windows and Mac. So I provided a modified test snippet that doesn't throw a NPE in case anyone else wanted to test it.

In so doing I can confirm your bug occurring on Linux, but not on Windows and Mac (as I said in my previous comment "Fails as per the OP only on Linux.")

Nope, I can confirm that the bug still occurs.

And that's exactly what I confirmed.

[Lukas-Habring]

Ok, that was a misunderstanding then. Thanks for the clarification. Still: There shouldn't be a NullPointerException when you call shell.dispose() from a BrowserFunction, right?

[Phillipus]

There shouldn't be a NullPointerException when you call shell.dispose() from a BrowserFunction, right?

In snippets such as this, it's best just to dispose the Display object when the event loop is finished and follow the basic pattern in other SWT snippets. (That is not a criticism of your snippet.)

However, getting back to the original issue, the important thing for your use case is that I can confirm that the Security Policy issue is only occuring on Linux.