#38 open
Damien Saussac

Element.fire fails in IE when element has no parent

Reported by Damien Saussac | December 9th, 2008 @ 09:41 PM

Hello,

I could not find any doc or ticket about this so here we go :


var el = new Element("div");
el.observe("test:evt", function(e){alert(e);});
el.fire("test:evt");

will fail in IE ("Unspecified error") whereas in Firefox it works. This is this line in prototype 1.6.0.3 that throws the exception : 4073 : element.fireEvent(event.eventType, event);

Adding this code before el.fire makes it work in IE also :


var parent = new Element("div");
parent.insert(el);

It can be a problem when using events to synchronize tasks in complex pages like we do at work. Pages we make are built from components and dynamicaly loaded libraries. Thus events are widely used.

As a workaround, elements can be inserted when needed into a fake parent node at event fire time, like this : (to be inserted at line 4073)


if(!element.parentNode)
 new Element("div").insert(element);

(Do you think it is usefull to remove the parent afterwards ?)

PS: by the way that's a great job you have done.

Comments and changes to this ticket

  • Juriy Zaytsev

    Juriy Zaytsev December 10th, 2008 @ 01:01 AM

    • State changed from “new” to “not_for_core”

    Oh god. Usual IE mess.

    FWIW, accessing offsetParent of an orphaned element in IE throws the very same error.

    I don't think we can do much about it internally. Giving element a parent is too obtrusive, imo.

    My advice is to do this explicitly as you currently do, and yes, make sure to null any DOMElement references (i.e. parent container) that are not used.

  • Damien Saussac

    Damien Saussac December 10th, 2008 @ 09:09 AM

    Ok. However I think it's worth a paragraph in the custom events documentation.

  • Juriy Zaytsev

    Juriy Zaytsev December 10th, 2008 @ 02:32 PM

    • Assigned user set to “T.J. Crowder”
    • State changed from “not_for_core” to “doc”

    Definitely. I'll mark this as a "doc" issue.

  • Tobie Langel

    Tobie Langel May 12th, 2009 @ 04:02 PM

    • Milestone cleared.

    [responsible:ID#32948 milestone:ID#9627 bulk edit command]

  • T.J. Crowder

    T.J. Crowder November 16th, 2009 @ 04:50 PM

    • Assigned user cleared.

    [responsible:none bulk edit command]

  • Tobie Langel

    Tobie Langel November 29th, 2009 @ 07:18 PM

    • Milestone cleared.
    • Assigned user set to “Samuel Lebeau”
  • Tobie Langel

    Tobie Langel November 29th, 2009 @ 08:11 PM

    • State changed from “doc” to “open”
  • Michael M Slusarz

    Michael M Slusarz April 5th, 2010 @ 09:44 PM

    I would disagree that this is a documentation issue. Essentially, what you are asking is that every location where you call fire(), you have to make this check. Our web app has tens, if not hundreds, of calls to fire(). There are various locations where we are calling fire() on elements that may have been removed from the page, since various event handlers may fire in various orders and one of these event handlers may remove the element from the page before we can fire the custom event.

    Damien's fix seems to be the exact kind of thing that should be encapsulated in prototype - because it is hiding the quirks of a certain browser from the coding user. I don't feel that giving an element a parent is "too obtrusive". It seems that something like the attached would do the trick.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

People watching this ticket

Attachments

Referenced by

Pages