FF3 with firebug trips on e.relatedTarget when losing browser focus

[wdoekes]

When using the "Break on All errors" option of firebug, it breaks when I switch to a different application with an "e.relatedTarget is null" error.

This occurs in a mouseout event added in dojo/_base/event.js, doing the FF2 workaround.

Patch is attached.

Versions:

• Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.9.0.5) Gecko/2008121621 Ubuntu/8.04 (hardy) Firefox/3.0.5
• Firebug 1.3.0

[wdoekes]

dojo/_base/event.js

[Adam Peller]

Please provide steps to reproduce the bug. Which page did you load?

[wdoekes]

preconditions:

• use Firefox 3 with Firebug 1.3.0
• after loading the test sites, enable Firebug on the test sites, and set "Break on All errors" option in the Script pane, reload the page and see behaviour:

expected behaviour:

go to ​http://dojoapi-mirror.devs.nu/bugs/8555.html and witness what's expected.

• an alert box (after 1000ms) for the _caught_ nullexception (TypeError?)
• firebug trips on the _uncaught_ 2nd error (x.noProperty)
• this is expected

unexpected behaviour:

go to ​http://dojoapi-mirror.devs.nu/bugs/dojo-release-1.2.3/dijit/themes/themeTester.html (verbatim from the dojo-release tgz) and witness Firebug tripping over a similar TypeError?.

• click around a bit for a couple of seconds (especially on the accordionpane titles) and a bit outside the window.
• after a while you get an "e.relatedTarget is null" error from Firebug, at the spot as shown in my patch
• see this screenshot: ​http://dojoapi-mirror.devs.nu/bugs/8555.jpg

now, this could be oddness in Firebug, or it could be intended behaviour for all I know. in any case, it is distracting to the unsuspecting user that has "Break on All errors" set.

[wdoekes]

ah, but after a restart of Firefox, my expected behaviour has changed :-)

ignore half of my previous comment:

• my 8555.html (now) also breaks on x.noPropertyButNoError, ergo: expected behaviour is that it breaks on errors, even if they're caught.
• nevertheless, the error as seen in the themeTester.html is still very cryptic to the uninformed (and can be mitigated by checking for nulls)

I'm sorry about the initial confusion.

[bill]

Doug, I remember that we needed a try{} rather than just an if() statement because the if() statement itself through an exception, but is there a problem with having both?

[bill]

I'm in this code now, looking at #8623, maybe I can fix this for 1.3 by adding an if() for that code to only run on FF2. I see the patch attached here too but it seems better to avoid that try/catch altogether, if possible.

Need to test on test_Dialog.html (mousing over the input in the dialog), to see if that change makes it better or worse.

That try/catch block was originally added to solve #7216. Should confirm problem described in that ticket is only happening on FF2.

[bill]

(In [16683]) Only do try/catch block for relatedTarget.tagName for FF2. It's not needed for FF3 and causes some issues. Refs #7216 and fixes #8555.

Also refs #8623 in that it fixes that issue (lingering hover effect on tree nodes) when firebug is enabled, but it's still failing when firebug is disabled as that's another issue.

!strict