I've got a really strange problem that I haven't been able to crack. On my web page, when viewing it on IE7, most of the hyperlinks do not work when the link is rendered near the top half of the body of the page.

For example, see the "Discography" page - linked text highlights when you mouse over it, and the links work (opening in a new page), when the link is showing towards the bottom of the inner content area. But if you scroll down the content of the page a bit, that same link which previously worked stops working once it gets near the top of the visible content area.

The header links (shown on all pages of the site) work fine, though, even though they're up near the top of the page.

This problem only happens on IE (I've only been able to test on IE7, and this is what I see on various machines with IE7) - the links work perfectly on Firefox.

Note also that the context menu when you click on the images (the album cover-art for example) is different for images at the bottom of the content area, vs. images which have been scrolled near the top of the content area.

It seems as if there's a hidden div/layer floating over the top of that part of the content area, preventing clicking links for a portion of the content area. But I can't find anything like that when inspecting my DOM hierarchy for the page.

Any suggestions??

Your script seems to be taking too much control, preventing the mouse from clicking things.

Your script seems to be taking too much control, preventing the mouse from clicking things.

In what sense? As far as I can see, there's nothing in my Javascript which is grabbing control of the mouse or mouse-clicks. Can you elaborate on this?

Thanks.

The script is taking all of the CPU time.

You can't have a script running all the time and expect other functions to work normally and concurrently. The script should either be started by a click, or it should run intermittently (Use setInterval instead of a while loop).

If the script is constantly rewriting the page, then immediately after the page rewrites, windows scans for a mouse click. If you fail to click in the tiny instant between the rewrite and the scan, the click is lost because of the rewrite.

It may be that the browser scans through the links to see if the mouse is on any of them before looking for the click. In that case, it's more likely that a click on the lower half is recognized.

I had the same kind of trouble last year. I had to make the script intermittent to solve it.

The script is taking all of the CPU time.

No, that's not it - haven't seen that sort of behavior on any of the browsers or OS's that I've tried this on. And if you look at the Javascript, it only runs at three occasions:

1. on any window.onresize
2. on window.onload
3. when the page first displays, the background image is rendered inline

I've thoroughly checked and debugged the javascript, so I don't think that has anything to do with it.

I believe it must have something to do with the div's, somehow maybe IE7 is imagining an invisible layer resting there, for some reason - overlaying the page, making it unclickable. I have no idea why or how it could be doing that, though.

Anyone else have any thoughts?

I took another look and found my security system in IE reporting the page as a suspected phishing site.

I think your attempt to disguise your email address is causing this.

The CPU usage was my security software reacting to this suspected site.

I did notice that the links at the top right work. I also noticed that the link address fails to appear in the status bar when it is unclickable.

One other thing: Your quoted string in the disguised email address may be longer than the longest string IE can accept.

I took another look and found my security system in IE reporting the page as a suspected phishing site.

I think your attempt to disguise your email address is causing this.

The CPU usage was my security software reacting to this suspected site.

I did notice that the links at the top right work. I also noticed that the link address fails to appear in the status bar when it is unclickable.

One other thing: Your quoted string in the disguised email address may be longer than the longest string IE can accept.

I can see how that obfuscated email address might trigger phishing-detection software. Thanks for that observation.

However, that email address can't be responsible for the links not working, since I have the same problem on other pages of the site which don't contain the obfuscated email address, such as the list of upcoming shows.

I see several things you need to check, and a few tips on finding this:

- The <!-- --> tags no longer protect html from scripts. They hide scripts from new browsers.

- Putting scripts in the html file (instead of external scripts) causes all kinds of hard to locate grief. I stopped using them the first week I started writing JS.

- Is there any JS code that changes the contents of anchor tags?

- Does the JS make some kind of covering box that is on top of the links in the top half of the page. A mouse can't click through a layer onto the layer below.

- I note that the top row links in the head box work.

- Have the W3C site validate the site. If it finds errors, fix them.

- Try deleting parts of the page, one at a time, in a temporary copy, and see if removing a piece makes the site work.

The problem is related to your use of transparent PNGs. I had the same problem here. I had a Javascript workaround using AlphaImageLoader like you, and none of my links were being recognized. I deleted the script, and my links worked fine. I took the liberty of doing the same with your source code, and while the PNGs did not load, all of the links worked in IE7. With my site however, the PNG's still loaded in IE7 so I am just going to discontinue IE6 and lower support and redirect older browser users to the IE7 download (I can do that because my site already requires at least Flash 8). I still don't have everything totally figured out, but I though I'd give you the heads up as to what the problem is.

I ended up not fully discontinuing support, but instead I wrapped my AlphaImageLoader script for IE6 in a Conditional Comment that told IE6 and less to read the script, but IE 7 bypassed. That's the best solution I have found, but I'm kind of new to web design.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.