Develop Reference

in iOS8 using .focus() will show virtual keyboard and scroll page after touch

Prior to iOS8, using the Javascript .focus() method on an input element would appear to have no effect (the virtual keyboard would not display). After the latest iOS 8 release, running the .focus() method seemed to have no effect on page load but once a user touched anywhere on the screen the virtual keyboard would instantly appear and scroll the page to the element in focus. (This is also an issue when I use the HTML attribute "autofocus")
This change has caused issues with iOS8 users on my site. When a user attempts to click a button on my page the sudden scroll and keyboard appearance causes them to unintentionally click a button that was lower on the screen.
I am assuming this is a bug in iOS8 and was not intentional feature, my question is what is the most efficient solution to fixing this problem?
Do I have to check navigator.userAgent to see if the device is iOS8, every time I use the .focus() method?

It looks like you're definitely hitting an iOS 8 bug. In iOS7, Safari would (apparently) ignore or keep unfocused elements that had focus set prior to page load. This includes both <input autofocus> and input.focus() that occur up to some point, possibly page load (I tested just with an inline script).
In iOS 8, Safari is now apparently remembering that the element was focussed but not actually focussing it until a touch down event. It is then blindly sending a click event to whichever element received the touch up.
Both browsers behave the same for input.focus() occurring after page load. They both zoom to the element and bring up the keyboard.
Tests:
input.focus() before page load: http://fiddle.jshell.net/qo6ctnLz/3/show/
<input autofocus>: http://fiddle.jshell.net/qo6ctnLz/4/show/
input.focus() after page load: http://fiddle.jshell.net/qo6ctnLz/6/show/
The good news is that you only need to be worried about new behavior on elements you want to prefocus. The other good news is that while you will have to use a user-agent workaround, you can use it for all iOS versions since they were already behaving like you weren't autofocusing:
if (!/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
element.focus();
}
This appears to be the approach http://www.google.com uses based on some basic user-agent testing:
Mac Book Pro: autofocus before page load.
iPhone: no autofocus
iPad: no autofocus
Kit Kat (Android): focus after page load, possibly doing extra detection for presence of software keyboard.
If you haven't, you should go ahead and file a radar with Apple at https://bugreport.apple.com.

If you are developing a Cordova project, you can fix it adding this line
<preference name="KeyboardDisplayRequiresUserAction" value="false" />
to your config.xml file. Tested in IOS 8.3 and IOS 8.4

It seems that in iOS 8 there has been an API change on the default handling for the javascript focus() command. If your application is a hybrid app in which you have direct control over Apple's web view facade the below is directly from apples docs.
A Boolean value indicating whether web content can programmatically
display the keyboard.
[myWebView setKeyboardDisplayRequiresUserAction:YES];
When this property is set to YES, the user must explicitly tap the
elements in the web view to display the keyboard (or other relevant
input view) for that element. When set to NO, a focus event on an
element causes the input view to be displayed and associated with that
element automatically.
The default value for this property is YES.
From the last paragraph it seems this method call is not strictly for the keyboard. It indicates that it is for input views across the board i.e. drop down and date picker etc.
It seems though there is a bug as this method call is not currently working for me. The current behavior I am receiving corresponds as if it defaults to NO.

I have a solution:
Disable all inputs
Enable the input you wish to focus
Set the focus to that input
Re-enable all the other inputs

Here's a conditional monkeypatch for jQuery.focus so you don't need to add the userAgent test everywhere.
JavaScript
if (/iPad|iPhone|iPod/g.test(navigator.userAgent)) {
(function($) {
return $.fn.focus = function() {
return arguments[0];
};
})(jQuery);
}
CoffeeScript
if /iPad|iPhone|iPod/g.test navigator.userAgent
(($) ->
$.fn.focus = ->
arguments[0]
)(jQuery)
Note: I'm returning arguments[0] so we don't break method chaining such as $(el).focus().doSomethingElse()

I've logged a bug about this into the Apple Bug Reporter and they closed it as duplicate, which is a sign they are working on fixing this. Unfortunately they didn't give me some more information about the duplicate item or about the problem itself. I can only see the duplicate item state, which is Open.

For anyone coming to this on 2018, there is a plugin that fix it. Just install this https://github.com/onderceylan/cordova-plugin-wkwebview-inputfocusfix and input.focus() will work automatically without any additional work.

IE11's F12 developer tools lack option to keep console on navigation

Trying to debug a problem that's IE-11 specific, I would like to see the console messages logged when a certain control is clicked. But the control refreshes the page, which makes F12 tools automatically clear the console, so whatever is logged just before that, I don't get to see!
Past versions of IE had an option to keep the console contents on navigation. Is this option available in IE11? If so, where is it? If not, is there some other way to view the console that doesn't immediately discard the message I want to see?

