ZoomBySite’s Past and Future

I created ZoomBySite to provide the last major feature that was preventing me from switching from Firefox to Safari (as I described in my initial post about ZoomBySite). It has some problems:

  1. Some sites with functionality that is tied closely to exact positioning can break. For example, on some sites, you have to click next to a button rather than on it because the page isn’t looking for a click on the button, it’s looking for a click in the exact coordinates where it expects the button to be, but ZoomBySite has shifted the position of the button.
  2. Some sites reset the zoom level after the page loads. Most sites don’t do this on purpose, but as I found out, a bug in the popular Javascript library JQuery caused this to happen on many sites.
  3. Certain extensions can conflict with ZoomBySite and cause it not to work. I’ve heard that this is the case with Disconnect.me and Ultimate Status Bar.

In spite of these issues, ZoomBySite has been very useful for many people (myself included!).

However, I’ve decided to discontinue what meager support I provide for ZoomBySite and am looking for someone else to take over development and support. The code for the extension is available on GitHub. Please contact me using the contact info on the upper right of this page if you are interested in taking over this extension.

The two main reasons for this change are: 1. I no longer use Safari as my primary browser (I’ve switched to Chrome). 1. Apple has changed the requirements for developing Safari extensions to require a subscription to their developer program ($99/year).

My understanding is that the extension will continue to work for people that have it installed, but that I will not be able to update it anymore.

Thanks to everyone that has sent in feedback for ZoomBySite. I also apologize for not being more responsive to bug reports.

ZoomBySite and OS X Yosemite / Safari 8 / JQuery

I’ve received a number of reports of ZoomBySite not working on OS X Yosemite and/or Safari 8.

I’m not aware of any issues with ZoomBySite and these versions of OS X and Safari, but there are a couple of things that might be causing problems for people.

If the zoom level is not remembered for any site, then check to see if ZoomBySite is enabled (Safari Preferences -> Extensions -> ZoomBySite -> Enable ZoomBySite checkbox). I’ve heard from some people that the ZoomBySite extension was disabled as part of the upgrade process of either OS X or Safari.

If the zoom level works for some sites but not others, then the issue might be with the version of the Javascript JQuery library that the site uses.

One site that seems to be affected by this is forums.macrumors.com. The issue here seems to be a bug with JQuery 1.9.0 that has since been fixed in JQuery 1.9.1. The bug causes the browser to set the zoom level of the body tag to 1, which overrides the zoom level that ZoomBySite sets. It might appear as if the page zooms to the desired level for a split second, but then returns to no zoom. The MacRumors team is looking into working around this by upgrading the version of JQuery that they use.

There also appear to be issues with other versions of JQuery as well. These versions of JQuery intentionally set the zoom level of the body tag to 1 in order to work around a bug in Safari. The Safari bug still appears to be open, but only the following versions of JQuery seem to use the workaround that breaks ZoomBySite:

  • JQuery 1.10.0
  • JQuery 1.10.1
  • JQuery 1.10.2
  • JQuery 1.11.0
  • JQuery 2.0.0
  • JQuery 2.0.1
  • JQuery 2.0.2
  • JQuery 2.0.3

The following versions of JQuery seem to have no problem:

  • JQuery 1.9.1
  • JQuery 1.11.1 (the latest 1.x release)
  • JQuery 2.1.0
  • JQuery 2.1.1 (the latest 2.x release)

These are just guesses based on looking at the JQuery source code.

ZoomBySite and Safari 7 – More Details

I wrote about ZoomBySite not working well with Safari 7 in ZoomBySite and Safari 7:

When a page loads, the ZoomBySite extension checks to see whether a zoom level has been saved for the page’s domain. To do this, a little bit of Javascript on the page sends a message over to the extension, which checks its database of zoom levels, and if one is found, sends a message back to the page with the desired zoom level. The problem with Safari 7 is that when the extension tries to send the message back to the page, it fails. I tried several different workarounds with no success.

As it turned out, the problem was actually with the extension trying to look at the URL of the page, which was always empty when loading in an empty tab or contained the “wrong” URL when loaded in an existing tab (instead of containing the actual URL of page as had been the case in prior versions of Safari). The extension looks at the URL of the page in order to make sure that it’s sending the zoom level to the correct page.

