Micro Focus is now part of OpenText. Learn more >

You are here

You are here

What software testers need to know about browser differences

public://pictures/Christopher-Null-CEO-Null-Media.png
Christopher Null Freelance writer
 

Browser testing can be a pain for the most seasoned testers, but it's particularly challenging for newbies.

"In today's world, an application behaves differently in different browsers, in different resolutions, and sometimes in different operating systems," said Dror Saaroni, R&D group manager at Micro Focus. "A tester should make sure he covers all of these dimensions."

If the sheer volume of usage scenarios to be addressed isn't daunting enough, testing is further complicated by the fact that during the development phase, most developers use a single browser as common practice, even if they have multiple browsers installed, said Surbir Singh, associate QA director at QASource. "That leads to issues across all the other browsers."

To give new testers a running start, we asked several testing experts to shed light on key differences among the four major browsers, as well as common issues testers may face in each and how to remedy them. Here are their answers.

Apple Safari

This proprietary browser is included on all of Apple's computers and mobile devices, but the mobile and desktop versions behave quite differently from one another, said Mike Johnson, a front-end developer at Unearth Technologies. In some cases, that's simply because iPhones and iPads use touch instead of mouse interaction. But the mobile version of Safari is also optimized to reduce load on iPhones' and iPads' smaller CPUs.

The upshot is that testers should treat mobile and desktop Safari as entirely different browsers.

Safari emphasizes security, with built-in features such as anti-phishing protection and a JavaScript toggle. However, one security measure often gets mistaken for a bug: Safari strips metadata out of files uploaded via the browser. For example, GPS coordinates will be removed from photos uploaded through Safari. This is intended to be a privacy feature, Johnson says, so there is no "fix," but those missing coordinates can sometimes be replaced using the web’s geolocation API.

Another common problem encountered on the mobile version of Safari is that event bubbling doesn't work on elements that don't have a cursor style set via CSS. This means that in some cases nothing will happen when a user clicks on an element that was supposed to be interactive.

To fix this, Johnson said, any element that you expect to propagate a mouse event must either have the event listener declared directly on the element—as opposed to a child—or have the CSS cursor value set, "which is rather egregious given that cursors aren't rendered on mobile iOS at all," he notes.

Another issue in mobile Safari involves elements that use the CSS position: Fixed-rule elements within a scrollable container are often buggy. Fixed elements are those that remain "stuck" to a position on the screen regardless of scroll or zoom position, Johnson explained. "They either won't remain fixed, or flash or judder during scrolling, or come unfixed when focused, particularly when the focused element is an input."

The CSS rule of -webkit-overflow-scrolling: touch is a good starting place to remedy this, he said, but usually these issues will require reworking both HTML and CSS to find a solution that fits the design.

It's also important to remember that Safari isn't the only browser users can run on their iPhones and iPads (though many developers treat it as if it were) and testing should reflect this.

Google Chrome

Chrome leads the market in terms of developer tools, said Eran Kinsbruner, mobile technical evangelist for Perfecto and author of the e-book 10 Test Automation Frameworks for Cross Browser Testing. There's a good reason for that: Google's popular browser includes a wide range of debugging and testing tools for auditing, network capture, performance, object spy, and more. Two particularly underutilized ones, Unearth's Johnson said, are the memory profiling and network throttling tools, which allow you to inspect your application's memory usage and test it under controlled poor network conditions.

Chrome also leads the pack when it comes to implementing standards and shipping new APIs. In addition, it has a headless option, which removes the user interface and lets you run the browser from the command line, making it easy to run unit tests against Chrome with a test runner such as Karma.

Chrome recently changed the behavior of page reloads to improve speed, particularly on mobile devices operating under poor network conditions. As a result, testers may see an increase in occurrences of cached resources being out of date.

"Specifically, Chrome only revalidates the main resource during a page reload, and no longer checks whether cached sub-resources are expired," Johnson said. "It can result in issues such as icons, fonts, images, and other static files appearing not to have changed after a deployment." He recommended that testers use explicit cache-busting methods such as timestamp URL parameters or hashed filenames instead of relying on headers to control caching.

