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 - 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??

Dani AI

Generated

Pattern described by (links clickable only when lower on the page, header links OK, different image context menus) points strongly to a translucent or invisible element sitting above the content and swallowing mouse events. raised script/resource issues and pointed toward an IE-specific rendering workaround; both are useful leads, but the immediate goal is to identify which element is on top.

A focused diagnostic routine that does not require rewriting the whole page helps isolate the culprit quickly. Use the browser DOM inspector (IE Developer Toolbar or a Firebug Lite drop-in) and these techniques:

  • Use the DOM API to ask which element is under a given viewport point. Run this in the debugger/console to see the topmost element at the pixel where a click fails:
    document.elementFromPoint(100,50)
  • Try keyboard navigation (Tab) to see whether links receive focus when they are visually unclickable. If they can be focused, an overlay is intercepting mouse events but not keyboard events.
  • Binary-hide containers: hide half the page wrapper, then narrow by halves to locate a region that, when hidden, restores clickability. This is faster than deleting pieces one-by-one.
  • Temporarily add visible outlines/backgrounds to large positioned elements to reveal any invisible shims or full-width wrappers.

Common culprits in IE7-era layouts are positioned elements with high z-index or layout/filter hacks that create a new stacking context and an invisible hit area. Once the overlay element is identified, either move it behind the content (adjust position/z-index), remove or resize it, or disable the IE-only rendering hack while serving an alternate approach for legacy browsers. Finally, validate the markup and reproduce the failure in a minimal copy of the page to confirm the fix before deploying.

Recommended Answers

All 9 Replies

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 .

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.