safari

This is a quick blog post, mostly for my own reference.

I finally got sick of a certain government website thinking that preventing pasting passwords into certain forms was some sort of security feature, so I am documenting my workaround in Safari for stupid forms written by compliance-minded folks (the same who think that expiring passwords every 30 days leads to any kind of better security).

In Safari, select Develop > Show Javascript Console (or press ⌥⌘C, that's Option + Command + 'C')¹.

Paste the following into the console and press 'Enter':

var allowPaste = function(e){
  e.stopImmediatePropagation();
  return true;
};
document.addEventListener('paste', allowPaste, true);

Now you can paste to your heart's content.

¹ If you don’t see the Develop menu in the menu bar, choose Safari > Preferences, click Advanced, then select “Show Develop menu in menu bar.”

Over the years my site has evolved quite a bit; I started this site (well, one form of it at least) around 2004, when table based web design was still a thing. I've evolved the design from table-based to CSS, to semantic CSS, to CSS + RDF, then to mobile-first... and now that macOS 10.14 Mojave is here, with a snazzy (and way easier on my eyes) dark mode, I have made the design work well in both normal (light) and dark mode on macOS.

It's using a new feature in the Webkit nightly builds (er, now called Safari Technology Preview), a media query named (at least, for now) prefers-color-scheme.

And here's how the site looks when you're using Safari Technology Preview 68+ in macOS Mojave with Dark Mode:

I do a lot of local development, and since almost everything web-related is supposed to use SSL these days, and since I like to make local match production as closely as possible, I generate a lot of self-signed certificates using OpenSSL (usually using Ansible's openssl_* modules).

This presents a problem, though, since I use Safari. Every time I rebuild an environment using my automation, and generate a new certificate for a domain that's protected with HSTS, I end up getting this fun error page:

Safari Can't Open the Page – Safari can't open the page because Safari can't establish a secure connection to the server 'servername'.

A few months ago, I switched to Safari after having used Google Chrome exclusively for the past four years (before that it was a mix of Safari and FireFox). Safari is lean and fast, but the one thing that really bothered me was the fact that I would often try searching for something by entering keywords in the location/address bar, then hit enter, and nothing would happen.

I quickly realized that if I did this and nothing happened, I could jump back into the location bar (⌘-L), press the left arrow key to get my cursor in the beginning of the string, then hit space and enter to perform the search.

Until today, I've begrudgingly used that workaround. But then I was checking Safari's preferences to see if I might be missing something obvious, when I decided to uncheck some options and see if it made a difference. And it did!

Kerberos authentication allows your computer to log into certain services automatically without you having to enter (and re-enter) your password (it's a SSO—single sign-on—service). Kerberos v5 is baked into Windows and Internet Explorer and works great with many LDAP-enabled services (for example, Drupal's LDAP module allows includes a submodule for SSO support).

Kerberos is built into Mac OS X as well, but isn't as simple to use and configure with Chrome and FireFox as it is with Explorer on a Windows workstation. You need to do two things before you can use Kerberos for authentication in Chrome/FireFox:

Google lit up the hornet's nest yesterday when they announced that they were dropping built-in support of H.264 for their own 'open' WebM and OGG video formats.

I reconfigured Xmarks on all my computers (to sync all my bookmarks between FireFox, Safari and Chrome), and I'm back to using Safari full-time, with FireFox as my main backup. (FF 4.0 can't come soon enough).

It was good knowing ye, Chrome. I actually had my sights set on using Chrome indefinitely until yesterday.

For some users, being able to tab through all clickable elements on a page is a blessing. For most, though, it's a curse (at least, in my experience). The default behavior of a browser should be to allow users to tab through form elements only (textfields, textareas, search forms, submit buttons, etc.).

For some time now, Google Chrome has only allowed users to tab through every. Single. Element. on the entire page. Luckily, there's a new setting that popped up in the 'Under the Hood' settings recently that allows a user to turn off this insane behavior.

In Chrome, select Preferences, then click on 'Under the Hood.' Go down to 'Web Content' and uncheck the checkbox next to "Pressing Tab on a webpage highlights links, as well as form fields."

Voila! Problem solved - now I can substitute Chrome for Safari much more readily. That and being able to read PDFs in-browser...

Chrome was great. It was Safari, with a little more speed, better tabs, and a cool status bar that would only show when it needed to.

But I'm switching back, for the following reasons: