w3c/mobile-checker

The Mobile Checker is a tool for Web developers who want to make their Web page or Web app work better on mobile devices.

The Mobile Checker is a tool for Web developers who want to make their Web page or Web app work better on mobile devices.

The Mobile Checker was built to provide all of us web developers with a new and helpful experience of mobile Web developement. We built the base. Now join us, and make it grant your wishes. We hope you will make it awesome.

How does it work?

This tool is a full JavaScript Web application built with Node.js and Selenium WebDriver. Based on the mobile Web browser emulator API, the Mobile Checker combines powerful technologies to simulate a Web browser on a mobile device. That's why, contrary to most of the current online mobile emulators, the Mobile Checker can provide an emulation close to what your Web app looks like on different kinds of mobile devices, including tablets and smartphones.

Installation

Mobile Checker is a Node application. It will eventually be distributed through npm, but in the meantime you can simply clone this repository:

git clone https://github.com/w3c/Mobile-Checker.git

1. Install Node.js

2. Install npm dependencies:

   npm install -d
   

3. In addition to the npm dependencies, install:

• Google Chrome
• browsermob-proxy running on port 8080
• ImageMagick
• XVFB

Running

In your terminal, run:

node app.js

Then, connect on the localhost:3000 port.

Testing

Testing is done using mocha. Simply run:

mocha --timeout 30000

from the root and you will be running the test suite. Mocha can be installed with:

npm install -g mocha

Feedback and contributions

• Send feedback about the tool and join us on the mailing list.
• Discuss about the Mobile Checker in our Gitter room.
• Report a bug and open an issue on Github.
• Send a feature request on Github.
• Contribute to the Mobile Checker by first reading the contribution guidelines.

mobile-checker's Issues

websites & app which generate bugs or invalid issues

• http://www.canalplus.fr/c-cinema/c-les-films-en-salles/cid354533-carlos-le-film.html (prefixed css test)

use http/https get() of node js to get resources of webpages

see https://github.com/guibbs/onepagecatcher

separate lines in source files

review check issues

review required on issues delivered by the mobile checker. (spelling, grammar...)

devicePixelRatio

Although the devices we target have all a devicePixelRatio > 1 (i.e. have more then one screen pixel per css pixel), the current mobile emulator doesn't reflect this. In particular:

• it doesn't set window.devicePixelRatio to the right value
• it doesn't react to the min-device-pixel-ratio media query

We need to fix that; it looks like there would be a simple solution for Firefox; chrome allows to emulate this in its developer tools, so there must be a way there too, but I'm not sure how yet.

mobile checker display on mobile devices

• remove animation
• clean design, elements size ...
• fix issues generate by mobile checker himself (css prefixes)

Detect and explain opportunity for reduced network usage

One of the primary UX improvements for mobile devices is reducing the usage of network, both from a latency and bandwidth perspective.

The checker should help identify the places where one can get the biggest gains in terms of network usage. These includes:

• gzip-compressing textual resources (HTML, CSS, SVG, JS)
• combining distinct CSS stylesheets into a single one
• combining distinct JS scripts into a single one
• remove meaningless whitespaces from textual resources
• remove non-rendered content from images (e.g. EXIF metadata from JPEG)
• optimize raster images (e.g. via pngcrush)

Mobile screenshot and device-width not quite right

Right now, when meta viewport set width to device-width, we render the page on a screen set to the size of the device-width and take a screenshot of that same size. While that behavior is correct for initial-scale=1, it's not for device-width where the zoom level is adjusted to the the widest part of the page.

add line number & line content of source file in l10n

CSS prefix improvements

The CSS prefixes detection only works for properties at this time; it should work also for prefixed at-rules and prefixed values.

Also, the detection of inconsistent values need to take into account prefixes (otherwise, it reports buggy inconsistencies).

Maybe we can reuse stuff from https://github.com/postcss/autoprefixer ?

Detect common errors in Web app metadata

Get inspiration from https://github.com/w3c-webmob/installable-webapps/tree/gh-pages/ios_standalone

favicon issue not responsive

The favicon issue is not responsive on a smartphone.

run mobile checker as a web application on smartphones

