"Wrong Architecture" when loading plugins on Mac

[jfelchner]

Just got this error and I have no idea where to go with this.

I'm currently on Snow Leopard

webkit_server[86769:903] Error loading /Library/Internet Plug-Ins/SharePointBrowserPlugin.plugin/Contents/MacOS/SharePointBrowserPlugin:  dlopen(/Library/Internet Plug-Ins/SharePointBrowserPlugin.plugin/Contents/MacOS/SharePointBrowserPlugin, 262): no suitable image found.  Did find:
    /Library/Internet Plug-Ins/SharePointBrowserPlugin.plugin/Contents/MacOS/SharePointBrowserPlugin: mach-o, but wrong architecture
webkit_server[86769:903] Error loading /Library/Internet Plug-Ins/QuickTime Plugin.plugin/Contents/MacOS/QuickTime Plugin:  dlopen(/Library/Internet Plug-Ins/QuickTime Plugin.plugin/Contents/MacOS/QuickTime Plugin, 265): no suitable image found.  Did find:
    /Library/Internet Plug-Ins/QuickTime Plugin.plugin/Contents/MacOS/QuickTime Plugin: no matching architecture in universal wrapper
webkit_server[86769:903] Error loading /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player:  dlopen(/Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player, 262): no suitable image found.  Did find:
    /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player: no matching architecture in universal wrapper

I did find this: http://developer.qt.nokia.com/forums/viewthread/4972 posted on the QT web forum. So I guess this is not a capybara-webkit issue?

Any pointers would be appreciated.

[emilford]

Have you found a solution to this? I am experiencing a similar error on Lion.

[willmanduffy]

I'm also having this issue on Lion. I tried rolling back to QT 4.7.3 to see what happened and the result is the same.

[jferris]

Can somebody attach a debug log to this issue? https://github.com/thoughtbot/capybara-webkit/wiki/Reporting-Crashes

I haven't seen this and I have no idea what SharePointBrowserPlugin is.

[jfelchner]

@jferris sorry for the delay, here's the log that I get: https://gist.github.com/1259762

Note that this does not cause the test to fail. It simply outputs the above message to STDERR. Again, a note about this error was posted here: http://developer.qt.nokia.com/forums/viewthread/4972 It's possible there may be nothing that capybara-webkit can do.

I've tried with both QT 4.7.4 and 4.7.3 (compiled using Homebrew from source).

Thanks for looking into this.

[jfelchner]

Updated the issue title since it doesn't just apply to the SharePointBrowserPlugin plugin

[keo]

I have the same issue with OS X 10.7.2 and qt 4.7.4

[uokesita]

Same issue https://gist.github.com/1309624

[nuc]

A not-so-real solution for a not-so-real problem: #211

This is not a real problem for capybara-webkit. QT will fail to load all those plugins of different architecture, and this is not affecting by any means capybara.

I tried to disable plugins via QWebSettings::PluginsEnabled, but it didn't worked.

So, in order to keep rspec's output as clean as possible, I just hide all error messages while loading webkit-server.

I guess this is not a really good approach, because that way any other loading errors that it might appear, would be hidden as well.

But it will bring us some temporary sanity at least :)

[djanowski]

I'm having the same issue. As other state, it doesn't affect the tests, just the output.

However, I wonder if actually disabling these plugins (maybe we can tell Webkit to start in 'safe mode' or something?) would speed up boot time or even execution time.

[yelvert]

Any updates on this? I am still having this issue and it is extremely annoying.

[jferris]

@yelvert As far as I know, nobody has found a way to disable the plugins yet. If anybody finds something out, I'm sure they'll update this thread.

[sandro]

Is this relevant? ariya/phantomjs@8c7b586

[marcinczenko]

Did anyone find any solution ?

[garyharan]

Alright so I've dug a little deeper and I found a fix for my issue. It might break other people's system if they don't know what they're doing but in my case it works great.

As with any problem like this one there are a lot of actors and it's hard to figure out who needs to do the appropriate fix. I think they all stem from one fact. There are plugins residing in your system that are too old for the system you currently use. This can happen if you upgrade your OS and system without doing a cleanup of some key folders.

To do this cleanup you need to go in two folders:

/Library/Internet Plug-Ins/  <- For all users of webkit_servers like Chrome or webkit_server
~/Library/Internet Plug-Ins/  <- For your user only.

The plugins listed there may not be listed in chrome://plugins but in my case some were.

Applying this fix might break your browsing experience or make you need to reinstall newer plugins

I decided to move all the plugins that were causing issues to the trash (well with a temp folder in between to make sure I could revert if something went wrong).

