A guide to cross-browser testing: installing all the things

So, you’ve written a website. Your carefully crafted HTML, CSS and JavaScript sits waiting to be sucked through the ether into the wild world of browsers.
With any luck it will land in a nice new Chrome or Safari. But maybe your beloved code will find itself cold and alone in the bowels of a Yandex browser, or UC or IE8 or … a BlackBerry.
This sucks a bit and it’s a common pastime of some web developers to complain about the inconsistencies between browsers.
But complaining is what you do when you’re out of ideas. So instead I thought I’d write a guide to setting up the bits and bobs required to test a bunch of different browsers and devices.
If you care to follow along, in a matter of minutes you should have the following browsers ready to use on your local dev machine (all legit and free).
  • Internet Explorer 8 and up
  • Edge 14 and 15
  • Chrome for Android
  • Chrome for Windows
  • Chrome for macOS (macOS users only)
  • Chrome for iOS (macOS users only)
  • Safari for macOS (macOS users only)
  • Safari for iOS (macOS users only)
  • Firefox for WindowsFirefox for macOS (macOS users only)
Depending on your users, you should throw Linux, UC Browser, Samsung Internet, Opera and any others into the mix.
I will also mention Browserstack and tell you why you should tell them to shut up and take your money.

Choose your browser support

Step uno is deciding to care. If you’ve got a bad attitude towards users of inferior browsers and operating systems, that’s going to slow you down.
Or, be like me and replace caring with greed (compassion free since ’93) — I see slices of browser share as slices of a profit pie.
Whatever motivation works for you, decide which browsers you will support. Base it on your traffic (or stat counter if your site isn’t live yet). Put it in your readme. Keep it up to date. Tell all your developers.
Browser support doesn’t have to be a hard line in the sand, though — that’s what progressive enhancement is all about.
Some examples?
  • Earthquake disaster contact info site: All information on the site is accessible on anything that can render HTML
  • Shopping site: Needs JavaScript. The site behaves the same in all browsers from IE11/Safari9+. The purchase journey can be completed on IE8/Safari 7 although the site might look a bit crappy.
  • know-it-all.io: “if your browser is more than three weeks old you don’t belong here
I’m quite lucky with know-it-all.io because you lot — my users — are all web developers, so my browser share looks like this:
Not an IE in sight, God bless you all
I didn’t need to show that, I just wanted to say thanks for being awesome.

Maximize the use of your favourite browser

I used to think the responsible way to work was to share my development time between all the browsers I endeavored to support.
I have come to believe the opposite is true.
I now think that the fastest way to get stuff done is to spend as much time as possible in my favourite browser (Chrome) and only go to other browsers to ensure the site works.
Of course for this the be a viable approach, it is important to build up an idea of which language features work seamlessly across all browsers, and which might cause trouble.
Then, when you’re working on something prickly (let’s say, flexbox) you will open up 8 different browsers because you know it’s a jolly old mess.
So lesson one I suppose is to hone your mental cross-browser testing skills.
I, for one, have invested in a cross-browser parrot. He sits on my shoulder watching me code, if I type classList.toggle he will screech WON’T WORK IN IE, WON’T WORK IN IE.

Apple vs Microsoft

There’s a nugget of truth in the old anthropomorphic trope: Apple the cool kid and Microsoft the nerd.
Microsoft is like the accountant for the school dungeons and dragons club. He wants to help you with your homework and make sure you can run all the Windows versions on macOS without cost or cause for worry.
Apple meanwhile is dressed in black, hanging out at the far end of the schoolyard with kids that don’t even go to this school. He make’s no effort to help you test iOS or macOS if you’re a Windows user — buy a Mac, loser.
The world is an unfair place, and so — because of Microsoft’s efforts — macOS is the superior operating system for web development.
(If this was a competition for reader alienation, the judges would all be standing tall, holding up 10’s. One of them has a tear rolling down her cheek.)
OK OK, to save those poor angry people from the bother of getting angry, let me water down my opinion to something only the insane could disagree with: “it is easier to run Windows on macOS than it is to run macOS on Windows.”
As such, the below is quite heavily focused towards Mac users.
Now, how about we see how many browsers we can get set up on our development machines without standing up.

Windows on macOS

