OmniWeb for Mac

Welcome to OmniWeb 6

• System Requirements — Current test builds of OmniWeb 6.0 require El Capitan (macOS 10.11) or later. (The current development target is High Sierra, i.e. macOS 10.13.)

• What else is broken? — Please let us know if you notice regressions which aren’t in the “Not Ready” list below.

What We Know is Not Ready

• Site Preferences — Web pages should honor the “override page styles” site preference. There may be a bunch of other styles that aren’t yet working.

• Proxy Server Authentication — Proxy server authentication hasn’t been reimplemented yet.

If you encounter some other issue with these builds, please use Send Feedback in the OmniWeb menu or email omniweb@omnigroup.com to let us know!

Earlier Changes

Tuesday, September 6, 2016

• Updated Memory Architecture — Over the holiday weekend, rewrote a bunch of low-level code to use the weak references provided by modern Objective C’s Automatic Reference Counting rather than our hand-rolled weak reference implementation from two decades ago. Going forward, this will make this code much easier to maintain, but since this touched a lot of code in fundamental ways it may take a little while to sort out new issues introduced by these changes. I’ll keep my eye on the crash reports and fix new things that I see crop up, but if you want a reasonably stable from before these changes went into place I recommend using r268795.

Thursday, September 1, 2016

• 401 Crash — Fixed a crash encountered when a web page denies access with a 401 Unauthorized error but doesn’t provide any authentication methods. (This typically happens when reconnecting to a web site which requires a login through a web form rather than through HTTP authentication.)

Tuesday, August 9, 2016

• Sandboxed Public Test — Turned Public Test back on. If you’re upgrading from a pre-sandboxed copy of OmniWeb, you may need to migrate your older bookmarks, favorites, and workspaces by hand from ~/Library/Application Support/OmniWeb 5 to your sandboxed container in ~/Library/Containers/com.omnigroup.OmniWeb6/Data/Library/Application Support/OmniWeb.

Sunday, August 7, 2016

• Sandboxing — Finished with the last of the major regressions from introducing sandboxing. There may be a few remaining issues (if you weren’t syncing your bookmarks and favorites, you’ll have to copy them into place by hand) but OmniWeb seems fairly usable once again. Will do a bit more internal testing before making public test builds available again.

Tuesday, August 28, 2015

• Sandboxing — Enabled sandboxing. Unfortunately, this introduces a number of regressions that we don’t have time to fix at the moment. Turning off public test builds so this doesn’t cause issues for people outside Omni.

Tuesday, June 23, 2015

• Performance — Improved scrolling performance on El Capitan.

Tuesday, May 26, 2015

• Untrusted Server Certificates — OmniWeb will once again ask for permission to continue connecting to servers with untrusted certificate chains, rather than immediately giving up with the message “The operation couldn’t be completed. (OSStatus error -9807.)”

Sunday, January 4, 2015

• Preference Registration — Updated OmniWeb’s preference registration to match changes to our shared frameworks made in early December. This fixes the recent regressions with preferences, autocomplete, opening new windows on launch, and many other issues.

Remainder of 2014

• Broken builds — No other intentional changes were made to OmniWeb after October 2, but some changes to our shared framework logic did affect OmniWeb. In particular, a change to the dynamic loader on December 12 broke OmniWeb’s preference registrations which in turn broke many of its features which rely on those preference registrations.

Thursday, October 2, 2014

• Yosemite — Some rendering and stability issues on Yosemite should now be fixed; OmniWeb 6.0 now requires Yosemite.

Tuesday, July 22, 2014

