Opened 12 years ago
Closed 12 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: |
Description
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
Attachments (1)
Change History (8)
Changed 12 years ago by
Attachment: | event_relatedtarget_null.diff added |
---|
comment:1 Changed 12 years ago by
Please provide steps to reproduce the bug. Which page did you load?
comment:2 Changed 12 years ago by
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.
comment:3 Changed 12 years ago by
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 12 years ago by
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 12 years ago by
Milestone: | tbd → future |
---|
comment:6 Changed 12 years ago by
Milestone: | future → 1.3 |
---|---|
Owner: | changed from sjmiles to bill |
Status: | new → assigned |
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 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(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
dojo/_base/event.js