Mobile Safari not rendering HTML5 app correctly

In the past, web developers bemoaned having to implement workarounds and hacks to deal with older versions of Internet Explorer.

Lately we’ve experienced a spate of problems with Safari on iOS devices. A quick search turns up that Safari on iOS 7 is the buggiest Safari version since 1.0. Although I didn’t discover the particular issue and solution discussed here, this is something our team has been struggling with for a few days and the solution is strange.

A mobile web application, which works fine on Chrome on Android, was having strange rendering issues on Safari on iOS devices. In particular, the page would arbitrarily partial render and stop. However, “bumping” (scrolling the status bar, or any other small scroll attempt) would complete the rendering. The rendering would freeze in different places and at different times, but bumping would always resolve the issue.

A lot of searches turned up fruitless and the issue was very frustrating. The main developer on the project discovered there was an issue with refresh on iOS 7 related to the size of the page. We tried hacks like those described on the lazy repaint page, to no avail.

Finally, the developer determined that while the page was loading, the changing of DOM elements was causing the page to attempt to scroll, which disrupted the rendering of DOM elements. Apparently, the “bumping” interrupted that process and allowed the render to complete (not exactly sure how that worked though).

For some reason, setting the viewport of the page resolved the issue. Note that setting only the width causes the app to work fine in landscape mode but not portrait mode.

<meta name="viewport" content="width=device-width, height=device-height">

I’m sure there’s a better explanation, but for now, we’re writing this as a weird Safari iOS 7 mystery bug.

Using TRY_CONVERT in SQL Server 2012+ to migrate from varchar fields to strongly-typed fields

We have a SQL 2008 database which has some varchar fields used to store times. I wanted to migrate them to use actual time fields, but the format entered into the varchar field had been inconsistent (as previously, there was no validation on the field). In addition to properly formatted times, some entries used . instead : (for example, 12.38), some entries had am/pm (or just a/p) on the end, some didn’t. A simple convert(time, …) would not suffice.

One way to approach is to TRY_CONVERT (new in SQL 2012: converts if able, returns null otherwise) and chain them with COALESCE in order to try multiple formats for a single field.

Consider the following example, assuming field is the source varchar field and convertedField is the new time-typed field.

UPDATE tableName SET
  convertedField = COALESCE(
   TRY_CONVERT(time, field),
   TRY_CONVERT(time, REPLACE(field, '.', ':')),
   TRY_CONVERT(time, REPLACE(field, 'a', ''),
   ...
)	  

Two other things to consider with a conversion of this type:

  1. Users may mix 12 and 24 hour time standards. In this case, we had entries like 13:30 (clear) and 1:30 that were used to reflect the same time. Some additional logic and testing is needed to attempt to “smart migrate” afternoon times that are not marked with pm and are in 12-hour format.
  2. If the database is being imported from SQL 2008, you need to upgrade the compatibility level to gain access to 2012 features:
    ALTER DATABASE DatabaseName
    SET COMPATIBILITY_LEVEL = 110;