These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Filling usernames and passwords from the keychain seems to have broken sometime in the last few builds.

This seems to be working fine for me in the current build—assuming OmniWeb has access to the keychain entries in question.

A couple things you might try are quitting and restarting the app, and opening a keychain entry that isn't working in Keychain Access where you can double-check its Access Control settings to ensure that OmniWeb 6 is allowed to use that entry.

Ken, I assume that new builds are only created and added to the staging area if there were some changes in the VCS, is that correct? If yes, this would mean that OW6 receives frequent code changes (even if they'll probably be small) - or am I misjudging my observations here?

Ken, I assume that new builds are only created and added to the staging area if there were some changes in the VCS, is that correct? If yes, this would mean that OW6 receives frequent code changes (even if they'll probably be small) - or am I misjudging my observations here?

Well, yes and no.

Yes, OmniWeb 6 only builds when code it uses changes. However, it shares a lot of framework code with our other apps, so most of its builds are triggered by framework changes that don't affect OmniWeb's core functionality (or help with its core issues).

Whenever I touch the OmniWeb code base itself, I try to add an entry to the change log so you'll know what's new. So until today, there hadn't been any interesting changes to OmniWeb itself since last December (even though there have obviously been quite a few builds happening in that time).

Based on the crash reports, it looks like this is the same crash in the caching code of Apple's frameworks which I've been trying to track down for a while. I was hoping that the changes I made last night for the r201285 build would help, but I've already seen a few crash reports in the same place.

Today (in r209448), I 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!)

So far no crashes for me. Just out of interest - whose bug was it in the end? I mean, if I'm not mistaken, both Google Chrome and Safari use the same piece of code, don't they?

I'm happy now to see that OW does not crash anymore. Thus there may be some hope that some fine tuning and polishing can take place now? Loading speed is still a bit of an issue, in particular when loading large workspaces (and unfortunately little feedback is given telling me that OW is still in the process of loading a page).

Did I mention that I'd be willing to pay $100 for an OW license if it should go commercial again?