Mozilla

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • Event firing bug?

    5 answers - 874 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    I have a tree element that contains data records and a couple of
    textboxes for editing the record fields.
    When a tree row is selected the cell data is loaded into the textboxes
    for editing.
    I have an onchange event handler attached to the textboxes that marks
    the record as tinged when altered.
    Now, the tree's onselect handler is supposed to check with the record
    if it has been touched, but (if only one field is altered) by the time
    it fires the textbox's handler hasn't fired yet, not catching the
    change.
    the other hand I have some buttons that are also to check for
    changes in the current record and their oncomand event fires after the
    textbox's onchange handler, thus catching the change.
    Is this a known bug?
    dev-tech-xul mailing list
    dev-tech-xul (AT) lists (DOT) mozilla.org
  • No.1 | | 1104 bytes | |

    shy wrote:

    >I have a tree element that contains data records and a couple of textboxes for editing the record fields.
    >When a tree row is selected the cell data is loaded into the textboxes for editing.
    >I have an onchange event handler attached to the textboxes that marks the record as tinged when altered.
    >Now, the tree's onselect handler is supposed to check with the record if it has been touched, but (if only one field is altered) by the time it fires the textbox's handler hasn't fired yet, not catching the change.

    the other hand I have some buttons that are also to check for changes in the current record and their oncomand event fires after the textbox's onchange handler, thus catching the change.
    >
    >Is this a known bug?


    Well, it's known to me, although I don't remember it being filed as
    such; I think the workaround is to put <treechildren
    onmousedown="this.parentNode.focus();" - the reason it works for
    buttons is that they fire on mouse up.
  • No.2 | | 760 bytes | |

    Neil wrote:
    I think the workaround is to put <treechildren onmousedown="this.parentNode.focus();" >

    True, this works.
    Unfortunately, my event listeners lie in an object which is
    instantiated onload, so I have to attach them through the DM using the
    attachEventListener function and the internals of a tree are not
    DM-accessible.

    Anyway, this has some strange twists:
    If I insert alerts into the listener functions, in Firefox, the events
    suddenly fire off in the expected order.
    Minefield freezes though - must have tripped one of them mines -,
    which could indicate that there is some work in progress regarding
    this.

    dev-tech-xul mailing list
    dev-tech-xul (AT) lists (DOT) mozilla.org
  • No.3 | | 198 bytes | |

    shy wrote:

    >If I insert alerts into the listener functions, in Firefox, the events suddenly fire off in the expected order.

    Alerts cause focus changes too.
  • No.4 | | 805 bytes | |

    Neil wrote:
    Alerts cause focus changes too.

    Makes sense.
    I now use a setTimeout on the execution branch triggered by the
    premature onselect event. milisecond is all that's needed.
    I'm quite happy with that; (For some time I had tried to make do with
    on keypress events on the textboxes instead of the onchange to ensure
    even one field modifications would be registered, but, apart from the
    extra overhead, those didn't fire at all when the contents were altered
    copy-paste actions)

    Now I was thinking about filing a bug, but in the minimal testcase I
    came up with, the events fired in the proper order. Maybe it only
    affects trees with rdf datasources?!

    dev-tech-xul mailing list
    dev-tech-xul (AT) lists (DOT) mozilla.org
  • No.5 | | 923 bytes | |

    shy wrote:

    >I now use a setTimeout on the execution branch triggered by the premature onselect event. milisecond is all that's needed. I'm quite happy with that; (For some time I had tried to make do with on keypress events on the textboxes instead of the onchange to ensure even one field modifications would be registered, but, apart from the extra overhead, those didn't fire at all when the contents were altered copy-paste actions)


    oninput fires for every change (except drag-n-drop); onchange only fires
    when the textbox loses focus.

    >Now I was thinking about filing a bug, but in the minimal testcase I came up with, the events fired in the proper order. Maybe it only affects trees with rdf datasources?!


    I know for sure that it affects the SeaMonkey preferences window, which
    doesn't have a datasource.

Re: Event firing bug?


max 4000 letters.
Your nickname that display:
In order to stop the spam: 7 + 6 =
QUESTION ON "Mozilla"

EMSDN.COM