event.target referencing element not attached to the DOM?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

event.target referencing element not attached to the DOM?

Jonatan-7
Hi,

I don't know if this is the correct forum or not, so please point me in the right direction if I'm blabbing in the wrong place.

To the issue at hand: Since updating to FF 15, I'm experiencing an issue where event.target in event handlers represents an element that is not the same element as the one found in the DOM (== comparison fails), but it seems like it's parent *is* the exact same element as in the DOM.

What I'm doing is intercepting click events on elements and then generating a (proprietary) search path for identifying the element (with or without ID attributes). This has worked fine before, but as of FF 15 I cannot verify that the search path represents the same element anymore since the element in the DOM != event.target.

Has anyone run into this problem or does anyone have any idea what the cause might be? Or a hint as to where I can find someone that has an idea?

Thanks!
/Jonatan
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: event.target referencing element not attached to the DOM?

Bobby Holley-2
Hi Jonatan,

It might be related to compartment-per-global [1]. The best thing to do
would be to put together a reduced testcase (as small and simple as
possible) that works in FF14 but not in FF15, file a bug on
bugzilla.mozilla.org, and CC me. I'll try to take a look!

Cheers,
bholley

[1]
http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/

On Fri, Sep 14, 2012 at 1:55 PM, Jonatan <[hidden email]> wrote:

> Hi,
>
> I don't know if this is the correct forum or not, so please point me in
> the right direction if I'm blabbing in the wrong place.
>
> To the issue at hand: Since updating to FF 15, I'm experiencing an issue
> where event.target in event handlers represents an element that is not the
> same element as the one found in the DOM (== comparison fails), but it
> seems like it's parent *is* the exact same element as in the DOM.
>
> What I'm doing is intercepting click events on elements and then
> generating a (proprietary) search path for identifying the element (with or
> without ID attributes). This has worked fine before, but as of FF 15 I
> cannot verify that the search path represents the same element anymore
> since the element in the DOM != event.target.
>
> Has anyone run into this problem or does anyone have any idea what the
> cause might be? Or a hint as to where I can find someone that has an idea?
>
> Thanks!
> /Jonatan
> _______________________________________________
> dev-tech-dom mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-dom
>
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: event.target referencing element not attached to the DOM?

Jonatan-7
In reply to this post by Jonatan-7
Thanks a lot, Bobby. That might very well be it since the case I'm struggling with is an extension to the Selenium IDE (recording interactions on webpages) combined with a Vaadin/GWT-based application, where the recorded element is sent to the GWT app, which in turn checks the equality.

I gather that the cross-compartment-wrappers should work transparently in cases like these? Or can I force it / explicitly create a cross-compartment-wrapper?

Off to create the reduced test case.

/Jonatan

On Friday, September 14, 2012 4:28:04 PM UTC+3, Bobby Holley wrote:

> Hi Jonatan,
>
>
>
> It might be related to compartment-per-global [1]. The best thing to do
>
> would be to put together a reduced testcase (as small and simple as
>
> possible) that works in FF14 but not in FF15, file a bug on
>
> bugzilla.mozilla.org, and CC me. I'll try to take a look!
>
>
>
> Cheers,
>
> bholley
>
>
>
> [1]
>
> http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/
>
>
>
> On Fri, Sep 14, 2012 at 1:55 PM, Jonatan wrote:
>
>
>
> > Hi,
>
> >
>
> > I don't know if this is the correct forum or not, so please point me in
>
> > the right direction if I'm blabbing in the wrong place.
>
> >
>
> > To the issue at hand: Since updating to FF 15, I'm experiencing an issue
>
> > where event.target in event handlers represents an element that is not the
>
> > same element as the one found in the DOM (== comparison fails), but it
>
> > seems like it's parent *is* the exact same element as in the DOM.
>
> >
>
> > What I'm doing is intercepting click events on elements and then
>
> > generating a (proprietary) search path for identifying the element (with or
>
> > without ID attributes). This has worked fine before, but as of FF 15 I
>
> > cannot verify that the search path represents the same element anymore
>
> > since the element in the DOM != event.target.
>
> >
>
> > Has anyone run into this problem or does anyone have any idea what the
>
> > cause might be? Or a hint as to where I can find someone that has an idea?
>
> >
>
> > Thanks!
>
> > /Jonatan
>
> > _______________________________________________
>
> > dev-tech-dom mailing list
>
> > [hidden email]
>
> > https://lists.mozilla.org/listinfo/dev-tech-dom
>
> >

_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: event.target referencing element not attached to the DOM?

Bobby Holley-2
Yeah, in general the wrappers should be totally undetectable in terms of
identity comparisons. CC me on the bug once you have a testcase.

Cheers,
bholley

On Mon, Sep 17, 2012 at 10:37 AM, Jonatan <[hidden email]> wrote:

> Thanks a lot, Bobby. That might very well be it since the case I'm
> struggling with is an extension to the Selenium IDE (recording interactions
> on webpages) combined with a Vaadin/GWT-based application, where the
> recorded element is sent to the GWT app, which in turn checks the equality.
>
> I gather that the cross-compartment-wrappers should work transparently in
> cases like these? Or can I force it / explicitly create a
> cross-compartment-wrapper?
>
> Off to create the reduced test case.
>
> /Jonatan
>
> On Friday, September 14, 2012 4:28:04 PM UTC+3, Bobby Holley wrote:
> > Hi Jonatan,
> >
> >
> >
> > It might be related to compartment-per-global [1]. The best thing to do
> >
> > would be to put together a reduced testcase (as small and simple as
> >
> > possible) that works in FF14 but not in FF15, file a bug on
> >
> > bugzilla.mozilla.org, and CC me. I'll try to take a look!
> >
> >
> >
> > Cheers,
> >
> > bholley
> >
> >
> >
> > [1]
> >
> >
> http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/
> >
> >
> >
> > On Fri, Sep 14, 2012 at 1:55 PM, Jonatan wrote:
> >
> >
> >
> > > Hi,
> >
> > >
> >
> > > I don't know if this is the correct forum or not, so please point me in
> >
> > > the right direction if I'm blabbing in the wrong place.
> >
> > >
> >
> > > To the issue at hand: Since updating to FF 15, I'm experiencing an
> issue
> >
> > > where event.target in event handlers represents an element that is not
> the
> >
> > > same element as the one found in the DOM (== comparison fails), but it
> >
> > > seems like it's parent *is* the exact same element as in the DOM.
> >
> > >
> >
> > > What I'm doing is intercepting click events on elements and then
> >
> > > generating a (proprietary) search path for identifying the element
> (with or
> >
> > > without ID attributes). This has worked fine before, but as of FF 15 I
> >
> > > cannot verify that the search path represents the same element anymore
> >
> > > since the element in the DOM != event.target.
> >
> > >
> >
> > > Has anyone run into this problem or does anyone have any idea what the
> >
> > > cause might be? Or a hint as to where I can find someone that has an
> idea?
> >
> > >
> >
> > > Thanks!
> >
> > > /Jonatan
> >
> > > _______________________________________________
> >
> > > dev-tech-dom mailing list
> >
> > > [hidden email]
> >
> > > https://lists.mozilla.org/listinfo/dev-tech-dom
> >
> > >
>
> _______________________________________________
> dev-tech-dom mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-dom
>
_______________________________________________
dev-tech-dom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-dom
Loading...