I'm trying to debug the JavaScript of a website which references some JS via a random URL path each pageload. This makes Chrome think that the JS is a different document, but I can see the same JS is being served up each time. However, breakpoints don't stay because the URL is different.
Is there a way I can get breakpoints to stay somehow between page loads of the same JS with different URL paths, or maybe break on function name instead of the normal way?
The only way i think is to put
debugger;
everywhere you wanted the breakpoint. As you have rightly understood that the browser considers it as a new file, and there is no way to tell the browser that it is same file when the URL is different.
Related
I have a weird network request in my page, which refers to JavaScript files, which I removed from every html file earlier. Cache is cleared and there is no single reference to be found in the source html and the JavaScript files. For fixing that and also out of general curiosity I would like to know if there is a simple way to find out where a request was triggered, preferably using the chrome-devtools.
Update:
Thanks to jaredwilli I found the initator column under the network-tab. However this only shows Other. What I would like to know, is the (html or javascript) file where those Requests have been triggered.
On the Network panel, you can determine what the initiator of a request was by viewing the Initiator column. It gives you the file, line number and type of resource it was, either Script or something else.
I'm using a WebView to scrape an unholy mess of a website with a bizarre mix of HTTP and Javascript redirects. In my injected script, I need to get the current URL, but it seems like none of the relevant properties ever return anything other than the URL I passed to WebView.loadUrl, even after a redirect.
I've tried:
window.location
window.location.href
document.URL
document.location
document.location.href
document.documentURI
So what's going on here and how am I supposed to get the current page's URL with Javascript?
I was injecting my script in the WebViewClient.onPageStarted method to try and make it execute as soon as possible, but it appears that the window context isn't completely set up at that point. When I moved my injection code to WebViewClient.onPageFinished, it started retrieving an accurate URL from the properties I listed. It's not really an ideal solution, since my script now has to wait for the entire page to load, but I don't know of any other way to do it.
On a page I have a an iFrame and a swf, I've been trying to use ExternalInterface to pass values from the swf to the iFrame, anyone ever tried this and had any luck? I won't be able to post any code until tomorrow, will update then if needed.
Thanks in adavnce.
Here is a visualization of what I need to accomplish, perhaps if it can't be done the way I said someone will have a suggestion of another way to accomplish this.
Try to target the frame. This should work with one frame on the page or you will have to change the index.
duhFrame = window.frames[0]
targetElement = duhFrame.getElementById('someIframeElement');
If this doesn't work for you then use LocalConnection and put a hidden swf on the iframe file.
LocalConnection is Global to the browser so be aware that if two browser windows are open you will get two iframes connecting on the same name and will get some funky results. So change the connection name via query string and flashvars.
Its a real hackish workaround but it will work.
[EDIT]
One more thing make sure your javascript callback function is getting called as ExternalInterface has major domain issues when running under the file structure and not in a domain(EX: clicking run in the editor ). Try uploading to your server and change your embed code to allow for it. Also dont forget to update your crossdomain.xml(s).
You cannot access iframes from outside of them. These are security reasons, and browsers will and should block such attempts.
If this has been asked before, I apologize but this is kinda of a hard question to search for. This is the first time I have come across this in all my years of web development, so I'm pretty curious.
I am editing some HTML files for a website, and I have noticed that in the src attribute of the script tags that the previous author appended a question mark followed by data.
Ex: <script src="./js/somefile.js?version=3.2"></script>
I know that this is used in some languages for value passing in GET request, such as PHP, but as I far as I ever knew, this wasn't done in javascript - at least in calling a javascript file. Does anyone know what this does, if anything?
EDIT: Wow, a lot of responses. Thanks one and all. And since a lot of people are saying similar things, I will post an global update instead of commenting everyone.
In this case the javascript files are static, hence my curiosity. I have also opened them up and did not see anything attempt to access variables on file load. I've never thought about caching or plain version control, both which seam more likely in this circumstance.
I believe what the author was doing was ensuring that if he creates version 3.3 of his script he can change the version= in the url of the script to ensure that users download the new file instead of running off of the old script cached in their browser.
So in this case it is part of the caching strategy.
My guess is it's so if he publishes a new version of the JavaScript file, he can bump the version in the HTML documents. This will not do anything server-side when requested, but it causes the browser to treat it as a different file, effectively forcing the browser to re-fetch the script and bypass the local cache of the file.
This way, you can set a really high cache time (like a week or a month!) but not sacrifice the ability to update scripts frequently if necessary.
What you have to remember is that this ./js/somefile.js?version=3.2 doesn't have to be a physical file. It can be a page which creates the file on the fly. So you could have it where the request says, "Hey give me version 3 of this js file," and the server side code creates it and writes it to the output stream.
The other option is to force the browser to not cache the file and pull down the new one when it makes the request. Since the URI changed, it will think the file is completely new.
A (well-configured) web server will send static files like JavaScript source code once and tell the web browser to cache that file locally for a certain period of time (could be a day, a week, a month, or longer). When the browser sees another request for that same file, it will just use that version instead of getting new code from the server.
If the URL changes -- for example by adding a query string -- then the browser suspects that its cached version is no good and gets a new one. As such, the ? helps developers say "Oops, I changed this file, make sure the browser gets a new copy."
In this case it's probably being used to ensure the source file isn't cached between versions.
Of course, it could also be used server side to generate the javascript file, without knowing what you have on the other end of the request, it's difficult to be definitive.
BTW, the ?... portion of the url is called the query string.
this is used to guarantee that the browser downloads a new version of the script when available. The version number in the url is incremented each time a new version is deployed so that the browser see it as a different file.
Just because the file extension is .js doesn't mean that the target is an actual .js file. They could set up their web server to pass the requested URL to a script (or literally have a script named somefile.js) and have that interpret the filename and version.
The query string has nothing to do with the javascript. Some server side code is hosting up a different version depending on that querystring it appears.
You should never assume anything about paths in a URL. The extension on a path in a URL doesn't really tell you anything. URLs can be completely dynamic and served by some server side code or can rewritten in web servers dynamically.
Now it is common to add a querystring to urls when loading javascript files to prevent client side caching. If the page updates and references a new version of the script then the page can bust through and cause the client to refresh it's script.
I currently have the following JavaScript function that will take current URL and concatenate it to another site URL to route it to the appropriate feedback group:
function sendFeedback() {
url = window.location.href;
newwin = window.open('http://www.anothersite.com/home/feedback/?s=' + url, 'Feedback');
}
Not sure if this is the proper terminology, but I want to mask the URL in the window.open statement to use the URL from the current window.
How would I be able to mask the window.open URL with the original in JavaScript?
Things you could do:
1- Mask the external site in a html frame inside a document from your site.
(for example www.mysite.com/shortUrl/)
2-Send a Location HTTP header (real url will eventually be displayed)
Keep in mind that browsers do their best to show the real address due to phishing concerns.
I wouldn't use javascript if I wanted to mask url even thought it would work with javascript. You wouldn't get much benefits in that scenario.
The reason is simple:
javascript/jQuery = functions belongs to client-side (browswer/your PC/DOM)
links, url, http, and headers = functions belongs to Apache.
Apache is always top level above client-side. Whenever link is fired to SampeLink.html, Apache wakes up and reads the file, but links/urls are already owned before javascript could claim them. So, it is kinda of pointless if you tried to manipulate links in your javascript scripts, even though it works but weak.
I'd point you to this awesome approach: .htaccess and you will be surprised how powerful it is. If .htaccess is presented in the parent folder of SampleLink.html, Apache denies the DOM engine (your browser) from reading files until Apache have finished reading .htaccess.
With your scenario, .htaccess can do some work for you by rewriting links and send "decoy" links to the DOM engine, meanwhile keeping the orginial links/urls behind the curtain; and visitors would reach to 404page if they tried to break the app or whatever you are concerned about.
This is a bit complicated, but it never ceased to fail me. I use this as my "bible" http://corz.org/serv/tricks/htaccess2.php.