Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!
Showing posts with label firefox. Show all posts
Showing posts with label firefox. Show all posts

Friday, September 25, 2009

Joys of cross-browser development

I'm working on a dependent drop-down list inside my Tapestry application (one I'm building for a client). Guess what? They fire the critical "change" even completely differently.

In FF, change is fired when:

  • You hit enter after tabbing into the select and changing its value
  • You tab out of the field after changing its value with the up and down arrows
  • You mouse click on the select, then click on an entry in the pop up list

This is sensible, even if it does not, perhaps, match the spec.

In IE 6:

  • After using the mouse to select a value from the popup
  • After changing the value with the up and down arrows

In other words, any visual change to the select causes an immediate change event. Of course, I need to work around IE's behavior since it will result in way too many Ajax requests. My event handler needs to set a timer and wait some time, perhaps 1/4 seconds, before doing the Ajax update (but only if another change event hasn't been triggered). Fortunately, I have Prototype's delay on my side.

Meanwhile, who implements the spec correctly? Here's what it says:

The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA

So, when using mouse selection, FF fires early (before the tab out of the field, or when you hit enter), and IE fires early all the time.

And for those who have asked ... yes, I'll "productize" this code and put it into Tapestry 5.2!

Thursday, June 19, 2008

Firefox 3 : The Good, the Bad

The Good is that it does feel faster,and it now sports a UI that looks much more Mac native.

The Bad is that many plugins don't work yet, such as FireBug! In addition, the Selenium support for Firefox is glitchy with the new release.

Update: People are coming out of the woodwork to point me at the Firebug for FF3 ... check the comments!

Monday, November 27, 2006

Firefox 2.0 stability on Mac OS X

I've found that Firefox 2.0 is simply not stable on Mac OS X (10.4.8 Intel). It was locking up on my multiple times a day. I downgraded to 1.5 and have had virtually no problems since (in the last couple of weeks).

It seemed like it had trouble with heavy JavaScript pages such as Google Mail. Again, 1.5 is fine.

It really is like being between a rock and a hard place; Safari is faster and more stable but doesn't do everything I want it to do (such as the WebDeveloper or FireBug plugins to Firefox). FireFox is less "OS-X-y" (James Duncan Davidson won't run it because it feels like a Windows program to him ... and it sure could use a few more glowing curvy glass buttons!). Some common JavaScript, such as animation effects from Dojo, run incorrectly in Safari but correctly in FireFox. So, what's next ... Opera?

Nope, probably stay with Firefox (1.5, until they admit there are Mac OS X problems and fix them). It's much more likely that my clients will be running FireFox than Safari or Opera (my clients, and my client's client's are almost universally running Windows). I think a shift has occured, where people understand that Firefox is the standard, and that IE may take some extra effort "to get working correctly". I'm not saying people don't expect things to run flawlessly in IE ... just that they understand that it's not automatic, that IE makes things harder.