I have NPAPI plugin and I want to detect its version before I embed it into web page. If version is not the latest one I want to show some message that asks users to update the plugin.
Now it's implemented in the following way
if (navigator.mimeTypes && navigator.mimeTypes["application/myplugin"]) {
{
// some code here
if(navigator.plugins["myplugin"] && navigator.plugins["myplugin"].version >= latest_version) {
// we have the latest version (embed the plugin into web page)
document.write ("<object id='plugin'><embed ....></object>");
} else {
document.write ("Show message here");
}
// some code
}
The problem is that navigator.plugins["myplugin"].version works fine in Firefox but not in Chrome. Chrome doesn't expose version property. I can add my own property in NPAPI code, but I don't see the way I can use it before embedding the plugin into page.
Is there any workaround?
Thanks in advance, Andrew
I see a lot of plugins have version information in either the name or the description. You should be able to access that information before the embed.
I actually put the version number in the filename, rather than even the name or description. The reason for this is that if there are multiple plugins with the same name, description, and mimetypes Firefox will generally use the latest version. Older versions of firefox have been inconsistent in how they handle this, so I even usually put the np???_version.dll file in a version-specific subdirectory.
It is a little bit of a pain, but it works consistently the same way in every NPAPI browser.
You can create a JSAPI property of your plugin containing the version. This property returns the plugin's version when called from javascript. So when you try to insert/embed the plugin in the page, you can check through javascript to make the appropriate calls.
Related
I'd like to hide the version of jQuery library used in my project so nobody can see which version is in use (at least just by quick looking at the code).
While removing a JS comment containing jQuery version is fairly easy, there is a variable hardcoded into jQuery which reveals the version:
var ah = "1.11.3"
My wish is to empty the variable, however I'm not a frontened developer so I don't know what could potential consequencies.
Does jQuery uses this variable is some particular way?
So two points:
Yes removing that could have issues, 3rd party plugins will use: jQuery().jquery to get the version to see if the version used is a recent enough version for the plugin to work, if you remove that the plugin could not load or try and work and have massive issues if the version of jquery isn't 'good' enough.
Removing the version won't help in people not being able to identify if they really want to, it just adds a 2 minute step to the process of just comparing the rest of the code to jquery versions.
I would strongly advise not to remove the version number or change it.
I agree with others point but to answer your question . You can remove the version. you can just empty the version string.
var version = " "
If you give this in your source code even if you try to get the version using $.fn.jquery it gives the empty string.
To give more insight:
download the jquery from jquery.com
save it in the same folder where you create your file.
Include the script in your file in the script src tag.
go to the downloaded file and empty the version variable( var version = " ")
Now in your file even if you try to get the version number ,you cant.
Note : Try to not use the vulnerable version.
Company recently upgraded to Flash v11.8.800.168 and a flash movie which is loaded using SWFObject (1.1) is not working correctly in Internet Explorer (Firefox works fine). The movie is loaded dynamically using a jquery document.ready method using the "new SWFObject(...); so.write("ID")" method (again SWFObject 1.1).\
The movie on load calls a JavaScript function (which is built dynamically using server scripting). The function is being called correctly as checked by a debugger. The JavaScript function calls a method in the flash movie passing it some XML (which is used to render some user and navigation items).
Something like this:
function calledFromFlash() {
document.getElementById("FlashMovie").renderUsingXml('<?xml version 1.0"?><lotsofxml></lotsofxml>');
}
Like I said, this all works still in Firefox with the new Flash version.
When I step through the function above, using step into with the IE Debugger, I get the following steps:
function anonymous() {
return eval(this.CallFunction("<invoke name=\"renderUsingXml\" returntype=\"javascript\">" + __flash__argumentsToXML(arguments, 0) + "</invoke>"));
}
At this point, I checked the arguments variable and it contains the XML as one would expect. After the next step into, I get this:
try { __flash__toXML(calledFromFlash(undefined)); } catch (e) { "<undefined/>"; }
At this point the debugger is already on the catch, yet one more step into take the code into the "<undefined/>" section and I can see that e is Object Expected
What I've tried:
Static implementation without SWFObject. This works. But then Firefox doesn't process the XML properly (and it seems to be the same issue as IE)
Upgrading to SWFObject 2.2. Using dynamic implementation it fails still. Using static implementation it works in IE but not Firefox
This is NOT my flash movie, the source is... well, I don't know. The guy that wrote it has left the company. That said, this seems like such a crazy issue.
My proposed fix is simply to use SWFObject for Firefox and use a static implementation for IE, but I really want to know what is wrong.
This was caused by a bug in Flash Player 11.8.800.168. It has been fixed in 11.8.800.175.
Bug fixes:
3630443 - [External][Windows][IE] ExternalInterface.call() method with non-ASCII text as a parameter corrupts the characters on the Javascript side
Both firebug and the built in console in webkit browsers make it possible to set breakpoints in running Javascript code, so you can debug it as you would with any other language.
What I'm wondering is if there is any way that I can instruct firebug or webkit that I'd like to set a breakpoint on line X in file Y at runtime, and to be able to examine variables in the specific scope that I have paused in.
I need something that can work in both Chrome (or any other webkit browser) and Firefox. For the latter Firebug is an acceptable dependency. Supporting IE is not a requirement.
I've been building an in-browser IDE ( quick video for the interested: http://www.youtube.com/watch?v=c5lGwqi8L_g ) and want to give it a bit more meat.
One thing I did try was just adding debugger; as an extra line where users set them, but this isn't really an ideal solution.
I'd say you can definitely do this for webkit browsers using the remote debugging protocol. This is based on a websocket connection and a json message protocol that goes back and forth.
You can read the announcement and the whole protocol schema.
Chrome also offers more information about this inside its remote developer-tools docs.
For the debugger domain, for instance, you can see how you can use Debugger.setBreakpoint, Debugger.setBreakpointByUrl and Debugger.setBreakpointsActive to work with breakpoints.
On the other hand, Mozilla also seems to be working on this as you can see in https://developer.mozilla.org/en-US/docs/Tools/Debugger-API and https://wiki.mozilla.org/Remote_Debugging_Protocol though I don't know the completion status of it.
In this case, you can work with breakpoints using the Debugger.Script APIs setBreakPoint, getBreakPoint, getBreakpoints, clearBreakpoints and clearAllBreakpoints
I hope this helps you move forward.
There isn't such a thing, at least not using the public, scriptable side of JavaScript. It would be possible if you have a privileged browser extension that could do that for you. For example, Firebug has a debug method which you can call from its command line, but not from scripts inside a page.
So, you have two solutions:
Implement your own JavaScript interpreter, which you can control as you wish. Might be a bit too ambitious, though...
Rely on a browser extension that can set breakpoints anywhere in the code, expose some API to public code, and interact with it from your JavaScript. But that means that users will have to install some extra piece of software before they can use your "Web IDE".
Use _defineSetter__ to watch variables, and combine it with a call to debugger when an assignment happens.
__defineSetter__("name", function() { debugger; });
or defineProperty:
function setter () { debugger; }
Object.defineProperty(Math, 'name', { set: setter });
References
MDN: Object.defineProperty
A List Apart: Advanced Debugging With JavaScript
JavaScript Getters and Setters
Well yeah, it sounds funny, but all I want is to read the value of Capabilities.version to get the right version of the Flash player? I have tried getting the version info from swfObject library, but it doesn't give the complete version info:
http://www.adobe.com/devnet/flashplayer/articles/swfobject.html
FP version info have 4 numbers: major, minor, release and build. I couldn't find an API which can give me all four on all browsers without loading SWF. Hence I am looking for help here.
SWFObject has a detection function built into it and for the most part it is cross-browser capable.
The function name is getFlashPlayerVersion
It returns an object with 3 attributes major, minor,release
[EDIT]
SWFObject also has a function called testPlayerVersion.
I shortened it up for you but I think it gets what you want.
var o = createElement(OBJECT);
o.setAttribute("type", FLASH_MIME_TYPE);
alert( doc.getElementsByTagName("body")[0].appendChild(o).GetVariable("$version") )
doc.getElementsByTagName("body")[0].removeChild(o);
Remember this is not browser compliant.
Pretty sure you need to test for plugin or active x also.
You do not need to load flash to know what is the version of the player.
There for is JS.
http://www.featureblend.com/javascript-flash-detection-library.html
I have just been altered to the fact that a user of my website is using a very old browser which does not run jquery (in this case Safari 1.x) and as a result can not access the login panel which uses jquery's slideToggle function.
Can anyone think of a fix which detects whether a browser is able to use jquery - and if not make that link go to a different page rather than showing the login panel?
You could a little conditional check like
if(!'jQuery' in window) {
// jQuery is not available
}
or, if Safari 1.x doesn't know about the IN operator (I'm not sure) use
if(!window.jQuery) {
}
I think there are alternative answers to this, but for me, I would have to weigh up the time it will take you to support his obsolete browser (I'm sure there may be other things inside the site), versus the payback to you...
In the plain HTML source code for the the href= of the login link, set that to a plain HTML login page.
Using jQuery, attach the click handler to the link, if this part fails, thats ok, the browser will just follow the href in the link to the plain login page, allowing your old-browser-user to login still.
$(document).ready(function(){
$('#login_link_id').click(function(){
// Your code here
});
});
If you use javascript/jQuery you should ALWAYS ensure your site works perfectly without it. In this case if you have a login popup box; you probably assign a click event assigned after the DOM has loaded.
What you should do is ensure that if jQuery isn't present the link loads a "normal" login webpage as opposed to the popupbox. I use something similar to this:
Log in
<script>
if(!'jQuery' in window) {
$(document).ready(function(){
//assign on click event to loginlink
});
}
</script>
If jQuery doesn't exist then login.html will be opened normally.
Wow, seriously?! Safari 1.x?? Anyhow, try this...
var isJQSupported = false;
$(function() { //shorthand for document.ready
isJQSupported = true;
//your usual code
});
if (!isJQSupported) {
window.location = "http://www.apple.com/safari/download/";
}
To me it sounds like safari 1.X has problems with jQuery internally. Which means simple checks like whether $ exists in the global space or whether $(function) does anything are not going to help.
The most likely root cause will be that javascript throws an error in loading of jQuery itself which will then stop the rest of your javascript code from execution.
There are four viable options here.
Either make the website work with noscript. Replace your login control with pure HTML and postbacks and ask the user to turn javascript off. This option is useful since you won't be fixing the issue for safari 1.x problems specifically.
You can make javascript check for safari 1.X and other non-supported browsers and only load jQuery through script tag injection or ajax if your user is using a supported browser. If the user is using a browser not compatible with jQuery then you can instead use plain javascript.
Get a copy of safari 1.x and see why jQuery breaks. Then fix it and ask for it to pulled into the release of jQuery 1.5. This relies on the fix being something that does can be done without hacking and that the jQuery team agrees is worth adding in.
Ask the user to use a compliant browser.
There might be some more options. I would personally lean towards asking the user to use a compliant browser because supporting Safari 1.x is ridiculous.
This seems like a case where progressive enhancement is needed.
You have to do multiple checks
see if $ exists
see if $.fn exists
[not sure if needed] check if $.support is a function
check for feature support as needed with $.support() http://api.jquery.com/jQuery.support/
At the end of the check, when jQuery reports that features you need are present - the rest of the script can run.
If you're not sure which features mentioned in the support you use, then this might need a single test on Safari 1.x to see what are the values returned by $.support(), but that is what your nasty old-browser-user can do for you (if you prepare code and publish) and report the resulting text. Then you compare the list with other [old] browsers that are accessible and determine features that are required.
The easy way would be to require everything and cancel all scripts if suport for any feature is missing. This will also rule out IE6 and IE7 and opera below 9.something and firefox below 2.0 or including - I'm not sure.
Use a server side language to detect if it's the old safari based on user-agent and load a different javascript file