I recently stumbled across what I think is a little bug which might be caused by a misreading of the SVG Animation specification. Here you should see two overlapping circles gradually appear:

If you're on Chrome, you might only see one circle animate. Why? Bloody semicolons! The bane of every programmer's existence².

The specification for SVG Animation has this text for human readers:

keyTimes

A semicolon-separated list of time values used to control the pacing of the animation. Each time in the list corresponds to a value in the ‘values’ attribute list, and defines when the value is used in the animation function.

[…]

If the last semicolon separator is followed by either just white space or no more characters, ignore both the separator and the trailing white space.

To me, that isn't ambiguous. The text keyTimes="0; 1;" has a final semicolon with nothing after it. Therefore it should be ignored. Instead, Chrome throws an hissyfit and says Error: <animate> attribute keyTimes: Invalid value, "0; 1;".

But maybe the humans who wrote the description were sloppy. There's also a machine-readable formal specification. It defines the acceptable sequence as being:

<number> [; <number>]* ;?

This isn't quite Backus–Naur form³, but rather CSS Values.

• The <number> is a component.
• The [ and ] are grouping combinators.
• The * and ? are component multipliers
  • * "indicates that the preceding type, word, or group occurs zero or more times."
  • ? "indicates that the preceding type, word, or group is optional (occurs zero or one times)."
• The ; is just a semicolon⁴.

Reading the definition tells us that a valid value will be a number, followed by zero-or-more groups of "semicolon and another number" with an optional final semicolon.

So, based on my reading, I think Chrome is wrong to throw an error here. Both Firefox and Safari work with a trailing semicolon.

Accordingly, I've raised a bug with the Chromium team. If you think I have erred in this matter, please let me know.

What's causing this?

Try opening this link to a window size detector in a background tab. Then visit that tab.

On Chrome, this is what I see.

If I hit the refresh button on that tab, the Outer window size snaps back:

What's going on?

According to the specification:

The outerWidth attribute must return the width of the client window. If there is no client window this attribute must return zero.

This is where I get confused. The inner width & height are the amount of space the the browser has to display web content - so ignores the browser bar, menu bars, window decorations etc. The outer width & height are the total amount of space the browser window has.

How can a browser window have no outer size, but simultaneously have an inner size???!?!

There is a client window. The tab may be rendering away in the background - but its parent still has a non-zero size.

There has been a bug report open on Chrome about this since 2017.

Firefox takes a different approach. On desktop, both outer and inner are reported correctly for background tabs. On mobile, both outer and inner dimensions are set to zero. This may change as it is a potential fingerprinting target.

So, web developers, please don't rely on window.innerHeight and window.outerHeight - users may be opening your site in the background, which causes the browser to lie to you.

"Harry ‮".draziw a si ‭Potter

Now, try to select the text and see what happens.

WHAT WITCHCRAFT IS THIS?!

If you examine the source code for this page, you'll see that I'm using the Unicode Bi-Directional characters.

"Harry ‮".draziw a si ‭Potter

These characters are useful when writing text that includes, say, English and Arabic - but they can also be used for malicious purposes.

On a more mundane level, they can cause all sorts of UI bugs. I've just filed a bug against the Chrome browser for how it handles these characters.

If you right click on text with mixed direction, you'll notice that the UI behaves oddly.

In Firefox, the behaviour is correct - although one could argue whether "Potter" ought to be reversed.

Searching

So, what happens when we run these searches?

Neither Firefox nor Chrome do particularly well. I'm not sure if the reversed text in the window title and URL bar are bugs in Ubuntu - or whether it's the fault of the app itself.

On Windows and Mac, we see this happen:

This would suggest that Google isn't correcting the direction of the text and that is deforming its own title tags.

Are These Bugs?

Ok, so having the title reversed isn't the worst problem in the world. But do these examples count as bugs and, if so, who is responsible for them?

Every search engine I tried passed through the right-to-left-over-ride unscathed - so that's the fault of the search engine, right? How the hell do you a report a bug to Google?

