Re: Need advice on reliable way to identifyIE asthe browser

I forget that there IS another browser other than Firefox. I just got through some pretty extensive testing of a fairly complex application. I was feeling *really* good about it. I tried to break it using invalid data, keystrokes, mouse clicks, etc. I am smart enough to know that *my* testing will always be influenced by knowledge of how I wrote the app so I sent an email to someone I know who is very thorough, daring her to break it.

I get an email back about 2 minutes later saying that she was getting an error as soon as she logged in and clicked a calendar. WHAT! I had tested that calendar control a 100 times! She gets an "Object does not support this property or method" error. The culprit: IE. Back to the testing rack for me, this time with IE. The light at the end of the tunnel winks out.....

So, I am curious, do you have a tool that can see what DOM event was triggered, deep in the bowels of some DOM object? I very occasionally attempt to view the DOM but frankly I haven't found anything that makes it easy to see events or drill down to the objects that generate them. I have been using jQuery much more as of late and understanding and analyzing the DOM is becoming more important for me. So, what do you use? Also, I know you use Dreamweaver and I know the DW has a browser compatibility checker. Do you find that useful?

Pete


Nathan Andelin wrote:

From: Pete Helgren
I guess someone who had an axe to grind with Microsoft and
didn't mind losing business could implement logic that would
only run on non-MS browsers.

I could admit to something here, but I don't want folks to think of me as devilish ...

More seriously, IE used to be my "preferred" browser, then I switched to FF, and I can see how developers can get zealous about one or the other.

Regarding the behavior of the Table component that I referred to in other threads, I needed to attach a "click" event-listener to "row" objects and refer back to the row object that was the target of the event. Firefox provides a reference to the row in the event currentTarget property. Easy!

IE events don't have a currentTarget property. They have a srcElement property, but if the row contains other elements, say another table for example, the reference in the srcElement property, may be referring to an element way down in the bowels of the DOM hierarchy.

You think, Blast! I just attached the event listener to a "row", but something I many not even be aware of in the bowels of the DOM hierarchy is triggering the event, and the event srcElement is pointing to it! So you write another layer of code to work your way up the DOM hierarchy. At each step, you ask "are you my mother", "are you my mother", "are you my mother", until you find her. And you have to come up with a kludge for identifying the right mother.

I suppose someone could come up with an example of how Firefox makes something harder, but the point is that you kind-of get a feel for your preferred environment and things are easier for you there.

Nathan.