After deleting the culprits I restarted Chrome and it did not affect it (I did see that the list of available plugins was matching my changes in chrome://plugins/ so that's a good sign.

And I ran my tests again and had no more issues with wrong plugins appearing anywhere.

[jferris]

@garyharan Thanks for looking into this; that's really useful. Do you mind writing this up on a new page on the Wiki?

Since this warning appears to be somewhat legitimate and we now have what seems like an appropriate user fix, I'm closing this issue.

[marcinczenko]

Thanks a lot for looking into that and reporting here. I will check it out when I have a moment and write back.

On Oct 25, 2012, at 5:28 PM, Gary Haran [email protected] wrote:

Alright so I've dug a little deeper and I found a fix for my issue. It might break other people's system if they don't know what they're doing but in my case it works great.

As with any problem like this one there are a lot of actors and it's hard to figure out who needs to do the appropriate fix. I think they all stem from one fact. There are plugins residing in your system that are too old for the system you currently use. This can happen if you upgrade your OS and system without doing a cleanup of some key folders.

To do this cleanup you need to go in two folders:

/Library/Internet Plug-Ins/ <- For all users of webkit_servers like Chrome or webkit_server
~/Library/Internet Plug-Ins/ <- For your user only.
The plugins listed there may not be listed in chrome://plugins but in my case some were.

Applying this fix might break your browsing experience or make you need to reinstall newer plugins

I decided to move all the plugins that were causing issues to the trash (well with a temp folder in between to make sure I could revert if something went wrong).

After deleting the culprits I restarted Chrome and it did not affect it (I did see that the list of available plugins was matching my changes in chrome://plugins/ so that's a good sign.

And I ran my tests again and had no more issues with wrong plugins appearing anywhere.

—
Reply to this email directly or view it on GitHub.

[brianp]

edit:

comment removed. Managed to resolve most of the remaining issues via methods already discussed.

[b-murphy]

@garyharan +1

[laysreyleap]

@garyharan I try to remove the plugin, and it works too.

Thanks,

[tamoyal]

Suggested solution also worked for me and Gmail loads so that's enough for me to say my browsing experience is not broken. I guess it's worth noting that this warning only popped up after a second invocation of my code that uses Capybara with webkit.

[ghost]

The suggested fix does remove the error from the test output, however, it also removes the plugins from your browser.

On Mavericks I get the plugin architecture error for QuickTime (using the brew install qt --head method of installing Qt).

When I move the QuickTime Plugin.plugin out of the /Library/Internet Plugin-Ins folder there is no error message in my test output, however, QuickTime videos no longer play in Chrome.

A warning to others: be sure to just move the QuickTime Plugin.plugin file, don't delete it... Apple doesn't seem to allow you to easily download the QuickTime plugin for OSX. As far as I know, you have to copy it off another Mac, find it somewhere in the Mavericks install download, or reinstall OSX to get it back.

[jdguzman]

I just ran across this issue and though I would post here for anyone else. I used the following to suppress the messages:

# Custom output class to silence Qt warnings
# NOTE: This may cause issuse in the future so look here first if js
# tests fail
class QuiteWebkit
  IGNOREABLE = /CoreText performance|userSpaceScaleFactor|Internet Plug-Ins|is implemented in bo/

  def write(message)
    if message =~ IGNOREABLE
      0
    else
      puts(message)
      1
    end
  end
end

# Registering webkit driver using custom output class above for stderr
Capybara.register_driver :quiet_webkit do |app|
  Capybara::Webkit::Driver.new(app, stderr: QuiteWebkit.new)
end

Capybara.javascript_driver = :quiet_webkit

I can't remember where I got this from but I was previously using it to suppress some qt4 related messages. May not be the best solution but at least it's one where you can manage what gets ignored.

[Sporky023]

If you are using @jdguzman's strategy to simply suppress the warnings (IMO a better path than removing browser plugins because it's less system-intrustive), and are also using the Capybara::Webkit.configure syntax introduced in capybara-webkit 1.6.0, then make the following modification to maintain that configuration when registering the new driver:

Capybara::Webkit.configure do |config|
  config.block_unknown_urls  # <--- this configuration would be lost if you didn't use .merge below
end

class WebkitStderrWithQtPluginMessagesSuppressed
  IGNOREABLE = Regexp.new( [
    'CoreText performance',
    'userSpaceScaleFactor',
    'Internet Plug-Ins',
    'is implemented in bo'
  ].join('|') )

  def write(message)
    if message =~ IGNOREABLE
      0
    else
      puts(message)
      1
    end
  end
end

Capybara.register_driver :webkit_with_qt_plugin_messages_suppressed do |app|
  Capybara::Webkit::Driver.new(
    app,
    Capybara::Webkit::Configuration.to_hash.merge(  # <------ maintain configuration set in Capybara::Webkit.configure block
      stderr: WebkitStderrWithQtPluginMessagesSuppressed.new
    )
  )
end

Capybara.javascript_driver = :webkit_with_qt_plugin_messages_suppressed

[Sporky023]

And then of course to keep your spec_helper short and grokkable, you can move the class from spec_helper.rb to lib/webkit_stderr_with_qt_plugin_messages_suppressed.rb and just add

require 'webkit_stderr_with_qt_plugin_messages_suppressed'

at the top of spec_helper.rb.