Testing an iOS browser using Safari on Desktop

Prerequisites

• Safari v7+ or greater is required to debug on iOS8 - NOTE: At time of writing, this is the current iOS iteration.
• Safari v6 is required to debug on < iOS8. (Example: iOS7/6/5).

Steps

• On your mobile device goto "Settings" > "Safari" > "Advanced" and enable "Web Inspector".
• Plug your device into your development machine via. USB
• Ensure you have the "Develop" menu option enabled in Safari on your desktop. If not, from Safari on your desktop. "Preferences" > "Advanced" > "Show Develop Menu".
• With your device now plugged in you should see: [Your Device Name] iPhone|iPad (Example: "Tony's iPhone") appear in the "Develop" menu. Selecting this menu item will then show you all of the browser tabs you have open in Safari on your mobile device. Similarly to Android; you will then be able to use the Developer Tools on your desktop to debug the browser on your mobile device.

Testing a Droid browser using Chrome on Desktop

Prerequisites

• Both the device and your development machine must have a newer version of Chrome on them (v32 or greater). In the case of mobile devices, access the Google Play (App Store) and download the latest version of Chrome.

Steps

• On the mobile device goto "Settings" > "About Device" > "Developer Options". (If Developer Options isn't enabled, find "Build Number" and tap 7 times (not kidding!), you will see an option to enabled "Developer Options").
• In Developer Options select "Enable USB Debugging"
• Plug your device into your development machine via. USBFrom your development machine, in the URL bar of Chrome type "chrome://inspect/" > And then choose "Devices".
• You should then see a list of all the browser tabs open on the mobile device from your desktop. You can then use the Developer Tools in your desktop browser to control and get debug information about the browser on your mobile device!

Further Reading:

• Reference Article - http://www.smashingmagazine.com/2014/09/03/testing-mobile-emulators-simulators-remote-debugging/2/
• Apple Specifics - https://developer.apple.com/safari/tools/
• Android Specifics - https://developer.chrome.com/devtools/docs/remote-debugging

I'd imagine a somewhat wide applause echoed from the front-end community when Microsoft announced in Jan 2015 that they were working on a ground-up new browser codenamed Spartan.

Over years Internet Explorer has developed a stigma amongst front-end developers. Microsoft made some attempts in IE10 and IE11 to align itself with already adopted W3C standards but decades of slow decay from wider internet standards contributed to the browsers lack of adoption amongst a rapidly evolving, standards compliant set of Webkit/standards based browsers.

Perhaps, the best news for me is the decision to use the Webkit engine. In some respects it's not the browser necessarily that limits front-end development, but the rendering engine. Spartan now joins the likes of Chrome and Safari in adopting Webkit. To be honest, all browsers should just adopt Webkit so more focus can be applied to generating amazing new content rather than working on x-browser compatibility issues.

As part of the B2G (Boot 2 Gecko) or, as it's more commonly known, FirefoxOS project (Mozilla is creating an HTML5 operating system), they have created the pdf.js library.

pdf.js is an HTML5 technology experiment that explores building a faithful and efficient Portable Document Format (PDF) renderer without native code assistance.

pdf.js is community-driven and supported by Mozilla Labs. Our goal is to create a general-purpose, web standards-based platform for parsing and rendering PDFs, and eventually release a PDF reader extension powered by pdf.js. Integration with Firefox is a possibility if the experiment proves successful.

- https://mozillalabs.com/en-US/pdfjs/

So, you may have been wondering why PDF's viewed in Firefox are no longer using Adobe Acrobat reader, and, on occasion may not be faithfully recreating the artwork originally saved.

A quick check in (address bar) about:config will reveal a (boolean) pdfjs.disabled value. By default this is false.

If you want to revert to the more traditional Adobe Acrobat viewer then you can set this flag to true.

You can set the pdfjs.disabled pref to true on the about:config page to disable the build-in PDF viewer and use the Adobe Reader instead.

- https://support.mozilla.org/en-US/questions/950988

It also turns out there is support for this in other major browsers such as IE9+, Chrome/Chromium, and (albeit rather buggy) in Safari.

If you're having issues with PDF's not rendering correctly in the browser just have a quick look for pdf.js and maybe revert back to the native Adobe Acrobat PDF viewer.