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.
Related
I came across a website that runs this code:
function check(){console.clear();before = new Date().getTime();…
^^^^^^^^^^^^^^^
on load, discarding valuable console messages. How can I make Firefox
ignore console.clear() globally?
I wonder why that even exists in the first place. It should not be
possible for a website to delete potentially relevant debugging output.
You can solve this in two ways,
First, you can write a firefox extension which executes a javascript on page load and assigns empty function to console.clear. So, it doesn't throw any error if its called.
console.clear = () => {}
References for building extension to run on page load
Chrome Extension: Make it run every page load
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Modify_a_web_page
Secondly, you can load the page once and open devtools and goto sources and search for console.clear and add breakpoints every where its called and reload the page. The code execution will stop when the console.clear is called for the first time and again you can goto console and assign console.clear with empty function and override.
Reference for Using BreakPoints in Firefox
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Set_a_breakpoint
Since you're asking about Firefox, if you don't want to write your own extension, you can use the one that already exists:
Disallow Console Clear Firefox Addon
It is right to hijack the console.clear on page load.
Here just a tip/record.
For some sites, there would be no explicit word console.clear in the sources. (And sadly, currently Firefox's Preserve Log option might still not be as powerful as Chrome's)
But the hijack might still work even!
BTW it might happen that "directly reassigning console.clear in console" not works.
So just try it.
I'd love to use History.js for its ability to handle history (pushState etc.) in older browsers but I'd need to disable the default behavior that automatically converts hashes into a "normal" url path.
By that I mean that by default the script changes link#hash to link/hash. It is great that if a push a state of "otherlink", it gives older browsers the #otherlink hash so it can still be handled but I need it to NOT automatically change link#hash to link/hash when the page is loaded. History.js seems to include an auto-initialize code so I don't even know how to load it with customized options.
To be specific, what I need is:
A page link#hash will remain link#hash
History.pushState (..., "#hash") will push the state but the page will be page#hash not page/hash
History.pushState (..., "hash") will be page/hash in modern browsers but page#hash in older browsers (and the script will handle what needs to be handled to load proper content).
I hope it makes sense. If it doesn't I can provide more information.
Thanks for help.
https://stackoverflow.com/a/21673425/2903169
Quoted from previous answer I gave earlier today (retaining the hash in history.js seems to be a popular question)
Within the History.js github repo, you can set the options to force
hashtags as Default
History.js Github Readme, Options Link
History.options.html4Mode If true, will force HTMl4 mode (hashtags)
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
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
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?