Yesterday a customer reported some interesting problems while testing their code with our Intel Web APIs on FireFox 3.6.6.
They were using our code correctly, however when running on FF v 3.6.6, FF kept indicating that plugins were missing, which in turn led our code to believe the plugins were not being instantiated in the page.
After a little digging around we believe we have found an issue with 3.6.x builds of Firefox that is related to a filesystem path limitation that prevents FF from finding our plugins if they are installed in a path longer than 130 characters.
The problem was not observed in other browsers, such as chrome, and after using a hack to work around the issue (see developer hack section below) I was able to get the code running again in FF.
So at this point I believe our APIs and plugins are working as they should and the issue is likely the browser.We will wait a bit to see what the folks at mozilla think - I may have to eat those words :)
I've submitted abug report to mozillawhere you can read the details - and also see commentary as it emerges.I encourage you to participate in the bug process if you have anything to add.
Developer hack section:
Okay, so here is a hack that will help you continuing to develop your code with our apis and test and demo your app in the latest Firefox. This is only for developers and demos where you have control over the client system - not viable for production release.
first, make sure all the web api code you are using
for your demos works in Chrome. This simply ensures that our web api connector
has downloaded the api plugins that your code
open up the windows registry editor and find the key:
HKEY_CURRENT_USER\\Software\\MozillaPlugins. In this key, you will see several
sub-keys that are named @intel-webapi.intel.com/
For each of the @intel-webapi.intel.com sub-keys find
the Path value and, at the very end, shorten the file name of the .dll to just
np1.dll. Next, go to the corresponding directory on the filesystem and change
the actual file's name to np1.dll. This will reduce the full path by 20+ chars and will likely get you back up and running again in FF.NOTE: you can backup the original Path value by
creating another string value named "xPath just in case something goes wrong
This problem does not exist in older versions of Firefox - ex. 3.5.10. So, if dropping back *on your development system* is a viable option, you could just do that. I don't really like this option because I would rather be developing on the latest version of Firefox browser that is being deployed to the public. The other big downside to dropping to an older version is that it may have security issues fixed in newer versions - so think carefully about that and your situation.