There should not be a single web developer on the planet that does not have access to Windows.
If you are one such person, that’s OK, no judgement. Just head on over to Microsoft’s modern.ie and grab a VM. They range from IE8 on Windows 7 up to Edge 15 on Windows 10, and you can use Vagrant, VirtualBox, VMware or Parallels.
If you’re not sure what all of this means, I recommend “Microsoft Edge on Win 10 Stable” (this will give you Edge and IE11) and VirtualBox.
OK have you downloaded some VMs and got them running? You found the instructions on the download page, right? Read the note for Mac users about unarchiver, right? Great, great.
All the Windows browsers
As a macOS user, you of course want Windows so that you can test Edge and IE. But you also need Windows to test the Windows version of Chrome and Firefox, since they are different to Chrome and Firefox on macOS.
How so?
Scrollbars and fonts.
If you’re a Mac user and never have scrollbars turned on, you probably don’t know that your site jumps to the side as content loads and also when modals open/close. It’s jarring.
(I went looking for an example and the third site I picked, uber.com, does this when their menu opens — the whole page jumps 16px to the right.)
This post isn’t about code but the sixteen-pix-sidestep is a pet peeve so please, just do this if you only need a full-screen modal (it will force the page to the top):
/* the page should not change width as content is loaded */
body {
  overflow-y: scroll;
}

/* block scrolling without losing the scroll bar and shifting the page */
/* add this class when a modal is open */
body.block-scroll {
  overflow: hidden;
  overflow-y: scroll !important;
  position: fixed;
  width: 100%;
}
Or this to block the scroll without changing the scroll position:
let bodyBlocked = false;

export function blockScroll() {
    if (
        typeof window === 'undefined'
        || typeof document === 'undefined'
        || !document.body
        || !document.body.style
        || bodyBlocked
    ) return;

    const scrollBarWidth = window.innerWidth - document.body.clientWidth;

    document.body.style.paddingRight = `${scrollBarWidth}px`;
    document.body.style.overflowY = 'hidden';

    bodyBlocked = true;
}

export function allowScroll() {
    if (
        typeof window === 'undefined'
        || typeof document === 'undefined'
        || !document.body
        || !document.body.style
        || !bodyBlocked
    ) return;

    document.body.style.paddingRight = '';
    document.body.style.overflowY = '';

    bodyBlocked = false;
}
As for fonts, a good general rule is to never rely on text being a certain width. If you do rely on this, test in every single browser ever made.
Here’s an iPhone 6 emulated in three different ways. Notice the cutoff point for ‘Culture’ in Medium’s header:
Simulator on macOS
Chrome on macOS
Chrome on Windows
(OK smarty pants, I know Medium uses native fonts (go Medium!), but I’d already taken the screenshots when I remembered. The message stands — don’t rely on text being exactly the same width on all devices.)

Finding your way around unfamiliar browsers

If you don’t know how to inspect your JavaScript in some foreign browser’s dev tools but want a breakpoint, just put the keyword
debugger
in your code. You can even do a fakey ‘conditional breakpoint’.
I haven’t the foggiest idea how to drive F12 (the IE dev tools), but here’s me inspecting a breakpoint like a champ:
Ah yes, I suppose my element ID isn’t “appnpm run dev”
If you forget what to type, just remember that it’s for when you’ve buggered something up and you want to debugger it.

macOS on Windows

As I hurtle towards 40 I have grown unwilling to do anything where the first step is “do a full backup of your system”. And since there is no official way to install macOS on Windows, this is the best you’re going to get.
If you’re young at heart and crave some Apple in your Window, hackintosh.com awaits.

iOS on macOS

Getting access to a virtual iPhone and iPad is vurry easy. You will use Simulator, which ships with Xcode (it’s so hard to keep track of where the capital letters go in Apple products).
You’ve got access to a whole bunch of iOS devices right there in Simulator, there’s not much to say about it.
They render actual pixels, not CSS pixels, so you may want to scale the device down to 50% to keep the whole thing visible on a smaller screen.
See, really not much to say about it.
The simulator is pretty accurate as far as I can tell. It even has the same insanely annoying behaviour of hijacking click events near the bottom of the viewport.
Pro-tip: never create an interface that relies on a user clicking something at the bottom of the screen. iOS Safari will punch you in the face.
Dev tools for Safari on iOS on macOS
If you want to inspect your site while it’s running in iOS Safari, you can use the macOS Safari Web Inspector. The process is the same for Simulator as it is for a real iOS device that’s plugged in.
That process is this: in iOS Safari, turn on Settings > Safari > Advanced > Web Inspector.
Then, open macOS Safari and go to Develop > Your Device Name (or ‘Simulator’) and select the tab you want to inspect
Boom:
For more details see Safari’s Web Inspector docs.
If you want to test UC or some other browser, I’m pretty sure you need a real device. At least, I couldn’t work out how to do it in Simulator.