The title bar could either be a problem with the browser - Firefox has a bug report over a year old on the issue - or the problem could be with the underlying operating system. How would one find out?

Thanks

Thanks to Yuan Phoon for asking the questions which prompted this discovery.

At the moment, Chrome (and other Android browsers) ask for permission before accessing features such as geo-location, camera, address book etc. This is a security measure to prevent your private information leaving your hands without your knowledge.

At the moment, accessing the HTML5 Vibrate API doesn't trigger an on-screen warning. Its use is seen as pretty innocuous. Because, realistically, the worst it can do is prematurely drain your battery. Right?

I'm not so sure.

Evil Thoughts

We've all seen those scummy adverts designed to look like Windows pop-ups. They usually pose as a legitimate system request - "Update Java" or similar.

Suppose a malicious web page pops up a fake system notification and vibrates at the same time. How confident would you be of telling the difference between a legitimate pop-up and a .png on the web page you're viewing. After all, the phone buzzed - so it must be genuine.

Are you really receiving an "AirDrop" - or is this page trying to trick you?

Autoplaying sound on adverts in annoying - auto-vibration could be just as irritating. Imagine searching through tabs until you found the single advert which was pulsing away trying to get you to buy new insurance.

For now, the intensity of the vibration cannot be controlled - only the duration. It is not impossible to conceive of malicious code being able to exploit an unpatched browser flaw and overdrive the motor to destruction.

Faking Telephone Calls

When combined with HTML5 Audio, it would be possible to create a fairly realistic "Incoming Call" screen which vibrated and played a ringtone. Once "answered", the page could play some audio which says "Hi, can you call me back urgently - my number is [premium rate line]" and then, perhaps, automatically open up the dialer using the tel: URI. Could you tell if the above was a real phone call? If you looked closely, probably, but when the browser is playing your phone's default ringtone and the handset is vibrating, it would be pretty easy to be confused. Combine it with a WebRTC call and you're looking at a very convincing scam.

Video Demo

Source Code

Here's a basic example which you can try on your own phone - demo site.

<body>
   <script type="text/javascript">
      navigator.vibrate = navigator.vibrate || navigator.webkitVibrate || navigator.mozVibrate || navigator.msVibrate;
      navigator.vibrate([1000, 500, 1000, 500, 1000, 500, 1000, 500, 1000, 500, 1000, 500, 1000, 500]);
   </script>
   <img width="100%" src="phone.png" onclick="window.location.href='tel:09098790815';" />
   <audio autoplay="autoplay">
      <source src="ring.mp3" />
   </audio>
</body>

At the moment, the auto-vibrate and auto-ring only work on Firefox for Android. But no doubt other browsers will follow suite soon.

Warnings

Firefox was the only browser I found which supported Vibrate - on Android, neither Samsung's browser, Chrome, or Opera did - iPhone also doesn't yet support it. No one cares about Windows Phone or BlackBerry - so I didn't test them*.

Firefox doesn't currently ask for permission when a page requests access to vibrate.

Do you think browsers should warn before a page vibrates - or is the risk too low? I guess we'll have to see if the scammers take advantage of it - and whether there is a user backlash.

*Update: thanks to the comments on Reddit and on HackerNews it would appear that BB10 does support the vibrate API, Windows Phone doesn't.

When scrolling, I notice that the font hinting seems to break down. This makes the text very "juddery". It looks like the fonts shrink and grow and they scroll. This is very disorienting when reading.

In this example I've noticed that once I've stopped scrolled the page, the fonts are hinted differently.

I've enlarged the examples (without interpolation) so you can see them a bit more clearly.

To give you a good idea of what's happening, I've magnified the letter "e" (again, without interpolation). You can quite clearly see what happens to the font.

I can understand why the font hinting changes as the scrolling occurs - but why does it change even after scrolling has finished?

All screenshots taken on an N7100 running 4.1.2 with the latest version of Chrome for Android. The Galaxy Note II has a fairly standard resoltion of 1280×720, giving it 267 PPI - that shouldn't cause any problems.

This issue has been reported to the Chromium team.