In with the latest F12 update to IE11 (that came as part of the Win8.1 Update) there is now a button to disable "Clear on Navigate"
Additionally, you can enable IE to record messages in the Console at all times instead of only when the Console is open.
For all the changes to the IE11 F12 dev tools see: http://support.microsoft.com/kb/2929437

Ran into this and I didn't find a good solution, but I found a hacked one that worked well enough for me to debug.
Use window.onbeforeunload to pop up a window so you can at least see the values before they are purged.
See: Prompting and preventing user from navigating away/closing a page

location.reload() behaving differently in chrome vs ff on page arrived at by POST

For non-negotiable reasons unique to the legacy system I am doing work on, a POST query is used to switch between tabs of a particular web interface.
On occasion, I need to trigger a refresh of the current tab and would typically use js's location.reload() to accomplish this. However, in this context the behavior is different in Firefox vs. Chrome.
Specifically, FF resubmits the POST query that brought me to my current page, whereas Chrome does not. As a result, FF ends up where I started, and Chrome instead goes to the URL in the address bar.
Does anyone know of a cross-browser means of accomplishing what FF does by default on location.reload()?

Try using it with true
window.location.reload(true);

I believe this is a bug in Chrome.
Take a look at the attached bug description.
http://code.google.com/p/chromium/issues/detail?id=30479
Although it mentions the back button, I see the same issue using location.reload(true) if I have a form using session cookies. That is, in IE and FF it reposts and reloads OK. In Chrome it does not.

Reload using location property:
window.location = window.location;

Print silently in Chrome

I need to be able to print silently in Chrome. In my ticket system no print dialog can appear, I just wont it to print on my javascript command.
I've done this before in Firefox but now I will change to Chrome as browser.
There is a ticket on this:
https://code.google.com/p/chromium/issues/detail?id=31395#c4
Comment #4 says:
If --kiosk is specified and the preference printing/printer/default is specified, the
print dialog will be skipped.
I have set kiosk mode but dont know where to change the preference printing/printer/default he is talking about? At least it does not exists in my version of Chrome (14.0.835.35 dev-m). But I have a default printer in windows.

For silent printing, you must start Chrome with the --kiosk AND --kiosk-printing flags. This will cause Chrome to display but immediately close the print dialog upon the user attempting to print the page or javascript executing window.print().
Because the print dialog will no longer be available, the printing will automatically use the settings that were last selected in Chrome (or the system default).

The issue you linked to isn't resolved - it is marked as "Available" meaning that it is waiting for some developer to work on it. "printing/printer/default" preference is merely a suggestion for how this feature should be implemented. Comment 4 is about merging a similar issue, not about the actual implementation.

Console.log messages not showing up in Chrome's javascript console?

I am logging using the jQuery.log plugin (which logs to console.log if available) and I am not seeing any of the logging messages appear in the Chrome JavaScript console.
Logging works on Firebug's console under Firefox, but I did have to explicitly enable the Firebug JavaScript console. Have a missed some option somewhere under Chrome?
Edit:
The only thing being logged to the console is
Uncaught Syntax error, unrecognized expression: |button
I assume that the Chrome console is suppose to log statements even after errors like the one above, but there may be some kind of issue with Chrome here, see http://code.google.com/p/chromium/issues/detail?id=29062. I am using Chrome 5.0.375 under Linux and that bug is listed as a Windows XP, Chrome 4.0 issue, it could still apply.

I've just had the same problem and found this question when trying to find an answer.
What fixed this for me was disabling firebug lite in chrome.
It was swallowing all console messages.

Make sure you have the console showing and that it is showing "All".
The cursor is on the button to hide/show the console.
Update: In newer versions of Chrome, you need to click the filter icon, then make sure "All" is selected.

When playing around with example Chrome Extensions, I was often unable to see the console.log messages when looking at console (ctrl+shift+j). But then I realized, that I was in the wrong place.
Wrench -> Tools -> Extensions and then click on the appropriate link under "Inspect active views". (in the Chrome examples it is often background.html) This should bring up the console that you are looking for.

On my computer I had accidently clicked the Debug filter. This made my log messages hidden. Here's how it was before (hidden messages):
Here's how it was after the change (working messages):

I am not sure if this is the case, but if you are using firebug with chrome, you have to turn firebug off in order for console.log() to work in Developer Tools.

I just found out logging was disabled from my filters.

For me, it was because the script was being cached and the browser was not loading my latest version.
Try Ctrl+F5 to reload your page.

Resetting default setting works for me.
While in the console tab, pressingF1 should open the setting page. There you will different settings that you can adjust including the button Restore defaults and reload.

I have this error by have obfuscated javascript code, deobfuscate and console.log work again)