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
Related
I'm trying to make a Bookmarklet to grab an id value from the Clipboard, and navigate to a URL that is built with that id.
javascript:(function(){
window.location="index.php?module=Accounts&action=DetailView&record="
+ clipboardData.getData('Text');
})()
(this is only supposed to work when clicked on a specific site that is expecting that URL form)
The basics of the Bookmarklet are working fine, the tricky part is getting the Clipboard value, because clipboardData is not working.
I am using Firefox v64 (although I would like this to be generic across more browsers, at least modern ones).
Now, upon searching about this issue I realize what I'm trying to do is not as simple as it seems - clipboard API's in browsers are a tricky issue. I found several answers about this, the best one seems to be this:
JavaScript get clipboard data on paste event (Cross browser)
I also tried this one but couldn't get it to work either: https://stackoverflow.com/a/27908501/1189711
My question here is: are any of those techniques applicable in a Bookmarklet? If so, I would appreciate some help with this. My skills in Javascript are too low to understand how to translate these answers to my case - namely the asynchronous stuff.
PS - if someone wants a place to test this, just put 84f1bb99-7017-e8dc-94f9-5c179da9f102 in your clipboard and try it on this demo site, credentials will/will.
Clipboard copy cannot works from scripts. It must comes from an user action.
Similary, in the same way, you can't call a fullscreen from a bookmarklet.
From the Firefox console:
document.execCommand(‘cut’/‘copy’) was denied because it was not
called from inside a short running user-generated event handler.
I try this method and it works:
SAME WINDOWS:
javascript:location.href='https://www.ricerca.com?search%27+escape(location.href)
NEW WINDOWS: (by https://9to5answer.com/window-location-href-and-window-open-methods-in-javascript)
window.open()
javascript:window.open("https://www.ricerca.com?search="+window.getSelection());
How do you disable pushstate for Chrome (for testing purposes)?
Bonus if you know of a plugin that makes it easy to toggle :)
I'm using davis.js for my pushstate logic.
history.pushState = function (){};
//An empty function so if it is used, it doesn't throw any errors
Put that in the console. Tada! You can easily make a Chrome extension that executes that on a page using a Content Script.
The reason your Davis.js routes are still working is because when you click a link it runs your routes directly, since there is no onPushState event, you should find though that using the back and forward buttons no longer trigger your routes.
If you want to emulate what happens in a browser that doesn't support pushState you can fool around with how Davis.js checks for support. This is done in the Davis.supported function.
You can override that function to always return false, which is what would happen normally in a browser that doesn't support pushState. If you wanted to you could wrap this up into a Davis.js extension, see the block iOS extension as an example.
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.
Is it possible to disable AJAX without disabling JavaScript completely?
If you are using Firefox, you could accomplish this with GreaseMonkey. (https://addons.mozilla.org/en-US/firefox/addon/748)
GM is a framework for applying scripts to some or all of the pages you visit. I have GM scripts that disable google-analytics downloads (because they slow things down), and which disable google-click-tracking on google result pages (because it bothers me that they are doing that).
Here is my google-click disable script:
// ==UserScript==
// #name Google Clk
// #namespace googleclk
// #description Disable Google click tracking
// #include http://*google.com/*
// ==/UserScript==
// Override google's clk() function, which reports all clicks back to google
unsafeWindow.clk = function(url) {} // { alert(url); } // I use this to test.
By doing something similar with XMLHttpRequest (and other functions) you can effectively disable them. Of course, you may completely break the page by doing this, but you already knew that.
You can replace the browser tool to make AJAX (XMLHttpRequest object) with your own that does nothing.
XMLHttpRequest = function(){}
XMLHttpRequest.prototype = {
open: function(){},
send: function(){}
}
Be sure that your replacement code executes before any AJAX call.
This will work for any browser that implement AJAX through the XMLHttpRequest object but will not work for IE. For IE, you may have to overload the CreateObject() function if possible...
In IE this can be done with: Tools -> Internet Options -> Advanced Tab -> Scroll down to Security -> Uncheck 'Enable Native XMLHTTP Support'.
http://msdn.microsoft.com/en-us/library/ms537505%28v=vs.85%29.aspx
AJAX is simply the usage of the XMLHttpRequest function in Javascript. Depending on your browser, you may be able to lock down access to this function through your security settings.
At least with Firefox, you could disable it either through using a custom Extension.
This is a late comment on a question that has already been answered, but for the benefit of people coming in from Google:
With the Tab Permissions extension for Firefox you can disable JavaScript for a particular tab (as opposed to globally for all tabs) with a right-click context menu. I configured the "Permissions" menu item to toggle "Redirect" and "JavaScript," so if I stumble onto a page that has annoying refreshes and AJAX, I can quickly and easily shut down the bandwidth activity of the misbehaving tab without affecting the JavaScript on my other open tabs.
Additionally to the Firefox suggestion, you can do it in IE as a side-effect of disabling ActiveX. Also on IE7+ you have to disable the ‘Native XMLHttpRequest’ option.
No more than you can disable any other function - there may be some kludges or hacks to be found that could interfere with or break javascript, but we would hope not to find such vulnerabilities.
I'll take a wild stab in the dark and guess that you're trying to stop Ajax in untrusted user input of some kind? Your best bet in that case would be to avoid over-specifying your search parameters by mentioning Ajax, rather, search for 'sanitize javascript', 'user javascript safe'... that kind of thing.
No. AJAX is just a particular use of javascript.
If you could block the particular function call back to the server you might be able to do it, but you would probably have to edit your browser.
I assume you want to do this from the client end... Can you list some more specific goals? What is the expected outcome?
I have an ASP.NET MVC project that uses some simple AJAX functionality through jQuery's $.get method like so:
$.get(myUrl, null, function(result) {
$('#myselector').html(result);
});
The amount of content is relatively low here -- usually a single div with a short blurb of text. Sometimes, however, I am also injecting some javascript into the page. At some point when I dynamically include script into content that was itself dynamically added to the page, the script still runs, but it ceases to be available to the debugger. In VS2008, any breakpoints are ignored, and when I use the "debugger" statement, I get a messagebox saying that "no source code is available at this location." This fails both for the VS2008 debugger and the Firebug debugger in Firefox. I have tried both including the script inline in my dynamic content and also referencing a separate js file from this dynamic content -- both ways seemed to result in script that's unavailable to the debugger.
So, my question is twofold:
Is there any way to help the debugger recognize the existence of this script?
If not, what's the best way to include scripts that are used infrequently and in dynamically generated content in a way that is accessible to the debuggers?
I can not comment yet, but I can maybe help answer. As qwerty said, firefox console can be the way to go. I'd recommend going full bar and getting firebug. It hasn't ever missed code in my 3 years using it.
You could also change the way the injected javascript is added and see if that effects the debugger you're using. (I take it you're using Microsoft's IDE?).
In any case, I find the best way to inject javascript for IE is to put it as an appendChild in the head. In the case that isn't viable, the eval function (I hate using it as much as you do) can be used. Here is my AJAX IE fixer code I use. I use it for safari too since it has similar behavior. If you need that too just change the browser condition check (document.all for IE, Safari is navigator.userAgent.toLowerCase() == 'safari';).
function execajaxscripts(obj){
if(document.all){
var scripts = obj.getElementsByTagName('script');
for(var i=0; i<scripts.length; i++){
eval(scripts[i].innerHTML);
}
}
}
I've never used jquery, I preferred prototype then dojo but... I take it that it would look something like this:
$.get(myUrl, null, function(result) {
$('#myselector').html(result);
execajaxscripts(result);
});
The one problem is, eval debug errors may not be caught since it creates another instance of the interpreter. But it is worth trying.. and otherwise. Use a different debugger :D
This might be a long shot, but I don't have access to IE right now to test.
Try naming the anonymous function, e.g.:
$.get(myUrl, null, function anon_temp1(result) {
$('#myselector').html(result);
});
I'm surprised firebug is not catching the 'debugger' statement. I've never had any problems no matter how complicated the JS including method was
If this is javascript embedded within dynmically generated HTML, I can see where that might be a problem since the debugger would not see it in the initial load. I am surprised that you could put it into a seperate .js file and the debugger still failed to see the function.
It seems you could define a function in a seperate static file, nominally "get_and_show" (or whatever, possibly nested in a namespace of sorts) with a parameter of myUrl, and then call the function from the HTML. Why won't that trip the breakpoint (did you try something like this -- the question is unclear as to whether the reference to the .js in the dynamic HTML was just a func call, or the actual script/load reference as well)? Be sure to first load the external script file from a "hard coded" reference in the HTML file? (view source on roboprogs.com/index.html -- loads .js files, then runs a text insertion func)
We use firebug for debug javascript, profile requests, throw logs, etc.
You can download from http://getfirebug.com/
If firebug don't show your javascript source, post some url to test your example case.
I hope I've been of any help!
If you add // # sourceURL=foo.js to the end of the script that you're injecting then it should show up in the list of scripts in firebug and webkit inspector.
jQuery could be patched to do this automatically, but the ticket was rejected.
Here's a related question: Is possible to debug dynamic loading JavaScript by some debugger like WebKit, FireBug or IE8 Developer Tool?