Android on macOS and Windows

For your benefit, dear reader, I have installed Google’s Android Studio to take a peek at it’s built in emulator. It was dead simple to install and the emulator is fast (~20 second startup). It’s several gigs though, so don’t do this if you’re on a metered connection. Or in North Korea.
Genymotion is also a popular emulator for Android; I’ve heard good things about Bluestacks too. And when I say “popular” and “heard good things” I mean “I’ve got no idea I just googled android emulator for macos and glanced at the first result”.
I happen to have an Android phone, so I use that for testing, and fall back to BrowserStack for testing on other Android devices.
Just like with iOS running in the Simulator, if you want to install some other browser, you’ll need a physical device (although you can drag an .apk into the Android emulator to install an app if you have one lying around).
Obviously if you want to test Samsung Internet you’ll need a Samsung device.

DevTools for Chrome on Android (macOS and Windows)

Connect your Android device via USB and have your site open on the phone.
Open macOS/Windows Chrome, open the DevTools.
Click the snowman buttons (is that what they’re called? Can we make that what they’re called?) and select More tools > Remote devices.
You are now faced with the visual assault that is the ‘Remote devices’ tab.
Hey, what’s that Terminal tab?
Click on Inspect, I have faith that you can work it out from there; anything specific I write will be out of date in 6 week’s’ time.
(Grammar tip: if you don’t know where to put an apostrophe, use a “superposition apostrophe” — it appears in both places at once.)
If you get stuck connecting to your device, go check out Chrome’s docs on the matter. They must update those docs every few weeks, hat tip to whoever’s in charge there.
The “Remote devices” functionality works exactly the same for plugged in devices and emulators. Here’s an Android emulator in Windows being inspected with the Chrome DevTools:
Garfield comics get real deep when you remove Garfield
Alrighty alligator, if you’re a Mac user you’ve got a pretty decent suite of browsers at your fingertips now, all with their own dev tools.
However, you’re still missing different versions of macOS, iOS, and Safari, and a slew of Android devices. And poor, unadventurous, Windows users, you still need to get some Apple in your life.
Let’s talk about …

Filling the gaps with BrowserStack

I put off paying for BrowserStack for a long time. And I still question if I should keep up my monthly payments every time the bill arrives. But I simply need to remind myself: BrowserStack enables me to produce higher quality results, and increase my understanding of browser quirks.
Plus, ever since I became a hermit I’m saving a fortune on shoes, so I just pay for it out of my footwear budget. (Side note, how is it that I still feel like an outsider, even though I never go outside?)
In case you’re thinking this post is paid for by BrowserStack I will proceed to tell you that it is painfully laggy (about a 1 second delay on every click). I don’t think the human brain can withstand a 1 second delay on every action it performs for sustained periods.
As an experiment, I used it for two days straight and now I’ve lost the ability to empty a dishwasher.
Stupid neuroplasticity.
(Yes, I should be grateful that I have a dishwasher, even though it’s now just a plate jail.)
So … BrowserStack is not something that you can use to test how your site ‘feels’ on a Galaxy S6 or iPad 4. But to check that your site works in browser x, y or z, it is the perfect tool for the job.
There’s a free trial, it’s free for open source with a shoutout, and their website probably has a page with pricing details.
I use it in three ways.
Hey, I should describe those three ways!

#1 During development

When I’ve finished with some particular task (after testing on all the browsers I have available locally) I’ll check out a few of the major devices not covered. This is based on my site’s analytics and is usually the Samsung phones and IE6 on XP for the lulz.
Here’s a blow-by-blow of a typical session (after installing the extension, with real times):
  • Open my site in Chrome (yep even localhost)
  • Click the buttonClick IE9 in Windows 7
  • 18 seconds later I’m looking at IE9 in a Windows VM (18 seconds! I know websites that take longer than 18 seconds to load)
  • Do some testing then: Switch > Samsung Galaxy S7
  • 16 seconds later the phone is there with my site loaded in Chrome
  • Do some testing then: Switch > iPad Air 2
  • 32 seconds later a real iPad is there with my site in Safari 8Do some testing then: Switch > iPhone 6s
  • 13 seconds later a real iPhone … you get the idea
