Thomas Much's Weblog

iCab 3.0.3 Beta 455

Today, Alexander released iCab beta 455. The latest betas are available for registered users only, but let's hope that there will be a new public version before the current public version becomes one year old at the end of August...

The new beta version contains bug fixes as usual - and lots of compatibility fixes for other browsers' quirks:

• Unknown HTML attributes in the EMBED tag are no longer reported as error, because these attributes are treated as parameters for the plugin.
• If JS code tries to split text nodes at a location that lies beyond the text boundaries iCab doesn't always return an index error anymore. Some web sites don't work anymore if iCab would return an error in this error condition.
• iCab now supports the "onscroll" and "onmousewheel" events (JavaScript).
• IFRAMEs do now always get an HTML document assigned to, even if the web site defines the IFRAME without an document (the "SRC" attribute is not defined). Some web pages don't work anymore if an empty IFRAME element doesn't have a complete HTML document, because they try to access the non-existing document before(!) they define the document for the IFRAME (and other browsers do allow this).
• iCab internal threads are no longer connected so closely, hopefully this will fix some of the crashes.
• In "Quirks" mode iCab ignores that the CLASS attribute in HTML has to be treated as case-sensitive, because some web pages also don't case about this and won't look right if iCab would follow the web standards here.
• In general a <input type="image"> without NAME attribut can not be a "successful control", which means that the value of this button is never included in the form data when the form is submitted ("successful controls" must have a NAME attribut). But there're web pages which nevertheless require that for this special case (<input type="image">) the value is included using the names "x" and "y" (which can be a problem if these parameters would be used in other elements of the form. But other browsers are doing this as well, so iCab mimics the (wrong) behaviour of the other browsers as well.
• "list-item" elements which are declared as "float" using CSS are no longer treated as "list-item" element.
• Added a workaround for web pages, which try to open an URL which conatins characters that are not allowed in URLs.
• Atom feeds will be now also listed in the RSS Icon popup of the staus bar.
• If iCab was launched the very first time on the Mac and no other web browser was launched before on this Mac, iCab would hang. iCab looked for bookmark files of other browsers to offer that these bookmarks can be imported in iCab. But this didn't work correctly, if no other bookmarks were found.
• For "hover" effects using CSS rules iCab has always tested if the "hover" effect does require to layout the document again (if the size of an element changes) or if it is enough to redraw a certain element (for example if only the color changes). But sometimes iCab did even layout the page again, even if this was not really necessary.
• Added a workaround for a bug in MRJ (Java for "Classic" MacOS). If a Java applet opens a web page in a certain target frame or window, iCab did use a certain "unicode-aware" MRJ function to ask for the target. Unfortunately MRJ only returns garbage when it should return Unicode text. Now iCab uses the non-unicode functions to ask for the target.
• Added a workaround for badly written JavaScript menu libraries, which assume that the Browser would never use the actual visibility state of HTML elements if the state is changed within an event handler.
  The problem: Hovering over an area "A" will open another area "M" the menu. Then the user would normally move the mouse over the menu "M" so select a certain menu item. To programm this, one would write code for onmouseover and onmouseout event handlers. When moving the mouse over "A" "M" must be made visible. When leaving "A" without moving the mouse over "M" the menu "M" must be closed again. And also while the mouse is over "M" the menu "M" must be kept open.
  There's a menu library in the web, which only defines the following rules.
  • mouse over "A": make "M" visible
  • mouse leaves "A": hide "M"
  • mouse over "M": make "M" visible
  • mouse leaves "M": hide "M"
  But must not be working (even it does in other Browsers) because of the follwoing situation: The user moves the mouse from "A" to "M" (which is what the user will do to use the menu). Here one my thing that two events will occur: "A is left" and "the mouse is over M". But this is not always true. It depends on the order the events will be generated and delivered.
  In case the event "A is left" is generated first, this will close the menu "M" and then the mouse can no longer be over "M" and the second event will never occur. The menu will close as soon as the mouse leaves "A". In case the event "mouse is over M" is created first, the menu will stay open until the event "A is left" is delivered (which will be directly after the first event was delivered), and because this event will close the menu, the result is the same: The menu will close as soon as the use moves the mouse from "A" to "M". the menu won't work at all.
  In other browsers the menu stays open, though this is wrong (see above). iCab now follows the bahaviour of the other browsers, even this doesn't really make sense.