This change in behavior was due to a performance enhancement in Safari related to the preloading of pages. This is documented in the Safari Extension Guide in the Messages and Proxies section (under the ‘Tabs in Safari 6.1 and Later’ heading). This section explains that in some situations, “Safari 6.1 and later may preload webpages in the background to improve the user experience.” It goes on to explain that when you send a message from an extension to a tab, it goes to the live page (as expected) and also to any pages that are being preloaded. There are ways to tell whether the page receiving the message is live (for example, checking document.hidden). There’s also a visibility change Javascript event that can be used to detect the status of the page changing.

As far as I can tell, the change that broke ZoomBySite was that this preloading is now also done when typing in a URL in the address bar. In this case, the page started loading before you finished typing the URL and hitting enter. When ZoomBySite checked the URL of the page, it was either the URL of the previous page (in which case unless the domain was the same, the zoom level wouldn’t change) or if the URL was being typed into an empty tab, it was missing (also causing the zoom level not to change).

There is a preference for turning off this preloading behavior for the address bar in Safari Preferences (Privacy tab -> Do not preload Top Hit in the background). I didn’t try turning this on to see if it fixed ZoomBySite, but it should have. With a well-behaved extension, it’s definitely better to leave this enabled as it improves performance.

The fix for this was to move the check the domain from the extension to the page. In this case, the page knows its domain and can ignore zoom messages that are targeted to a different domain.

Again, thanks to Apple for pointing out the problem with ZoomBySite and also for providing a suggested fix!

ZoomBySite 1.6

I’ve released an update to my ZoomBySite Safari extension.

There is only one change in this version:

  1. A change in the way that the zoom level is sent to the page. This fix has been tested with Safari 7.0.1, but should also work in Safari 7.0.

As always, ZoomBySite is available for download from my site.

ZoomBySite 1.5

I’ve released an update to my ZoomBySite Safari extension.

There is only change in this version:

  1. The extension is now signed with a developer’s certificate.

This was an attempt to solve the issue with ZoomBySite now working with Safari 7. Unfortunately, it didn’t work, but it was a good thing to do in any case.

As always, ZoomBySite is available for download from my site.

ZoomBySite and Safari 7

As my inbox is painfully aware, ZoomBySite has been broken by Safari 7. I’ve been trying (unsuccessfully) to come up with a fix in my spare time since it came out several weeks ago.

When a page loads, the ZoomBySite extension checks to see whether a zoom level has been saved for the page’s domain. To do this, a little bit of Javascript on the page sends a message over to the extension, which checks its database of zoom levels, and if one is found, sends a message back to the page with the desired zoom level. The problem with Safari 7 is that when the extension tries to send the message back to the page, it fails. I tried several different workarounds with no success.

The only thing that worked was to not try and load the zoom level until the page fully loads. This was very jarring because the page would load at the default zoom level and then after a second or so (depending on how big the page was and the speed of your Internet connection), it would resize to your saved level. One of the main things that I’m proud of with this simple extension is how quickly the zoom level is applied… generally before the page is visible, so I hated this solution.

Apple seeded a pre-release version of Safari 7.0.1 yesterday. I was able to download it today and verify that one of my attempted fixes for Safari 7 does work with Safari 7.0.1.

Unfortunately, Safari 7.0.1 is only available to members of Apple’s Safari developers program (which is free to sign up for). I imagine that the public release should be available soon though.

Later tonight, I hope to upload a new version of ZoomBySite which should work with Safari 7.0.1. Thank you for your patience!

Update – Thanks to a very helpful suggestion from a Safari engineer, I was able to include a much better fix in ZoomBySite 1.6 which should work with Safari 7.

iOS and AT&T “4G”

Brad McCarty writes over on The Next Web about iOS 5.1 now using the 4G badge for AT&T’s HSPA+ network:

AT&T is defining its HSPA+ network as 4G, but by the very definition of HSPA+, theoretical speeds aside, it doesn’t qualify as 4G. […] This is clearly, without any doubt, a continued marketing ploy by AT&T and Apple has allowed the carrier to dupe consumers.

Shawn Blanc tweeted:

I wonder if the iPhone showing AT&T “4G” on 5.1 is a part of the negotiations to keep the new iPad’s LTE data plans low.

That was my first thought as well. I definitely think it must be related to the new iPad that supports LTE.