I should probably make it clear that I changed the icon for the Galaxy S7 to a toasty fireplace, not BrowserStack. Why yes, yes I do have too much.

#2 Sanity check

Screenshots is a neato feature that also works for localhost, I must learn how they do this one day. It has one big letdown though — they appear to have stopped updating the devices. The newest iOS version is 8.3.
C’mon BrowserStack, chop chop.
For testing older browsers though it’s still an incredible time-saver. There’s no reason that you shouldn’t be running a set of 25 screenshots for every change you make and attaching them to your pull request. Or whatever.

#3 When learning

Recently, I was working out how to make a pie chart. So, I took it out into jsbin, got my head around the best way to do it, then transplanted it into the site I was working on.
When working this way, it is trivial to get a share URL from jsbin …
… and paste that into Browserstack’s screenshot machine, which will go and render the page in a bunch of different devices.
Oops, these are not all the same. Luckily I have IE11 and iOS — with dev tools, right here on my machine.
[tinker tinker tinker]
XP can suck a bag of lollipops
All this without having to go and test in 19 different browsers. This is such a colossal saving of time it’s irresponsible not to be using it. If you don’t have a QA department, you should have this. If you do, they should have this.
OK that’s enough of the BrowserStack love fest, they haven’t even bought me dinner. I feel like I should go and see who their competitors are and give them a shot …

Sauce Labs

Just like BrowserStack, there’s a free trial, it’s free for open source, and their website probably has a page with pricing details.
Other than that, I don’t have anything positive to say about Sauce Labs.
I only gave it 20 minutes, so if I’m wrong on any of this please let me know and I’ll update it.
Also it’s worth noting that I didn’t try any of the automation features — I get the impression that this is their focus. If you want automation, check it out for yourself and don’t be put off by the below.
Here was my experience:
  • Started a ‘manual test’ and opened an Android device (emulated — there doesn’t seem to be any real devices)
  • 1 minutes 29 seconds later the phone opened.
  • The lag is about the same as BrowserStack — 1 second.
  • I got distracted and somehow found myself reading about the disputed zone between Venezuela and Guyana. They’re trying to resolve it peacefully thank God.
  • Came back to an error “Your test errored. Test exceeded maximum duration after 660 seconds”.
    (Turns out that’s not 660 seconds of idle, that’s 660 seconds total before you get booted. I might be just a limitation of the trial.)
  • Opened up a Simulated iPhone 7 — oh I can have two simulations at once, that’s nice.
  • 3 minutes and 35 seconds later the simulator opened — I wonder if those 215 seconds count towards my 660 seconds before I get kicked out?
  • Although it’s in Simulator, it’s not in a normal macOS instance, so I can’t open Safari to get the devtools. That’s a dealbreaker.

Conclusion

There isn’t really a ‘conclusion’, I just didn’t want to end on the low note of not having anything nice to say about Sauce Labs. Mother always said “if you don’t have anything nice to say, make it funny”, but I fear I wasn’t even that.
Oh I’ve got something! I like that “Sauce Labs” is two words with a space between them and a capital letter at the start of each one. A shining example to all budding startups.
And on that high note, goodbye!

Tags

More by David Gilbertson

React
Javascript
Javascript
Javascript
Javascript
Trading
React
Hackernoon Top Story
Hackernoon Top Story
Javascript
React
Javascript
Blockchain
Blockchain
Bitcoin
Blockchain
Javascript
Bitcoin
Bitcoin
Javascript
Bitcoin
Bitcoin
Ipfs
Blockchain
Bitcoin
Blockchain
Bitcoin
Bitcoin
Trading
Trading
Trading
Bitcoin
Trading
Security
Javascript
Javascript
Javascript
Javascript
Recruiting
Javascript
React
Javascript
Github
Accessibility
Javascript
Web Development
Git
Javascript
Typography
Css
Machine Learning
Css
React
Css
Javascript
Javascript
Svg
React
Javascript
React
Nodejs
Javascript
Web Development
Javascript
Git
Testing
Css
Javascript
Javascript
Design
Javascript
Javascript
Topics of interest