Develop Reference

Can JS be used to check for and log temporary page changes by end users via dev tools or the console?

The setup for this will be a Chrome instance on a VM I control (and thus can install anything I need onto it) for the purposes of monitoring changes to a web page that were not made by the web code itself. I will be testing a web site (on a Linux build, in Apache using a Tomcat or Jetty instance) which displays data from a backend database (I won't bore anyone with the details). That data once displayed can of course be edited by anyone who knows how to use dev tools and inspect element features in certain browsers, and while the changes made won't propagate back to the backend and can be wiped out with a refresh, I would like to monitor to see if those changes were nonetheless attempted.
I have already managed to find a way to monitor if the Dev Console has been opened using Chrome by using an extension that specifically hooks into its' toggle. Coupled with some JS code, I can then act upon when it is opened, closed or both, and for example, force a refresh of the page in the event that someone used the inspect element to make changes to the rendering of the page.
I would like to then check to see if any of the client-side elements have been altered, capture the changed values, and then retrieve the original data from the back-end to compare against (I can manage the back-end stuff). I've seen a few examples of the use of InnerText and InnerHTML as a means of checking, and will try it out later, but wanted to know if anyone had any experience with anything similar.

Why does reloading page in Firefox or Chrome cause the unload event handler to trigger after the browser calls the server?

I noticed something odd in the way Firefox and Chrome handle reloads, and I was wondering if anybody else has encountered this and perhaps knows why.
I have a window.onunload event where I set a cookie (in this case using YUI, but native JS or jQuery would work the same). This cookie normally gets sent in the HTTP request to the server, where the server-side code looks for it. If the cookie exists, it can take a special action.
window.onunload = function() {
Y.Cookie.set('reset_function', 'true', { path: '/'});
}
This works fine when the user is going from one page to another page via a link on the page. However, when the user reloads the page, the cookie is being set in Firefox and Chrome (i.e. I verified the code is being executed via Firebug/Chrome DevTools), but the cookie is NOT sent to the server, so the server can't take the special action.
Has anybody encountered this and know why? Is this behavior baked into these two browsers?
EDIT: When I debugged this further, on reload, Chrome and Firefox go to the server first and then go through the onunload event handler. I'm still unsure why the browser behaves like this.

I could be wrong, but my guess would be that it's just a performance optimization.
First, you should be aware that the onunload method is (last I checked) not allowed to prevent the user from navigating off the page. If it were, I think there'd be a lot more malicious inescapable websites!
What it can do (on some browsers, anyway) is prompt the user with a message, and give the user the opportunity to cancel navigation.
Since this prompt takes some non-zero amount of time, the browser developers (for Chrome and Firefox) may have decided to go ahead and make the request first, so that if the user pauses for a moment and then confirms, the subsequent page will load as fast as possible.
I don't really know if this is accurate or not, but it's one possible explanation. Note that the onunload method is not part of any standard, which means its behavior isn't exactly clearly defined anyway, which means the browser makers are free to put the request before or after the event handler, as far as I can tell.

javascript urls in IE pinned site task list

I'm attempting to set up Pinned Site features for my project. The trouble is that I'd like to have the tasks be javascript actions rather than loading a new page. The reason for this is that the site is designed to only ever work in a single window.
I tried adding the following META tag:
<meta name="msapplication-task" content="name=Test Action;
action-uri=javascript:ui('test',8);icon-uri=/img/icons/test.ico" />
However this causes the task to simply not appear. (Using a normal URL makes it show up just fine)
Is there any way to do this? The best I can think of is a hash and check for the hashchange event, but this doesn't work because it gets opened in a new tab of the window...

I'm afraid this is not supported, because action list is designed for launching an application, not for a navigation inside it.
If you really want implement it, you can open a new window, send a message to server via web sockets and let server to forward that message to application window also via web sockets. But this is very hacky approach and works only in IE10.

This issue can be resolved by using a hash. By setting the action-uri to something readable by JavaScript, the JS can then read it, process the instruction, and then clear the hash in preparation for the next task.
This has the advantage that it works even when the window isn't already open, since the JS will read the hash on the first load too.
The catch is to add window-type=self to the content.

Can I detect certain browser (IE) setting (not change, detect)?

I was just looking at this stackoverflow question: Display web browser settings
And that helps.
But, I'm curious if I can detect certain IE specific settings. I'm thinking some of the stuff in the Advanced Tab (e.g. Is 'Enable Integrated Windows Authentication' on)?
Or that our site was added as a Trusted Site? And within the Trusted Site settings, "Atomatic logon with current user name and password" is set?
I don't want to change them (I get that would be a huge issue that could be exploited). I just want to be able to present to the User:
"Hey, you need these couple of settings checked or unchecked for the site to work properly. Do this: a, b, c ... or Contact your Administrator".
Is this possible?

I don't think you can query these settings from within a web site. Being able to do so might introduce security holes.
I'm sure some settings can be determined by using circumstantial evidence (like if a JavaScript doesn't execute, scripting is probably disabled). But I don't think there is a proper API to poll every setting; I guess the best you can do is serve the user some advice on what to look for. (like, "The xyz symbol in the bottom right bar should show a green checkmark like so.... the abc checkbox in the options dialog should be unchecked... etc")

