Firefox and IE both have a navigator.onLine property which is false whenever the "Work Offline" option is enabled. In Safari, this property is undefined. This came up when testing Safari with a local build of Gears against writer.zoho.com's offline feature. Since 'navigator.onLine' evaluates to false, their checks assumed we were offline, and various things did not work. Since Safari doesn't have a "Work Offline" feature, having this always return true seems a reasonable way to improve web compat.
This was implemented a few days ago in r33457.
Guys - While I wasn't the person who originally filed bug 11284, I pleaded and prodded to get this fixed at the end of March. Anders Carlsson did the work as detailed here: http://trac.webkit.org/changeset/33457 Unfortunately, its not really behaving how I think it should, based on the HTML5 / WHAT.org specification. In bug 11284, Alexey Proskuryakov and I discussed how this should work and I expressed my strong opinion that not only should the navigator.onLine property toggle back and forth when the user has chosen "Work Offline" (which, for some reason, is still not in the GUI for Safari, even though Mozilla and IE have it...) but it should also toggle when the network goes up or down. In my 2008, AJAX-influenced world, I keep a lot of state in the page and I'm doing partial page refreshes and data fetches via DHTML/AJAX. I'm not doing whole 'page-refreshes' or 'page-loads'. Letting me know on the fly whether the network connection is up or down would allow me to prompt the user to give them the option to store the data to the SQL data store, the DOM data store or maybe even generate a big JSON data structure and put it out to a 'mailto:' URL as an emergency backstop to not lose data. In fact, although the HTML5 / WHAT.org spec is a bit ambiguous about what - exactly - constitutes being 'online' or 'offline', IE8 on Vista will respect 'network connectivity' as a reason to toggle this property (and to send the online / offline events). I'm bugging Microsoft to see if they can make this work on IE8 for XP. Note that I'm also having the same discussion over on Mozilla's Bugzilla, since this doesn't work for Firefox 3.0 either (incorrect documentation about how this worked on FF 2.0 notwithstanding). I'm adding Anders and Alexey as CC's on this bug. I hope you don't mind guys, but I'd really like to get this sorted out. Thanks to everyone who worked on this or cares about it! Cheers, - Bill
Here's some additional information which I should have attached to the previous bug: In my test environment, I'm testing the latest WebKit nightlies on both a Mac and Windows XP (using Parallels on Mac). In my first test, I fired up the Webkit nightly on XP, ran up my 'script console' (my own invention - a simple wrapper around 'eval()') and typed in 'navigator.onLine'. It reported 'true', as expected. Then, I disconnected the Parallels environment from its network adaptor. I again typed 'navigator.onLine' - it reported 'true'... not what I expected. I waited about 5 seconds and typed it again. This time it reported 'false' - what I originally expected. I then reconnected Parallels network adaptor, and tried 'navigator.onLine' again - it continued to report false over and over again, no matter how long I continued to try. On the Mac side, 'navigator.onLine' reported true no matter whether I had disconnected my Network via the Network Control Panel or not. Cheers, - Bill
This functionality continues to be completely broken for Webkit v40663 on Mac and Windows and Chrome up through 2.0.160.0. The Mozilla guys have put up a new set of pages describing the functionality here: https://developer.mozilla.org/En/Online_and_offline_events This has a link to a test page there that confirms the bustage. Can we please reopen this bug? Thanks! Cheers, - Bill P.S. I have filed this bug with the Chromium team for that browser: http://code.google.com/p/chromium/issues/detail?id=7469
Sorry folks - Wrong bug. I meant to post this to: https://bugs.webkit.org/show_bug.cgi?id=11284 Cheers, - Bill
Moving all JavaScriptGlue bugs to JavaScriptCore. The JavaScriptGlue framework itself is long gone. And most of the more recent bugs put in this component were put there by people who thought this was for some other aspect of “JavaScript glue” and have nothing to do with the actual original reason for the existence of this component, which was an OS-X-only framework named JavaScriptGlue.