OpenBSD Chromium Crash

[tslight]

uBlock Origin will not run in Chromium on OpenBSD. However it works fine in Firefox.

My xorg log reports the following errors:

extension_function.cc(410)] Bad extension message types.ChromeSetting.set

extension_function_dispatcher.cc(112)] Terminating renderer because of malformed extension message.

uBlock Origin version: 1.0.0.1
Chromium version: 44.0.2403.125
Other extensions: HTTPS Everywhere, LastPass. Disabling did nothing.

[gorhill]

Related to #533?

Any browser crash needs to be reported to Chromium devs, executing javascript is not supposed to crash a browser, and when it does, this is a browser bug.

[tslight]

Sorry, I think I have been unclear - the browser itself is not crashing, just the plugin. It is auto-disabled the moment I launch the browser, and it cannot be re-enabled.

[gorhill]

When I say "browser crash", I also refer to a process associated with any specific tab or extension crashing, it does not have to be the main browser process. Start chromium from the command line shell and see what is the output when you try to enable uBlock.

[tslight]

Ah, OK, I misunderstood. The output from the shell is the same as that originally mentioned in my xorg log. I shall submit a bug to the chromium devs and the OpenBSD porters (as uBlock was working fine on my previous Debian setup). Thanks for pointing me in the right direction, and for all your hard work on this project.

[gorhill]

If you type typeof webkitRTCPeerConnection in the console, what is the result? Maybe I could use this to detect whether I can safely use the chrome.privacy.network WebRTC API.

[tslight]

I get "function". I assume you mean this console: https://developer.chrome.com/devtools/docs/console ? Anything else I can test/do to help?

[gorhill]

I get "function".

So I can't use this. Kind of strange that WebRTC is not build into Chromium and yet the webkitRTCPeerConnection property is defined.

[qbit]

Perhaps a check for window.navigator.platform.match(/OpenBSD/) would suffice in this situation. Feels dirty explicitly listing an OS in that way, but until WebRTC is sorted out, it's probably the only solution.

This diff fixes it for me, but I haven't tested it on any !OpenBSD platforms:

diff --git a/platform/chromium/vapi-background.js b/platform/chromium/vapi-background.js
index 79d929e..59b47e7 100644
--- a/platform/chromium/vapi-background.js
+++ b/platform/chromium/vapi-background.js
@@ -103,7 +103,10 @@ vAPI.browserSettings = {
                 break;

             case 'webrtcIPAddress':
-                if ( typeof chrome.privacy.network.webRTCMultipleRoutesEnabled === 'object' ) {
+                if (
+                       typeof chrome.privacy.network.webRTCMultipleRoutesEnabled === 'object' &&
+                       ! window.navigator.platform.match(/OpenBSD/)
+               ) {
                     try {
                         chrome.privacy.network.webRTCMultipleRoutesEnabled.set({
                             value: !!details[setting],

[tslight]

Works for me on -current's Chromium 45.0.2454.85 👍

[mbaragiola]

Same problem here. OpenBSD 5.8-stable amd64 and Chromium 44.0.2453.125 (64-bit). As OP mentions, works fine both on Firefox and Chromium (on OpenBSD 5.7-stable and Debian/Ubuntu as well).

@tslight : Did you have any replies on the porters? Thanks in advance.

[Eloston]

09d7d1f should close this.

[gorhill]

Closing as duplicate of #533.