OmniWeb 4.1b6!

simX

Unofficial Mac Genius
In imitation of gplex, I will start posting new threads every time a new sneaky peek of OmniWeb comes out. Incidentally, right now the latest version is beta 6.

Here is the list of changes:

Changes since 4.1 beta 5:

• Enhancements
- Tables
¤ Made an optimization that further reduces jumpiness when laying out tables. A good example of how this will improve things is the Apple Store where the leftmost column used to start out rendering on the right edge of the screen until other columns were parsed. It now starts and stays on the left.
¤ Narrow the circumstances in which we are willing to stretch columns defined as percent width past their desired maximum. Now we'll only do so if we are stretching a span all of whose member columns are percentages. This fixes the differing column widths on forums.maccentral.com.
¤ Another optimization to table layout; it should stabilize a little more quickly now.
- Frames
¤ When loading child frames, we now send along a referring URL (pointing at the frame set's document) in our HTTP request headers.
¤ Cleaned up history/frame interactions.
- Interface
¤ Set the default browser window size to 748x1200, so people who don't find the "Save Window Size" setting aren't stuck with a relatively small browser window. (The window will shrink from this size to accomodate the dock, etc.)
¤ We're now much more careful about preserving location field edits, so they won't get accidentally lost when mousing over a link or switching applications or whatever. (To resume the normal unedited state, you can delete out all the text from the location field and stop editing it.)
- Miscellaneous
¤ When a page is the process of rendering and a link on the page is clicked, we now immediately abort the loading of the current page and begin loading the new page rather than continuing the current load while waiting for data from the new page to arrive. This behavior is controlled by the new OWStopLoadingOldPageWhenLoadingNewPage default.
¤ Improved performance of the initial rendering of 1x1background images so pages like store.apple.com load more quickly. (The Apple Store recently updated their layout to use 1x1 transparent images as the background for a number of their table cells.)
¤ The visited link color is now used for pages in your persistent history in addition to any pages viewed in your current session.
¤ Supply a client certificate callback which simply logs a warning, since we don't actually support client certificates. Now, when a connection fails for this reason, there will be a message logged in OmniWeb's Error Log.
• Localization Changes
- Fixed Spanish localization of OmniWeb. The browser window toolbar will now load.
- Fixed a problem in the Portuguese localization that prevented the toolbar on the Source View window from loading.
- Added many localized images to the international versions of OmniWeb's online help files.
• Bug Fixes
- Rather than retiring the HTML display processor as soon as its thread completes, we now wait for all main thread processing to complete as well. This means that the loading indicators will correctly indicate that the page is still rendering, and fixes some timing issues with jumping to a named anchor where we might think that the page had finished rendering when it hadn't yet.
- Fixed a bug where reloading a frames page from history would create a new history entry for that page, replacing later history entries.
- Fixed bugs with going back to frames pages in non-instant history.
- When we refuse to go to a page in a child frame because it's a parent page (and thus could cause an address loop), we no longer display that refused address in the browser's location field.
- We now load child frames using the same history action (backwards, forwards, or reload) as their parent pipeline used, fixing some bugs in the interaction between frames and history.
- Fixed a problem with Speech Recognition where it wasn't tracking the current page properly, allowing the names of links from other pages to be spoken and OmniWeb would follow them.
- Vastly improved the accuracy of using Speech Recognition for browsing by better integrating with the way that the system handles the text associated with it. Situations where link names were not being recognized should be greatly reduced.
- Fixed bug #3932: Loading a java applet on a page with whitespace in the URL fragment (such as <http://www.telebyteusa.com/catalog/prodlist.htm#fiber optics>) causes OmniWeb to terminate without warning.
- Fixed a table bug where cell spacing would get left out sometimes
- Fixed a bug where a table cell's background color would sometimes fail to draw near an animating default submit button.
- Fixed a problem in our AppleScript support where we were treating OpenURL events as the equivalent to GetURL events. We now respect the WIND parameter of the OpenURL event.
- Fixed a bug where tabbing from the location field to the displayed web page would sometimes fail.
- Fixed a bug where loading the same page twice would leave the location field stuck in the "Load address" state rather than the "Page address" state.
- Fixed a bug which caused a number of problems after scrolling to a named anchor within a document. (For example, you couldn't reload the page or view its source code.)
• Crashers Fixed
- Fixed a crash in the Netscape plug-in compatibility layer.
- Hopefully fixed our most frequent JavaScript crasher.
- Fixed a crash triggered by trying to process a character entity in the invalid Unicode range &#128 - &#159 when it also doesn't have a mapping in the Windows Latin 1 (Code Page 1252) string encoding and is being used as part of an attribute value, e.g. <img alt="This&#141;crashes">
- Fixed crash encountered when customizing the toolbar of a source view after having closed an earlier source view window.
- Fixed some more instances of crashes caused by JavaScript garbage collection.
- Fixed crash caused by trying to copy a partially loaded plug-in.
- Fixed a LiveConnect crash seen when trying to report a JavaScript error.
- Fixed an input text selection crasher, triggered by JavaScript onFocus handlers wanting to change the text before it gets selected.
 
We're now much more careful about preserving location field edits, so they won't get accidentally lost when mousing over a link or switching applications or whatever.
Yay! A fix I wanted!

When a page is the process of rendering and a link on the page is clicked, we now immediately abort the loading of the current page and begin loading the new page rather than continuing the current load while waiting for data from the new page to arrive.
And another one!

Fixed a bug where a table cell's background color would sometimes fail to draw near an animating default submit button
One more!

This sounds like a good update. I can't wait to get it running on my computer...
 
It's time! Thanks for the thread SimX. :)

I find the services of the OmniGroup to its user base so sweet. The OW-MailingList has been a phantastic journey so far, and so have the sneaky peeks of 4.x.

OmniWeb has every chance of replacing every other browser on Mac OS X as soon as it fulfills what's promised. This will take a while, of course, but it's feasible. OmniWeb already has clear advantages over other browsers. All other stuff is just work for the OmniWeb 5.0 phase, which will begin this summer. I mean, hey! It's a Cocoa based application. And they even do extensive testing. They have a great following. Check out the mailing list, it's worth it. Only don't start to fill my mailbox with unnecessary comments. Read the archives first. All available on www.omnigroup.com ...

OmniWeb 4.1b6 also increases speed over b5, although sp77 through sp80 have done that already.
 
I was just on my way over here to post this news. I downloaded this beta and found that it made this site faster. They did something with the tables that made them load in the right place so when viewing the threads it loads faster.

At least for me it does, you should try it yourselves.
 
A new sneaky peek version of OmniWeb is out. According to the chief coder Ken Case (in a message called 'How much to be done before 4.1 is final': "That table bug is the only thing holding back the 4.1 final release."

As far as I can see, the table bug has not been fixed by now (it shows up on macosx.com, too - watch the bottom of this page...), but 4.1 is nearing release. The table bug that hit http://story.ch seems to be fixed in this version, though.

Good work, Omni!
 
but for my usage, it's the most unstable browser out there for Mac OS X . I can usually surf no longer than 20 minutes before encountering some sight that brings it down.

That and it's lack of standards have pushed me to adopt Navigator as my primary browser, with OmniWeb holding second chair, Mozilla 3rd chair, and IE fourth.
 
I can't reproduce your instabilities. 4.1 has been quite stable for me (with one or the other black sheep among the sp versions). while i can crash all other browsers, omniweb stays up and up and up.
a bit like the energizer bunny. :)
 
Yeah... OmniWeb 4.1sp86 still has the table bug. :\

serpi: I have NEVER had a crash with OmniWeb since they fixed the crash on quit bug. I don't know what you're doing to make it crash, but OmniWeb, for me, is the stablest browser out there.
 
Originally posted by simX
Yeah... OmniWeb 4.1sp86 still has the table bug. :\

I was running SP84. Ran Check For Updates and it said that SP85 was available, though when I told it to update, it couldn't find it because SP86 was the latest! :)

Overall I use OW as my main browser these days. Partly because it's Cocoa. But some things still piss me off about it. Javascript is at best buggy. And URL completion would be better if it could do it on the line itself, like in IE. and I want a Go button! Since I past with the middle mouse button, it would make sense. There IS a reason why most browsers have it these days!
 
The table bug was really bad in sp83, but in sp84 it was significantly improved. The table bug on versiontracker seemed to be fixed and the bug on Apple's Webmail, where it randomly cut off the right side of the toolbar, doesn't happen nearly as much, although it still happens occsaionally.

Were there any improvements to this bug in sp85-86? I can't download it until I get home. It seems that from the progress made with sp84, 4.1 final would be able to be released really soon. Did it get any worse in sp85-86?

Adam
 
Damn, they're starting to release more than one sneakypeek a day!

Anyway, it doesn't seem to improve the table bug at all, at least not in these forums, and the release notes don't suggest that it improves it at all.

Hopefully OmniGroup will be able to fix this by July so that they can finally launch 4.1 final at MWNY. 4.1 still won't fix many of the current JavaScript and CSS problems; OmniGroup says these improvements will be in 5, and that the goal is to get OmniWeb working really well with all the web standards by then.

Adam
 
Omniweb is my most oft used browser. I found the early versions completely unstable, now is a completely different story. The best thing about Omniweb - it gives the end user fine tuning over almost every preference you could want. I haven't seen another browser on any platform match its preferences.
 
I agree completely, Jadey. I also think OmniWeb has by far the best interface of any browser. It's toolbar is very consistent with the rest of the OS, and is by far the most Aqua-ish of all the OS X browsers. Also, the download manager, bookmarks and history are the best I've seen on any browser, IMO.

Although it can get pretty slow at times, it has improved a lot in that area and going Back and Forward is the fastest I've seen for any OS X browser. With IE for 9 it was completely instant but when IE for X came out, it's not completely instant anymore. It is for some pages but not for all. OmniWeb used to have the slowest back history ever (it took almost as long as loading the entire page over again!) but in the 4.1 betas and sneakypeeks, it is completely instant. However, this does create some problems with JavaScript. Now on any page with JavaScript links that you go back to via the Back button, clicking on the JavaScript links doesn't do anything. If you reload the page, it's fine.
One place this problem shows up is the KBase, with the JavaScript links there. OmniGroup knows about this problem and with 4.1 final they are going to include an option to turn the Instant Back function off so that the JavaScript links work, but they are going to continue to look for a way to get the JavaScript to work while still having the Instant Back function.

Once OW 5 is released and it has complete functionality for all the web standards, I think Apple should include OmniWeb as the standard browser in OS X instead of IE. Right now, I can see them not wanting to because it still doesn't have full support for web standards, but once it does, there won't be any reason not to, and supposedly Apple is working closely with the OmniGroup in order to get OmniWeb to work flawlessly with OS X and Apple's own pages. OmniWeb is so OS X-ish that it makes sense for Apple to use that as their default browser once it has better support for web standards. OS X, OmniWeb and Mail.app is the perfect combination. :)

Adam
 
Is this what you mean about the table problem?

Here is OmniWeb (notice the "post reply" and "new thread" buttons)
 

Attachments

  • ow.jpg
    ow.jpg
    34 KB · Views: 23
Yeah, that's part of it. The table bug effects many different web pages. On the pages it effects, it usually cuts off some kind of frame or box on the page. On Mac.com Webmail, the right side of the toolbar is occasionally cut off. On these forums, the box with the "Subscribe to this thread", "E-mail this page" links and it also cuts off the "Forum rules" box. When you reload the page, it sometimes fixes it but usually it doesn't.

It seems to be getting a little better with each sneakypeek, and hopefully the OmniGroup will fix this bug soon and release 4.1 final.

Adam
 
Back
Top