possible to custom (full-screen, no url field...) and add the Mobile-Checker on the homescreen of our smartphones.
example:
https://developer.chrome.com/multidevice/android/installtohomescreen

Take care of mobile browser viewport

good article (in French) here: http://www.alsacreations.com/article/lire/1490-comprendre-le-viewport-dans-le-web-mobile.html

We don't have to set up just smartphone profile but also mobile browser profiles.

Add links for more info on fixes

E.g. after a message such as "Enable compression on the Web server", show the user a useful resource or two as a next step.

Show progress of checker

Currently there are two spinning cogs but after a while it looks as the though it may have timed out. Would be helpful to see a progress bar or percentage complete.

The Mobile Checker is using a vulnerable version of express

The package.json file indicates that the required express version is 4.4.1. However, express in versions <3.11 || >=4 <4.5 are deemed insecure as per the Node Security Project.

Best would be to require ^4.12.4 (or whatever the current stable version is) after some testing.

Detect when hit targets are too small / too crowded

Given that many mobile devices are now touch-based, it's important that activable areas (links, buttons, etc) be large enough and separated enough that a user can hit them easily.

add data in results via l10n file.

Show severity of issues

For example list issues in order of seriousness, or show a coloured icon (warning, danger, etc.) indicating what is serious, not-ideal-but-acceptable, and so on.

limit number of // checks

add a job manager to limit client number at the same time.

Save results of mobile checker

two options:

• database (like MogoDB)
• files
  second options envisaged because is esier to deploy on server.

doc-width check don't work properly

Detect flash on mobile website

Detect invalid SSL certificates

(since they'll generate horrible error messages, they're most user hostile esp on mobile)

Detect "costly" CSS

Some CSS properties can result in worse performances; the checker should draw attention to this when it detects they're in use.

Part of this issue is to collect with of these properties ought to be warned about; off the top of my head:

• animating properties that can't be GPU optimized (see http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/ )
• drop shadows

page.viewport not declared before page.open

so viewport don't work correctly after #30 for screenshots.

test.js is missing

can't run mocha, it fails with an error about test.js missing

Factor out code to detect network savings

there is quite a bit of overlap in the code between exif.js and compression.js; it could use some refactoring.

Missing test cases

• compatibility/css-prefixes
• compatibility/flash-detection
• interactions/alert
• interactions/touchscreen-target
• responsive/fonts-size

Performance stats

Archive.org have published a number of interesting statistics about average performance of Web pages from a mobile browser: http://mobile.httparchive.org/ e.g. http://mobile.httparchive.org/interesting.php

We discussed yesterday informing the users about how a given Web page fares compared to others in terms of performances, so it might be interesting to look into these stats.

Note that in particular the tests for mobile are conducted using an emulated 3G network; that might be something worth looking into for the checker as well (probably as a separate issue).

Provide hooks for giving contextual guidance

Beyond detecting well-identified errors or opportunities for improvements, it would be really nifty if the checker provided more open-ended guidance to its users when it detects some patterns in the code.

For instance:

• if the code use "large" raster images, it could draw attention to responsive images with the srcset attribute and the picture element
• if the code use ApplicationCache, it could draw attention to service workers
• if the code use "Web app metadata", it could draw attention to the work on the manifest spec

Ideally, this contextual guidance would be easily added and removed from the checker, possibly from a community-maintained repository of hints. I would imagine it as a JSON file that lets one associate with some code patterns a resulting suggested hint.

Detect fonts that are too small for legibility

The size of a displayed font depends on:

• its CSS font-size
• the size of the viewport
• the distance from which the screen is viewed

