Compatibility/CommonIssues

Web Compatibility issues change over time. Bugs that were common in 2005 are not often seen in the present. This list represents the most common issues currently being discovered by the webcompat community and will be updated as these change in the future.

WebKit Flexbox Total Armaggedon in China and Japan

This is not specific to Desktop and Mobile, but more to the specific markets of China and Japan and indeed more often on mobile.

Suggested Fix Use Web standards flexbox properties in addition to the WebKit ones if old devices compatibility is required.

Related Bugs

• https://webcompat.com/issues?page=1&per_page=50&state=open&stage=all&sort=created&direction=desc&q=%22country%3A+jp%22

Click-or-touch

Many sites have code that detects touch support and assumes mouse input can be ignored. These sites behave oddly on all computers that have a touch screen AND a mouse - usually not responding as expected to mouse input.

Suggested Fix Write JavaScript that will handle both click and touch input, not either-or.

Related Bugs

• https://webcompat.com/issues/1889
• https://webcompat.com/issues/2453

Max-width

(Fixed in Gecko) Basically an image with a max-width: 100% was bigger than the viewport It was an issue, created by a different behavior in Gecko and Blink. But the market share of Blink imposed the unspecc’ed behavior of Blink.

Suggested Fix The fix was often a combination of display: table with table-layout: fixed. This is now fixed in Gecko and the spec, but this is a good illustration point in terms of Web Compatbility issues.

Related Bugs

• https://bugzilla.mozilla.org/show_bug.cgi?id=823483

Video streaming using Apple’s proprietary HTTP Live Streaming

Firefox doesn’t support this on Desktop or Mobile.

Suggested Fix Not a trivial thing to fix. Ensure that there is a fallback mechanism for browsers that don’t support HLS (currently on Desktop, only Edge and Safari do).

Related Bugs

• https://bugzilla.mozilla.org/show_bug.cgi?id=941351

Meta viewport fixed size

Very similar to the max-width bug. This is a different of behavior in between blink and Gecko. Basically with a fix width, Gecko on Mobile doesn’t necessary resize the page to fit in the screen.

Suggested Fix Use width=device-width instead of fixed size.

Related Bugs

• https://bugzilla.mozilla.org/show_bug.cgi?id=617034

Faulty UA detection

Sites sniff the user agent string, often to figure out if you’re using a “supported browser”. This goes wrong all the time, because of an unknown UA string, or parsing bugs, or not understanding versions greater than 9, etc. Mobile browsers will frequently end up on “Desktop” sites, rather than mobile ones as a result of this kind of bug.

Suggested Fix Update your UA detection library or framework, or use feature detection rather than relying on User Agent string parsing. User Agent detection is about detecting the past. So it will obviously fail. Feature detection is about inspecting the now.

Related Bugs

• https://bugzilla.mozilla.org/show_bug.cgi?id=1267084

Relying on global event object

WebKit (possibly copied from old iE?) has a non-standard global event object. When sites don’t pass in the event object to an event handler, we end up with exceptions like “ReferenceError: event is not defined”

Suggested Fix Use web standards and pass in an explicit event object into your event handlers. For example: a.addEventListener(‘click’, function(e){ blah(e)});

Related Bugs

• https://bugzilla.mozilla.org/show_bug.cgi?id=804710
• https://github.com/webcompat/web-bugs/issues/2392#issuecomment-208477618

HTTP Ping Pong

The company has two different sites: desktop and mobile with different domain names. They do user-agent sniffing be with HTTP user-agent header, through JavaScript.

Suggested Fix The issue starts to fix itself by people switching to responsive Web sites. The fix is actually simple. Which ever technique you are using should have a consistent policy in terms of user agent sniffing. Some websites make mistakes when the detection mechanism is not the same on both domains: for example one with HTTP, and one with JS. In HTTP only, the browser is able to identify the infinite loop and will stop after 10 iterations, but when switching from HTTP to JS and then to HTTP, etc the browser is really caught forever.

Related Bugs

• https://webcompat.com/issues/1961
• https://webcompat.com/issues/797
• https://bugzilla.mozilla.org/show_bug.cgi?id=931849

Webkit Scrollbar

Websites would like to replace default scrollbars with custom ones. There are known issue of Firefox not hiding the default scrollbar and potential scrollbar lagging introduced with async scrolling (e10s-only).

Related Bugs https://github.com/webcompat/web-bugs/issues/2767 https://github.com/webcompat/web-bugs/issues/4423 https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%20%5Bwebkit-scrollbar%5D&list_id=13411089 https://github.com/whatwg/compat/issues/61