about attachEvent() and detachEvent()

[stanleyxu]

Hi All,

I try to write a script to fix context-menu-hijack.

When the context-menu is hijacked by "oncontextmenu=hijack()", it can be
fixed with "oncontextmenu=null";

But when it is hijacked by "document.attachEvent('oncontextmenu',
hijack)", the previou fixes doesn't work any more.

Is it possible to detach all attached event handler from an event, even
when the name of those event handlers are unknown?


--
___
oo // \\
(_,\/ \_/ \ Xu, Qian
\ \_/_\_/> stanleyxu2005
/_/ \_\

 

[Thomas 'PointedEars' Lahn]

I try to write a script to fix context-menu-hijack.
[...]
But when it is hijacked by "document.attachEvent('oncontextmenu',
hijack)", the previou fixes doesn't work any more.

Is it possible to detach all attached event handler from an event, even
when the name of those event handlers are unknown?

It is not event handlers that are attached, but event listeners. Event
handlers are intrinsic immutable parts of the DOM that execute attached
event listeners in specified order.

I am afraid it is not possible to detach an event listener from an object if
you don't have a reference to that. Determining a reference at runtime is
generally possible with source code parsing, however the reference can be
obfuscated by the offending script-kiddie just as easily.

Nevertheless, there are a number of other ways to work around context-menu
hijacking, with disabling script support being only one of them.


PointedEars

 

[stanleyxu]

I try to write a script to fix context-menu-hijack.
[...]
But when it is hijacked by "document.attachEvent('oncontextmenu',
hijack)", the previou fixes doesn't work any more.

Is it possible to detach all attached event handler from an event, even
when the name of those event handlers are unknown?

It is not event handlers that are attached, but event listeners. Event
handlers are intrinsic immutable parts of the DOM that execute attached
event listeners in specified order.

I am afraid it is not possible to detach an event listener from an object if
you don't have a reference to that. Determining a reference at runtime is
generally possible with source code parsing, however the reference can be
obfuscated by the offending script-kiddie just as easily.

Nevertheless, there are a number of other ways to work around context-menu
hijacking, with disabling script support being only one of them.


PointedEars

Thanks ^^)

Could you tell me any way to work around context-menu hijacking using
"attachEvent"?


--
___
oo // \\
(_,\/ \_/ \ Xu, Qian
\ \_/_\_/> stanleyxu2005
/_/ \_\

 

[VK]

Could you tell me any way to work around context-menu hijacking using
"attachEvent"?

There is not any, except disabling script support. attachEvent has the
same privacy protection as setTimeout/setInterval: only one who
attached/set some has right to detach/clear it.

 

[Thomas 'PointedEars' Lahn]

Could you tell me any way to work around context-menu hijacking using
"attachEvent"?

There is not any, except disabling script support. [...]

You are wrong, of course. For example, there are internal and external
extensions that would allow that. I would not have stated that there are
other ways otherwise.


PointedEars

 

[VK]

There is not any, except disabling script support. [...]

You are wrong, of course. For example, there are internal and external
extensions that would allow that. I would not have stated that there are
other ways otherwise.

Such as?

You know, I'm thinking to introduce a new rule in c.l.j.: "one
possibility to help, that allows one post, that allows one beat down".
So if one can help, he can post the help, and if and only if he can
help, then he can add some comment(s) at the end about the OP's
coding.
IMHO to many people recently decreased their posting content to the
last part only, which is, dare I remind, comes only as a bonus to a
Usenet volunteer and only after the help is provided.

 

[Thomas 'PointedEars' Lahn]

There is not any, except disabling script support. [...]

You are wrong, of course. For example, there are internal and external
extensions that would allow that. I would not have stated that there are
other ways otherwise.

Such as?

Finding appropriate internal and external browser extensions that work
around the problem is beyond the scope of this newsgroup; suffice it
to say that there are some.

[rant]

Go away.


PointedEars

 

[VK]

Finding appropriate internal and external browser extensions that work
around the problem is beyond the scope of this newsgroup; suffice it
to say that there are some.

If you cannot provide a single sample then "there is some" is a
pointless mumbling and not a statement. It is the same as to say in a
math-related group "your formula is wrong for a number of arguments; I
don't know of any but there are some".

It is the same pointless mumbling as to say "the code you are using is
very bad [end of post]". To make it to be a post again out of useless
mumbling the message has to be "the code you are using is very bad,
look at this instead, it is doing what you want but with a) b) c)
benefits".

This way if you want to prove me wrong, you bring a single sample of
attachEvent for oncontextmenu overridden for IE6/IE7.
Until then I reserve my right to call you a liar.

 

[Thomas 'PointedEars' Lahn]

Finding appropriate internal and external browser extensions that work
around the problem is beyond the scope of this newsgroup; suffice it
to say that there are some.

If you cannot provide a single sample then "there is some" is a
pointless mumbling and not a statement. [...]

You may believe anything what your delusional mind allows you to. I have
already explained why am am not willing to elaborate on the possibilities
here. If you can't deal with that, so be it.


PointedEars

 

[stanleyxu]

Hi You All again,

Theoretically I think it is possible:
If I can take over document.attachEvent() before any hijack-code call
"document.attachEvent('oncontextmenu', hijack)", I can detach any
listeners, cannot I?


--
___
oo // \\
(_,\/ \_/ \ Xu, Qian
\ \_/_\_/> stanleyxu2005
/_/ \_\

 

[Thomas 'PointedEars' Lahn]

Theoretically I think it is possible:
If I can take over document.attachEvent() before any hijack-code call
"document.attachEvent('oncontextmenu', hijack)", I can detach any
listeners, cannot I?

Theoretically, yes, but if that approach would be practical, i.e. if you
could specify the order of execution before execution takes place, you would
not need to detach any event listener but you could disable the offending
code right away. The latter is what proxy filters can do automatically,
which is one example of an external extension that I was talking about before.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[...]

BTW, I know for a fact that it is a violation of the Acceptable Use Policy
of the newsserver that you are using to abuse message headers that way,
because the university that is providing the service was my alma mater
a few years ago, and the policy has not changed since then. You'll be
well-advised to adhere to that policy and modify the header so that it
contains the address of a mailbox that is under your control. (I will
gladly provide you with advice in private about avoiding spam when
posting in Usenet, once you made the change.)

http://www.tu-ilmenau.de/unirz/Downloads.download.0.html


PointedEars