Here’s how AT&T shows their 4G coverage (this is what Apple links to, though I’ve zoomed in one level because the true nationwide map only shows where they support any data; you need to zoom in one level to see the breakdown of 4G, 3G, EDGE, etc.):

AT&T's HSPA+ and 4G coverage map

The dark blue areas are what AT&T calls 4G.

Verizon has a page that compares their coverage with AT&T for “true” 4G. Here’s their view of AT&T’s coverage:

Verizon's view of AT&T 4G coverage

and their own 4G coverage (they do also have a more complex map that looks more like AT&T’s version above for detailed coverage):

Verizon's view of their own 4G coverage

Imagine if Apple hadn’t made the change in iOS 5.1 to allow AT&T to label their HSPA+ network as 4G. The coverage comparison would have been just as Verizon shows on their site. This would have been disaster for AT&T in the short term for sales of data plans for iPads. AT&T claims that their 4G LTE network is “planned to be largely complete by the end of 2013”. That’s a long time to spend behind Verizon. The situation would only get worse when the presumed iPhone with LTE support is released later this year.

AT&T has been petitioning Apple to call their HSPA+ network 4G on the iPhone since the iPhone 4S was released. At that time, they were trying to get ahead of Verizon. Now with the iPad, they’re trying not to fall too far behind.

My Last Day

Today is my last day at my current job with PNC. I’ve been there for a little over twelve years and while it is hard to leave, I’m very excited about this new opportunity.

After a week off, I’ll be starting at Google.

Why Lion Doesn’t Have an iMessage Application (Revisited x 2)

In my last post, I discussed the lack of iMessage support in OS X, which I had predicted in the first post on this site.

Today, as part of Apple’s OS X Mountain Lion announcement, the new Messages OS X was revealed. A Beta version of Messages is available for download today1.

From my original post:

Assuming Apple will provide iMessage functionality on the Mac, I see four options:

  1. A new iMessage app in the App Store
  2. An update to the FaceTime app currently available in the App Store with iMessage integration
  3. An OS X Lion update that includes an updated version of iChat with iMessage integration
  4. A new app in the App Store that combines the functionality of iChat, iMessage, and FaceTime in one place

Their current solution partially matches #12, #3, and #4. I think the closest match is #3. They did basically just add iMessage support to iChat, but also renamed the app from iChat to Messages.

Interestingly, chat windows that are using iMessage have a button to initiate a FaceTime chat, but the button opens up the FaceTime app ready to make a call rather than having the FaceTime functionality built in. Perhaps that consolidation will come with a future version of Messages3.

Why Lion Doesn’t Have an iMessage Application (Revisited)

I Was Wrong

In my first post on this site, Why Lion Doesn’t Have an iMessage Application (Yet), I predicted that Apple would provide an application for OS X that could “chat” with iOS devices using iMessage once iOS 5 was released.

It’s been almost three months now. There have been two point release updates to Lion, 10.7.1 and 10.7.21, yet there is still no iMessage app for OS X.

What a great way to start off this site!

An Aside on FaceTime

FaceTime was introduced with the iPhone 4 in June of 2010, and later brought to OS X in February of 2011. With the initial launch, Apple promised that it would be made into an open standard. To my knowledge, this has still not yet happened.

Perhaps Apple has changed its mind and prefers to keep FaceTime tied to Apple products (iOS and OS X).

Could iMessage Follow the Same Path?

It would appear that Apple is taking a similar approach with iMessage. So far, it’s limited to only iOS devices. I assume that an OS X app shouldn’t be far off, but there’s no promise of that. Even unlikelier would be an open standard that would allow iOS devices to talk to Android, Windows Phone, Windows desktop, etc.

Such a feature would be great for users (of all devices, not just Apple devices), but as the phone carriers have shown, they won’t quietly let Apple take away the massive profits from text messaging. After Apple announced iMessage, AT&T “simplified” their messaging plans by cutting all non-unlimited plans. Prior to the iPhone 4S, I had been an AT&T customer and paid $10/month for more text messages than I needed. Now, I would have to pay twice as much2. Thanks for the simplicity!

Still, even if Apple is planning on following the path blazed by FaceTime, there should still be an OS X client. FaceTime is “locked down” to iOS and OS X through the use of a client-side certificate in the communication with the FaceTime servers at Apple. The same approach could also be used to lock down iMessage.

I Could Still Be Right

I still do think iMessage will make its way onto OS X. It’s just going to take longer than I expected3.