Two weirdnesses..are they related? (IE7)

[The Natural Philosopher]

It's late and I am through for coding today, but one thing is causing me
to tear my hair out.

Its too long to post all the code, and I haven't yet pinned the thing
down properly.

However I have some pages that work just fine in firefox and Safari, and
validate HTML wise.

But they go apeshit in IE7.

And the weird thing is that a construction that works on another screen
is one if the things that is failing.

And essentially the same code generated by the same subroutine in php,
is working on one part of the screen partly, and not on another..


So, I am seeing if anyone recognizes the symptoms

Basically I have a <div> at zindex-0 that spawns (onmouseover) a <DIV>
'frame' at z-index one into which lots of clickable <div>s are loaded.
I.e. the onmouseover on theh parent <div> switches the visibility of the
parent frame from none to block.

That works, but on one part of the screen the frame at z-index one is
overlaid with the text, and some of the divs inside divs, from another
frame at z-index 0.. that is the flyouts at zindex 1 are sliding *under*
the _text_, and the _divs contained by_, the level 0 divs, but not the
overall div itself. Its as if the nesting within the DOM is expressing
itsel as a rising z-index..

As if that wasn't weird enough, I have another part of the screen where
when you click on one of these flyout divs, another div element gets its
text changed. As well as a hidden variable getting updated. The input
element is named, the other has a unique ID.

Thats done with:-

onclick="document.getElementsByName(mydiv')[0]='127';document.getElementById('mydiv').firstChild.data='new
crap';"

Now on Safari and Firefox everything works, and no reports show up in
the error console.

On IE7 it says that document.getElementById('mydiv').firstChild is not a
valid object.

Yet another screen has this exact system working fine.

I suspect that the brain damage that is causing the first effect, is
also causing the second, but how did I damage its brain in the first place?


Apart from 'well IternetExCrement7 is crap, what do you expect?' has
anyone else experienced any thing like this?

and is there any javascript validator for IE7?



..

 

[The Natural Philosopher]

It's late and I am through for coding today, but one thing is causing me
to tear my hair out.

Its too long to post all the code, and I haven't yet pinned the thing
down properly.

However I have some pages that work just fine in firefox and Safari, and
validate HTML wise.

But they go apeshit in IE7.

And the weird thing is that a construction that works on another screen
is one if the things that is failing.

And essentially the same code generated by the same subroutine in php,
is working on one part of the screen partly, and not on another..


So, I am seeing if anyone recognizes the symptoms

Basically I have a <div> at zindex-0 that spawns (onmouseover) a <DIV>
'frame' at z-index one into which lots of clickable <div>s are loaded.
I.e. the onmouseover on theh parent <div> switches the visibility of the
parent frame from none to block.

That works, but on one part of the screen the frame at z-index one is
overlaid with the text, and some of the divs inside divs, from another
frame at z-index 0.. that is the flyouts at zindex 1 are sliding *under*
the _text_, and the _divs contained by_, the level 0 divs, but not the
overall div itself. Its as if the nesting within the DOM is expressing
itsel as a rising z-index..

As if that wasn't weird enough, I have another part of the screen where
when you click on one of these flyout divs, another div element gets its
text changed. As well as a hidden variable getting updated. The input
element is named, the other has a unique ID.

Thats done with:-

onclick="document.getElementsByName(mydiv')[0]='127';document.getElementById('mydiv').firstChild.data='new
crap';"

Now on Safari and Firefox everything works, and no reports show up in
the error console.

On IE7 it says that document.getElementById('mydiv').firstChild is not a
valid object.

Ahh. I may have the answer to this one. It seems that IE7 when it does a
getElementById('mytag') , will return preferentially the element which
is NAMED 'mytag' if such exists...and in my case I used the same value
for an ID and a name.. well that should be easy to fix, anyway.

http://webbugtrack.blogspot.com/2007/08/bug-152-getelementbyid-returns.html

 

[David Mark]

It's late and I am through for coding today, but one thing is causing me
to tear my hair out.

Just one? That's a good day.

Its too long to post all the code, and I haven't yet pinned the thing
down properly.

Perhaps you should gather your thoughts.

However I have some pages that work just fine in firefox and Safari, and
validate HTML wise.

But they go apeshit in IE7.

Could be anything.

And the weird thing is that a construction that works on another screen
is one if the things that is failing.

That is weird.

And essentially the same code generated by the same subroutine in php,
is working on one part of the screen partly, and not on another..

Curiouser and curiouser.

So, I am seeing if anyone recognizes the symptoms

IE7 goes "apeshit?" Yeah, I've seen that. This particular case
sounds like a loose nut behind the keyboard.

Basically I have a <div> at zindex-0 that spawns (onmouseover) a <DIV>
'frame' at z-index one into which lots of clickable <div>s are loaded.
I.e. the onmouseover on theh parent <div> switches the visibility of the
parent frame from none to block.

How could you have coded this when you can't even explain it?

That works, but on one part of the screen the frame at z-index one is
overlaid with the text, and some of the divs inside divs, from another
frame at z-index 0.. that is the flyouts at zindex 1 are sliding *under*
the _text_, and the _divs contained by_, the level 0 divs,  but not the
overall div itself. Its as if the nesting within the DOM is expressing
itsel as a rising z-index..

Clear as mud (as usual.)

As if that wasn't weird enough, I have another part of the screen where
when you click on one of these flyout divs, another div element gets its
text changed. As well as a hidden variable getting updated. The input
element is named, the other has a unique ID.

Quite a poser.

Thats done with:-

onclick="document.getElementsByName(mydiv')[0]='127';document.getElementById('mydiv').firstChild.data='new
crap';"

What is that?