In principle, the latter two are linked (a device's viewport should be sized to a number of CSS px such that the px takes up a viewing angle of approximately .0213 degrees), but in some cases (e.g. TV sets), they're not correctly set — so maybe there is an additional optional configuration parameter.

Give guidance on mobile forms

Some ideas in https://www.youtube.com/watch?v=iYYHRwLqrKM&utm-source=crdev-tw

Deal with HTTP errors

HTTP errors (e.g. 404, 500) can occur:

• when retrieving the main Web page
• when retrieving resources required by the Web page

The former is obviously a fatal error that needs to be explained to the user.
The latter shouldn't stop the overall check of the page, but the fact that these errors occurred should be highlighted; at the very least, they are useless additional network traffic; and in general, they may be the sign of a bigger issue.

Note that HTTP errors can occur in stylesheets or scripts that are directly linked from the main page, but they may also occur from resources that are themselves invoked from stylesheets or scripts (recursively :)

Filter URLs that can be checked

We need to make sure that the checker can't be used to access URLs that are not available to the outside world (e.g. 127.0.0.1, and others).

The easiest is probably to transpose on the python library we use for this in other services:
http://dev.w3.org/cvsweb/2004/PythonLib-IH/checkremote.py?rev=1.24;content-type=text%2Fplain

Emulate mobile browser in phantomjs

This encompasses at least 2 critical aspects (which might be worth documenting as 2 new issues):

• set the HTTP headers to match the headers sent by a well-known mobile browser (at least the User-Agent header, possibly others such as the "Accept" header)
• make phantomjs interpret the Web page as a mobile browser would; in particular, using the notions of "viewport" that is so far specific to mobile browsers

Both of these would benefit from being imported from "profiles" of virtual browsers that would include the said headers, the dimensions of the underlying device, the dimensions of the viewport, etc.

Detect double-scrolling

One of the first things that qualifies a Web page as not "mobile-friendly" is when you have to scroll horizontally, and zoom on specific sections of the page.

That happens typically when:

• the page doesn't declare a viewport with <meta name="viewport" > (with values such as content="initial-scale=1.0")
• the size of the viewport implied by the said declaration is narrower that (some of) the content of the page

Mixed content

There are mixed content issues when served using https

Not enough contrast for some text

To pass at least WCAG AA, some text seems to need more contrast, e.g. the resolution figures in the device-selector buttons on the front page. There may be more so it would be worth running a contrast checker on all pages.

add 4 "category" in result : What,Why,How

provide a presentation homepage

• gh-pages branch
• content review (by @dontcallmedom)
• host homepage on http://w3c.github.io/Mobile-Checker

simulate 2G/3G/4G connection

Make results available via URL

Even if most the operations are done via WebSockets, it's important that the results of checking a page be available via an URL (à la /?url=http://example.org) — to make it easier to share the results of a check.

In particular, it's important when these URLs are used to ensure that the checker is not calling itself.

change client side to show line number & some code in result

Checker messages

Some open questions with regard to the error messages sent by the checker:

• we should probably have a style guide of some sort; for instance, I don't think we should be using "you" or "your Web page" (the user of the checker may not be the owner of the Web page in the first place); also, it should be clear whether the messages start with a capital letter, finish with a period
• I'm not clear whether we can put markup in the error messages or not
• in many cases, we will want to bind an error message with a specific file, and ideally, a specific line in the said file; the checker should make it easy to do that binding
• the messages we'll be sending have 3 goals:
  ** identify an issue
  ** explain why it is a problem
  ** give guidance on how to fix the problem
  these 3 levels should probably be managed separately (since there are cases where we will want a subset of the 3 levels)
• we had talked about various degrees of errors
• we discussed using a well-known localization framework to make it easier for others to manage or contribute to translations

Detect opportunities for faster first view

A number of things will block the browser from displaying anything when loading a Web page:

• downloading main HTML
• downloading stylesheets
• anytime it encounters a script that is not loaded asynchronously

In addition, some other assets will create unwanted artifacts when loading a Web page; the "flash of unstyled text" (often referred as FOUT) due to downloadable fonts (e.g. WOFF) is probably the most well-known of those.

The checker should (as far as possible) give advices on how to reduce or remove these.

update readme and contribute markdown file

• readme
• contribute

mobile-browser-emulator should only send "end" when all actions have been done

right now, it sends it once it has sent over the 'har' data, but that creates a race condition if one of the 'har' listeners do asynchronous stuff.

We should collect all the promises of on actions on browsers, and only send 'end' when all the promises have been resolved.

bug in mobile-browser-emulator.js with document.clientWidth

On this website http://gbaudusseau.com (which is no-really responsive) width getted don't provide good value to check if we have double scrolling.