Opened 13 years ago

Closed 13 years ago

#8555 closed defect (fixed)

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

Reported by: wdoekes Owned by: bill
Priority: high Milestone: 1.3
Component: Events Version: 1.2.3
Keywords: Cc: [email protected]…, Douglas Hays
Blocked By: Blocking:


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.


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

Attachments (1)

event_relatedtarget_null.diff (736 bytes) - added by wdoekes 13 years ago.

Download all attachments as: .zip

Change History (8)

Changed 13 years ago by wdoekes


comment:1 Changed 13 years ago by Adam Peller

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

comment:2 Changed 13 years ago by wdoekes


  • 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 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 (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:

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.

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by bill

Cc: Douglas Hays added

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?

comment:5 Changed 13 years ago by dante

Milestone: tbdfuture

comment:6 Changed 13 years ago by bill

Milestone: future1.3
Owner: changed from sjmiles to bill
Status: newassigned

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.

comment:7 Changed 13 years ago by bill

Resolution: fixed
Status: assignedclosed

(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.


Note: See TracTickets for help on using tickets.