Now on Safari and Firefox everything works, and no reports show up in
the error console.

I doubt that.

On IE7 it says that document.getElementById('mydiv').firstChild is not a
valid object.

That too. The above "code" won't do anything.

Yet another screen has this exact system working fine.

Not if it includes the above sample.

I suspect that the brain damage that is causing the first effect, is

Aha. Now I think we are making progress.

also causing the second, but how did I damage its brain in the first place?

A blow to the head perhaps? Could explain a lot.

Apart from 'well IternetExCrement7 is crap, what do you expect?' has
Alright.

anyone else experienced any thing like this?

No, but everything is going to be okay.

and is there any javascript validator for IE7?

.

A validator? No. You could try JSLint, but in your delicate
condition...

 

[The Natural Philosopher]

It's late and I am through for coding today, but one thing is causing me
to tear my hair out.

Its too long to post all the code, and I haven't yet pinned the thing
down properly.

However I have some pages that work just fine in firefox and Safari, and
validate HTML wise.

But they go apeshit in IE7.

And the weird thing is that a construction that works on another screen
is one if the things that is failing.

And essentially the same code generated by the same subroutine in php,
is working on one part of the screen partly, and not on another..


So, I am seeing if anyone recognizes the symptoms

Basically I have a <div> at zindex-0 that spawns (onmouseover) a <DIV>
'frame' at z-index one into which lots of clickable <div>s are loaded.
I.e. the onmouseover on theh parent <div> switches the visibility of the
parent frame from none to block.

That works, but on one part of the screen the frame at z-index one is
overlaid with the text, and some of the divs inside divs, from another
frame at z-index 0.. that is the flyouts at zindex 1 are sliding *under*
the _text_, and the _divs contained by_, the level 0 divs, but not the
overall div itself. Its as if the nesting within the DOM is expressing
itsel as a rising z-index..

Oh well. Nothing like expressing the problem clearly to dream up the
right thing to key into google.

Seems this one is well known as well

http://richa.avasthi.name/blogs/tepumpkin/2008/01/11/ie7-lessons-learned/

As if that wasn't weird enough, I have another part of the screen where
when you click on one of these flyout divs, another div element gets its
text changed. As well as a hidden variable getting updated. The input
element is named, the other has a unique ID.

Thats done with:-

onclick="document.getElementsByName(mydiv')[0]='127';document.getElementById('mydiv').firstChild.data='new
crap';"

Now on Safari and Firefox everything works, and no reports show up in
the error console.

On IE7 it says that document.getElementById('mydiv').firstChild is not a
valid object.

Yet another screen has this exact system working fine.

I suspect that the brain damage that is causing the first effect, is
also causing the second, but how did I damage its brain in the first place?


Apart from 'well IternetExCrement7 is crap, what do you expect?' has
anyone else experienced any thing like this?

and is there any javascript validator for IE7?

Sorry to bother you ffolks. Now the problems are understood, I can sleep
better and fix them in the morning.

Night all..

 

[David Mark]

(regarding the workarounds #2 and #3 on the linked page

I don't see why they're going to all the trouble with the .attributes

They don't know what they are doing. There is virtually never a call
to use that collection (or get/setAttribute) in an HTML DOM.

collection. From their comments, it looks like they were trying
something like this in #2 (simplified):

function gEBIreplacement(id) {
    var elem = document.getElementById(id);
    if (elem) {
        if (elem.id == id) {  // x
            return elem;
        }
        // else apply their workaround
    }
    return null;

}

Then they found that in IE, elem.id could refer to a child node of elem
instead of elem's id attribute:

| Unfortunately if the element you are looking for, in turn has a child
| element with a name or id attribute, that is set to "id", it will not
| test the attribute, but rather the child element.

If this is true, the HTML that would trigger this problem could look
something like this:

    <div name="needle">
        <input name="id" ...>
    </div>

So in #3, they changed the line marked 'x' above to:

    if (elem.attributes['id'] && elem.attributes['id'].value == id) {

Stop reading. It's voodoo (and poorly written voodoo at that.)

[snip]

 

[David Mark]

So in #3, they changed the line marked 'x' above to:
    if (elem.attributes['id'] && elem.attributes['id'].value == id) {

Stop reading.  It's voodoo (and poorly written voodoo at that.)

Thanks, I suspected something like that.
So would you say that

function gEBIreplacement(id) {
    var elem = document.getElementById(id);

Best to qualify document (window.document at least.)

    if (elem) {
        if (elem.id === id) {

Why the strict comparison between two strings?

            return elem;
        }
        // try the workaround
        // using getElementsByName() instead of document.all (like it
        // was suggested in the linked page)

Why do anything but return null? If your markup has a name and an ID
that match (on two different elements), then you want this to fail so
you will know to change one or the other. Why would you ever want/
need such an obviously error prone structure?

    }
    return null;

}

is a suitable way to work around the id/name problem in IE and Opera?

Since when is this a problem in Opera? Even if it is, see above.

 

[David Mark]

elem.id could contain a DOM node reference in IE.

As in elem is a form reference and "id" is the name of one of its
inputs? And then if the toString method of this element results in
the ID, you would get an incorrect result. Pretty far-fetched even
for markup you don't control.

=== might not be necessary, but it won't hurt either.



Because I may not be in control of all elements on the page. Links,
headers, and other content (ads) could be injected by other components
on the server side. The classical example of where this bug hits is this:

And who is in control of those? Are they working in sound-proof
booths?

[snip]

 

[rf]

Because I may not be in control of all elements on the page.

You don't have control of your own web pages?

Links,
headers, and other content (ads) could be injected by other components
on the server side.

What other components? Don't you even have control of what your server does?

Time to find a new host.