More Fun with Browser Quirks
First and foremost, I've been informed by a few folks now that blogs are in fact supposed to be updated from time to time. I had previously been of the impression that simply changing the page theme once a year might suffice, but I stand corrected, and will see if I can't manage to update it a bit more often. The lack of attention paid to the blog has not been entirely without cause....extra attention has been scarce these past months due to the sometimes frenzied pace at which Echo2 is being developed.
To follow up on the last entry, Opera 8.01 is in the wild and appears to correct some of 8.0's XMLHttpRequest-related shortcomings. Safari 2.0 is unfortunately still broken. Shortly after the last blog entry I reported a couple of the Safari bugs via bugreporter.appple.com; the more important of them being promptly marked as a "Duplicate" by an Apple staffer. Whether it has actually been resolved or not I cannot say, as their bug tracking system does not provide me access to such information.
I have found a means to workaround the Safari issue mentioned in the last entry, but the workaround only exposes another bug in Safari 2.0: XML attributes appear not to be (un)escaped properly, i.e., ampersands ("&") are returned as "&". While this too can be worked around, at this point I'm willing to wait for Apple to release a fix rather than adding tons of browser-specific quirk code to workaround a set of bugs that will likely be fixed shortly... even if it means that I have to reply to a few more "Why doesn't it work in Safari?" posts in the next n public announcements.
While we're (STILL) on the subject of fun with web browser quirks, it might be an appropriate time to bring up a particular issue that I like to refer to as the "worst bug ever in Internet Explorer 6." I'm sure some may disagree that this item truly deserves that title, but it is most certainly in conetention for it. Anyway, here's the quirk: IE gets unresponsive when the DOM gets complex. More specifically, when a DOM gets linearly more complex, Internet Explorer will get exponentially less responsive. This is a seat-of-the-pants analysis, but when you see the behvaior for yourself, it's pretty darn obvious. The most easily observed example was that when using IE with an Echo2 app (prior to the workaround implementation), the performance of button rollover effects would degrade in proportion to the number of floating WindowPanes visible on the screen at any given time. If no WindowPanes were visible the "rollover performance" was instantaneous. With one WindowPane, the rollovers were a bit slower. With two there was noticable lag. With three or more the rollover effects would only fire if you stopped moving your mouse and waited with the cursor over a button.
This issue received perhaps 40 hours of time spent trying to isolate the issue and find a solution. In the course of this effort, I noticed that the CPU meter would peg if a complex DOM was being displayed and the mouse cursor was moved in circles anywhere within the IE browser window, even over white space to which no event listeners had been registered. It was also observed that no event listeners appeared to be invoked until such mouse movement ceased. And no DOM updates would be performed while the IE browser was seemingly hypnotized by this irrelevant mouse movement. The moment the mouse stopped, IE would resume executing JavaScript, firing events and updating the DOM as necessary.
At this point I'd managed to isolate the behavior but the solution was still nowhere to be found. When the DOM got complex, rollovers got terribly slow as a result. And dragging a WindowPane could be downright painful. But oddly enough, resizing a WindowPane was still fairly smooth, regardless of the complexity of the DOM. I found this to be extremely interesting, especially given that in cases where one resizes a WindowPane from its upper-left corner, the WindowPane JavaScript code is actually moving the window up/left and then resizing it such that the lower right corner appears to remain stationary--i.e., it's doing everything that a move operation does, and MORE. This observation gave way to the solution: it's not that IE isn't firing events or performing DOM updates when the DOM is complex, it is simply delaying the repainting of the screen in such cases. And as it turns out, changing the width CSS property of a DOM element triggers an immediate repaint operation.
In more recent versions of Echo, if you happen to roll your mouse over a button with a rollover effect, and you happen to be using IE, know that the button is being momentarily resized to be one pixel narrower and then put back to its original state. The effect is not visible, other than that rollover behavior is now smooth even when the UI gets extremely complex. This quirk workaround has also been applied elsewhere, such as to moving WindowPanes. The quirk is ONLY enabled when the client browser is determined to be Internet Explorer. If anyone is aware of other writeups on this IE performance impairment and/or a cleaner workaround, I'd be very interested in learning more.
That's all for now. Time to roll the beta2 release.
To follow up on the last entry, Opera 8.01 is in the wild and appears to correct some of 8.0's XMLHttpRequest-related shortcomings. Safari 2.0 is unfortunately still broken. Shortly after the last blog entry I reported a couple of the Safari bugs via bugreporter.appple.com; the more important of them being promptly marked as a "Duplicate" by an Apple staffer. Whether it has actually been resolved or not I cannot say, as their bug tracking system does not provide me access to such information.
I have found a means to workaround the Safari issue mentioned in the last entry, but the workaround only exposes another bug in Safari 2.0: XML attributes appear not to be (un)escaped properly, i.e., ampersands ("&") are returned as "&". While this too can be worked around, at this point I'm willing to wait for Apple to release a fix rather than adding tons of browser-specific quirk code to workaround a set of bugs that will likely be fixed shortly... even if it means that I have to reply to a few more "Why doesn't it work in Safari?" posts in the next n public announcements.
While we're (STILL) on the subject of fun with web browser quirks, it might be an appropriate time to bring up a particular issue that I like to refer to as the "worst bug ever in Internet Explorer 6." I'm sure some may disagree that this item truly deserves that title, but it is most certainly in conetention for it. Anyway, here's the quirk: IE gets unresponsive when the DOM gets complex. More specifically, when a DOM gets linearly more complex, Internet Explorer will get exponentially less responsive. This is a seat-of-the-pants analysis, but when you see the behvaior for yourself, it's pretty darn obvious. The most easily observed example was that when using IE with an Echo2 app (prior to the workaround implementation), the performance of button rollover effects would degrade in proportion to the number of floating WindowPanes visible on the screen at any given time. If no WindowPanes were visible the "rollover performance" was instantaneous. With one WindowPane, the rollovers were a bit slower. With two there was noticable lag. With three or more the rollover effects would only fire if you stopped moving your mouse and waited with the cursor over a button.
This issue received perhaps 40 hours of time spent trying to isolate the issue and find a solution. In the course of this effort, I noticed that the CPU meter would peg if a complex DOM was being displayed and the mouse cursor was moved in circles anywhere within the IE browser window, even over white space to which no event listeners had been registered. It was also observed that no event listeners appeared to be invoked until such mouse movement ceased. And no DOM updates would be performed while the IE browser was seemingly hypnotized by this irrelevant mouse movement. The moment the mouse stopped, IE would resume executing JavaScript, firing events and updating the DOM as necessary.
At this point I'd managed to isolate the behavior but the solution was still nowhere to be found. When the DOM got complex, rollovers got terribly slow as a result. And dragging a WindowPane could be downright painful. But oddly enough, resizing a WindowPane was still fairly smooth, regardless of the complexity of the DOM. I found this to be extremely interesting, especially given that in cases where one resizes a WindowPane from its upper-left corner, the WindowPane JavaScript code is actually moving the window up/left and then resizing it such that the lower right corner appears to remain stationary--i.e., it's doing everything that a move operation does, and MORE. This observation gave way to the solution: it's not that IE isn't firing events or performing DOM updates when the DOM is complex, it is simply delaying the repainting of the screen in such cases. And as it turns out, changing the width CSS property of a DOM element triggers an immediate repaint operation.
In more recent versions of Echo, if you happen to roll your mouse over a button with a rollover effect, and you happen to be using IE, know that the button is being momentarily resized to be one pixel narrower and then put back to its original state. The effect is not visible, other than that rollover behavior is now smooth even when the UI gets extremely complex. This quirk workaround has also been applied elsewhere, such as to moving WindowPanes. The quirk is ONLY enabled when the client browser is determined to be Internet Explorer. If anyone is aware of other writeups on this IE performance impairment and/or a cleaner workaround, I'd be very interested in learning more.
That's all for now. Time to roll the beta2 release.
posted by Tod Liebeck at
4:24 AM
|
0 comments