• Resource Unavailable — Fixed a common cause of “Resource Unavailable” errors: they were being triggered by HTTP redirects to a malformed URL (e.g. to URLs with space characters which should have been quoted in the URL as “%20").
• Yosemite compatibility — Fixed some “Layout still needs update” errors introduced by autolayout changes to the NSView API.

Monday, May 12, 2014

• Bundle Uploads — Added support for automatically generating a zip file when uploading bundles (such as OmniOutliner documents).
• Stability — Good news! After 24 hours, I think it’s safe to conclude that our most common crash is finally fixed! (Normally we would have seen hundreds of those crashes in that time; in the last 24 hours there have been none.)
• File Uploads — Reimplemented support for uploading files.

Sunday, May 11, 2014

• Stability — May have finally tracked down the crash in _CFURLResponseCreateCopy(). Then again, it’s never been easy to reproduce on demand so it’s hard to know for sure until we try this fix for a few days and see whether any more crashes in that location get reported. (Thank you for sending in those crash reports!)
• Fragmented gzip-encoded content — Some websites which send compressed content have been rendering poorly in OmniWeb 6 since last December, and if you checked the Error Log you would see a message saying “failed to read from gzip decoding stream” and “inflate: buffer error”. It turns out this “buffer error” is an expected state for the gzip-decoding library; we just needed to provide more buffer space and resume decoding. This is now fixed.
• NSURLErrorDomain error -999 — When Omni Software Update gets an error while trying to load its release notes, it will now log a message to the console rather than displaying a modal error dialog. Also, it won’t ever bother logging a message if the error is NSURLErrorCancelled (-999).

Sunday, Jan 5, 2014

• Stability — Continued work on tracking down the crash in NSURLCache. Found a WebKit preference setting which was frequently updating the cache size as pages from different sites loaded, which may have been the trigger for the crash.

Wednesday, Jan 1, 2014

• Memory Leak — Fixed a memory leak encountered when closing a window.

Sunday, Dec 29, 2013

• Load Blocked Stylesheets — “Load All Images” will now load linked stylesheets as well as images.
• URL with query but no path — Fixed a bug where URLs with a query but no path (e.g. “magnet:?xt=") would get parsed into a URL with an empty path (e.g. “magnet:/?xt=").
• Load All Images — “Load All Images” and the “unloaded images” status bar indicator both work once again.
• Stop — The Stop button and the spinning page load indicator should work again.
• Delete key in Bookmarks — The Delete key works once again in Bookmarks.

Friday, Dec 27, 2013

• Encoding crash — Fixed a crash encountered when a website indicated that its content was encoded with the identity encoding.

Thursday, Dec 26, 2013

• Middle-Click — Middle-clicking on a link will open it in a background tab.
• Construction tape — Removed the construction tape from the title bars of browser windows.

Tuesday, Dec 24, 2013

• Authentication crash — Fixed a crash encountered when trying to purchase music from play.google.com.

Monday, Dec 23, 2013

• Authentication — HTTP authentication with a webserver should now be working properly whether or not you choose to save the password in the keychain.

Wednesday, Dec 11, 2013

• Crash — Fixed a crash encountered when there was an issue decoding data from a compressed HTTP response. Thanks for all the crash reports!
• Fragmented gzip-encoded content — Some gzip-encoded content wasn’t loading properly depending on how its packets were split up for transmission across the wire.
• Gzip-encoded content — Unexpected gzip-encoded content should once again decode properly, rather than yielding a crash (right after logging an “Unknown or unsupported data encoding” error).

Tuesday, Dec 10, 2013

• Do Not Track — Added a security site preference which asks a website not to track you. Please bear in mind that this does not prevent a website from tracking you, it’s simply a request. In OmniWeb this Do Not Track request is sent by default, but as with all security site preferences you can change this default either on a site-by-site basis or globally.
• Crash Logs — Updated crash reports to include the last few seconds of information from the OmniWeb error log, since those details might include a vital clue as to why OmniWeb crashed. (Note: as always, you can review and edit your crash details before sending in the report.) You can turn off this reporting by turning off the “Copy log to crash reports” checkbox in the Error Log window.
• Crash — Fixed a crash encountered when loading from an empty URL.
• Crash — Fixed a crash encountered when performing HTTP authentication with a website.

Sunday, Dec 8, 2013

• Gzip-encoded content — Fixed a regression introduced last week where gzip-encoded content wasn’t being decoded properly. The most obvious ramification of this was that stylesheets were breaking on a number of popular websites.
• Crash — Fixed the zombie crash introduced in today’s earlier build (r200159).
• Crash — Fixed a crash encountered when trying to view the source of a page which failed to load.
• Crash — Fixed a crash sometimes encountered when loading a page with lots of resources.

Tuesday, Dec 3, 2013

• Safari 7.0 compatibility — You can now tell OmniWeb to identify itself to a website as Safari 7.0 (under Site Preferences -> Other).
• Scripts Menu — Removed the obsolete Scripts menu. (It’s been replaced by the global script menu bar item which can be enabled in AppleScript Editor’s preferences.)
• Cookies Regression — Fixed a regression in yesterday’s update which caused all cookies to be lost when quitting the app.
• JavaScript Spoofing — When you ask OmniWeb to identify itself as another browser, this setting will now affect JavaScript identification (via the navigator object) and not just HTTP identification. (This means that if you tell OmniWeb to identify as Safari 7.0, it can once again use icloud.com.)
• Global Site Preferences — Global site preferences work once again.
• Redirect Loop — Fixed an issue with the rewritten HTTP code which could cause a redirect loop due to OmniWeb following the original HTTP standard behavior for 302 rather than the revised-to-match-other-browsers standard.

Monday, Dec 2, 2013

• Flash Plug-In — Flash plug-in content renders once again.
• Independent Cookies — OmniWeb’s cookies are once again completely independent of Safari’s, and all of OmniWeb’s cookie management controls should once again be working properly. (You should now be able to use OmniWeb and Safari to simultaneously log into different accounts on the same website.)
• Show HTTP Requests — The “Show HTTP Requests” switch in the Console once again logs all HTTP requests to/from a server.
• Location Bar — Pressing Return in the Location Bar will once again return focus to the web page, auto-hiding the Location Bar when appropriate.
• Software Update — Moved OmniWeb over to the test software update track so it will see new builds of itself.

Sunday, Nov 10, 2013

• Flash Plug-In Crash — Though Flash plug-in content doesn’t render properly yet (it just shows up as a black square), it no longer crashes OmniWeb 6.

Friday, Oct 25, 2013

• System Requirements — OmniWeb 6 now requires Mavericks (10.9).
• App Icon — OmniWeb 6 has a new app icon.
• Text Zoom — Text Zoom has been re-implemented.
• Energy Use — Enabled automatic graphics switching to reduce energy use.

Monday, May 20, 2013

• 64-bit — OmniWeb is now 64-bit.
• Current WebKit — OmniWeb now uses the system version of WebKit.