Testers may also encounter image orientation issues: Embedded images that appear right-side up in other browsers such as Firefox and Safari may display sideways or upside down in Chrome. Rather than being caused by a bug, this typically happens when a photo's EXIF orientation and actual orientation don't agree and has to do with how Chrome interprets the ambiguous information. 

Johnson recommended running photos through a server-side processing step that ensures that the actual orientation matches the EXIF orientation and rotates the photo if it doesn't.

Mozilla Firefox

Firefox became popular with developers five to 10 years ago because Firebug was the best browser debugging tool available at the time, Johnson said. It's still a reliable browser with a deep catalog of extensions and user interface customizations, but its developer tools and rendering speed have been surpassed by Chrome.

This year, Firefox was rewritten to use a multi-process architecture that should address some of its growing performance issues.

Firefox does a good job of adhering to specifications and avoiding flagrant bugs, Johnson said. More often, problems come from slight layout inconsistencies resulting from differences in CSS implementations between the browsers. He notes that, because Firefox is built on the Gecko rendering engine rather than the webkit or webkit-derived engines used by most other browsers, you may find that text line heights appear slightly different and form inputs have different dimensions, occasionally resulting in layout breaks.

Usually, a CSS value simply needs to be adjusted slightly so as not to cause a break. When a value can't be found that works for all browsers, you might need to restructure your HTML to find a different way of implementing that feature.

But Firefox's biggest issue over the last few years has been performance. It has a tendency to run slowly, provide laggy interactions, and cause CPU usage to spike, particularly when several tabs are open. The problem is pervasive enough that Mozilla has even published a workaround guide for users.

The jury is still out on just how successful the browser's recent changes will prove to be. Regardless, CPU usage and memory footprint tests should be run regularly. QASource's Singh added that testers should pay particular attention to the performance impact of add-ons and suggested installing an extension such as Tab Data to keep an eye on memory allocation.

Microsoft Internet Explorer/Edge

"The first thing any tester should know about Internet Explorer is that IE and Edge are completely different browsers," Johnson said. Microsoft Edge, he noted, auto-updates and thus is the fourth of the "modern" browsers, while the final version of Internet Explorer, IE11, is the only version of that browser still supported by Microsoft.

That said, IE is actually the easiest browser for developers to target in their code. Using conditional comments in HTML, developers can run JavaScript and CSS that will reach only specific versions of IE. That's sometimes impossible—but also almost never necessary—to do for modern browsers.

A common frustration for developers and testers is when websites don't render in IE and Edge as they're expected to. Images don’t display, text is broken or jumbled, or pages can be completely blank. Styles for elements such as these are up to browser vendors to implement. The Microsoft browsers' implementation is significantly different from other browsers' and can be much more challenging to override—though that doesn't stop developers from trying.

Johnson offered the CSS appearance: none rule as a starting point for customizing the appearance of inputs. "Sometimes it is easiest to hide the native input and use custom elements to delegate user interactions to the hidden element," he said. "Other times the only way to meet the design criteria is to build a custom input manually."

Singh added that long-running scripts are detected differently by different browsers and may execute exceptionally slowly in IE. "The best way to avoid these problems is by reducing looping, recursion, and DOM [document object model] manipulation," he said. "Always use CSS and ID for locating the locators, and it will load the page faster."

The bigger picture on browsers

While the unique technical attributes and peccadilloes of each browser are important for new testers to keep in mind, Johnson cautioned that DOM specifications are constantly evolving, and new browser versions are released regularly.

"This is what keeps web technology progressing, but it's also what causes the various browser vendors to take slightly different approaches to the thousands of problems they have to solve," he said. "There can never be a canonical list of unchanging differences between browsers or bugs that you are guaranteed to find in one browser and not another."

A site that works perfectly today may suffer a debilitating bug after a browser update is released tomorrow. It helps to know which general categories of interactions or layouts tend to be problematic, but, Johnson explained:

"Browser testing is as much a process of testing the latest browser updates themselves as it is about testing your application."

Keep learning

Read more articles about: App Dev & TestingTesting