Community
Participate
Working Groups
The WebKitGTK authentication mechanism changed as of their 2.0 release, their default authentication prompter can no longer be vetoed by cancelling the "authenticate" signal.
(In reply to Grant Gayed from comment #0) > The WebKitGTK authentication mechanism changed as of their 2.0 release, > their default authentication prompter can no longer be vetoed by cancelling > the "authenticate" signal. Is there a workaround? As an aside, I'd think it would be better if the browser widget had the ability to pass credentials when it's created instead of waiting for a 401 to be returned then invoking the listener.
There was not a workaround at the time, and I don't think the behaviour in that native WebKitGTK stream would have changed in the meantime (for that matter it looks like that stream is now officially gone). I don't work on this anymore, but off the top of my head the only workaround that may work today could be to make the Browser use the WebKitGTK 2.x API instead (it currently uses the 1.x API by default; the API version name does not necessarily correlate with the WebKitGTK+ version name). This newer API may have different behaviour from the 1.x API. To try this I think you need to: 1. Use the GTK+ 3 API (this is the default behaviour as of the Luna release, assuming GTK+ 3 is found on your machine) 2. Use the WebKitGTK 2.x API (set Java property SWT_WEBKIT2 to 1 with something like command-line arg -DSWT_WEBKIT2=1)
Thanks for the feedback Grant. I found that one of the SWT Snippets actually demonstrates the bug: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet317.java It also happens on my Ubuntu 14.04 machine with GTK 3 and WEBKIT2 (libwebkit2gtk-3.0-25) specifying -DSWT_WEBKIT2=1 or not, either. Using an external browser is an option, will continue to investigate options to make the internal browser work.
We use Webkit2 now. *** This bug has been marked as a duplicate of bug 516838 ***