You can't check the settings directly, but you could test the functionality instead. If you attempt to authenticate with the server and find out you don't have their credentials passed in properly, you know it's not configured right. At this point you could show them your information about how to connect to the site. This would be a better solution anyways, as you're better off testing for features rather than specific settings.

To distill your question down, it looks like you're trying to find out whether IE is configured to automatically send NTLM credentials to your server.
Unfortunately, there's no way to cleanly feature-detect this. My initial thought was to put a JavaScript file in a protected directory that simply set a global variable, and link to that script in the <head>. (<script src="protected-dir/test.js"></script> – protected-dir would be configured only for integrated auth with anonymous auth off.) If the script loads, the variable is set; and if it fails, the variable obviously isn't. Another script on the page could check the variable and show a message if it's not set.
This works flawlessly when everything is configured correctly on a client, but when auto login is off, this causes an ugly 401 dialog to pop up, which is clearly no good. Additionally, a XHR request isn't the answer since the spec specifically says the browser should ask for credentials if it gets a 401.
Sadly, I don't think there's a way to automatically determine if auto login is enabled without causing the 401 dialog to pop up.

Safari doesn't allow AJAX Requests after form submit?

I am writing a Javascript based upload progress meter. I want to use the standard multipart submit method (rather than submitting the file in an iframe). During the submit, I send ajax requests that return the % complete of the upload and then update the progress meter accordingly.
This all works smoothly in FireFox & IE. However, Safari seems prevent the completion of ajax requests after the main form has been submitted. In the debugger, I can see the request headers, but it appears as though the response is never received.
Anyone aware of this, or how to get around it?

Yes, this is how Safari and any browser based on WebKit (i.e. Google Chrome) behave. I recently ran into this on a file upload progress meter also. I ended up using the same technique seen at http://drogomir.com/blog/2008/6/30/upload-progress-script-with-safari-support to get the ajax to work. In my case, I didn't want to change the look of my application to the one Drogomir uses, but the technique itself worked. Essentially, the solution is to create a hidden iframe only in Safari that loads jQuery and your AJAX script. Then, the top frame calls a function in that frame on form submit. All other browsers still work the same as before.

This is a WebKit bug. See https://bugs.webkit.org/show_bug.cgi?id=23933

Are you using an iframe to submit your form to? I'm guessing that once the form is submitted, the page enters a state where no more modifications to the DOM can be made.
Check a tutorial such as this one for more information.

This actually sounds like correct behaviour to me - and im surprised that firefox and IE behave otherwise.
It is akin to you attempting to leave a page and the page still interacting with you - sounds naughty!
i can see why this would be of benefit - but I would hope it only the case if you are performing a POST to the uri you are currently accessing, or at worst same-domain.