搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

Learn More

liinks on my website stopped working after upgrading to v3.6.17

  • 6 回覆
  • 9 有這個問題
  • 61 次檢視
  • 最近回覆由 cmullinsjr

more options

Typical link code:

<a href="infopages/000001-info.php">
   the img tag here
 </a>

1. img tag content has been removed for clarity 2. The link is inside a div 3. DOCTYPE is for HTML4.01 strict 4. Code passes W3C validation for HTML4.01 and CSS

The majority of links on images are now disabled but not all. Most <a> links around text still work but a few do not. All links work in IE8 and Opera.

The Error Console refers to an "uncaught exception"

Find it at qualitycanvasart.co.uk/catalog/abstracts-01.php

由 jim.livesey 於 修改

被選擇的解決方法

Firefox 3 versions do not recognize negative z-index values (and probably interpret them as 1), but Firefox 4 does honor negative values, so any container with a higher or default z-index (1) that covers that part makes it impossible to click buttons. Firefox doesn't make it possible to click through layers and only the top layer receives events.

從原來的回覆中察看解決方案 👍 1

所有回覆 (6)

more options

I have similar link structures on some pages, but they all worked fine in 3.6.x and they still work fine in 4.0.1. Sorry I can't help.

more options

That center DIV has a z-index of -1 and that causes the layout DIV to overlay that full section. Leave that z-index at the default (1) or use a positive value like you do elsewhere.


.centerpnl {
  position: absolute; 
	left: 155px; 
	top: 0; 
	width: 660px; 
	height: 740px; /***/
	z-index: -1;
	background-color: transparent;
}
more options

That worked! But I am puzzled. Inside the div centerpnl are others that position the various elements. They are z-index -1. W3C says, "An element with greater stack order is always in front of an element with a lower stack order". So the containing block is now in front of its contents. Its background-color is transparent so you see through it.

The sidebar men has a z-index of 5 so it is "in front" of the centerpnl contents when it slides out, and that works.

The problem affected Gecko browsers, but not Opera and IE8 so they must handle this differently. And why should it matter, a link is a link. If you can see it, it should work. If I get my z-indexes wrong I expect display problems not vanished links on buttons that I can see! And now the z-index sequence seems illogical.

Puzzling, nevertheless I am very grateful for the answer. :-)

more options

選擇的解決方法

Firefox 3 versions do not recognize negative z-index values (and probably interpret them as 1), but Firefox 4 does honor negative values, so any container with a higher or default z-index (1) that covers that part makes it impossible to click buttons. Firefox doesn't make it possible to click through layers and only the top layer receives events.

more options

Thanks for that cor-el. This was version 3.6.17. I looked at the z-indexes again and they were inconsistent to start with so I am fixing that, and your solution worked on my local server so I m sure I shall get this right. Your explanation makes this understandable.

I have noted inconsistent interpretation of x-indexes between browsers in other contexts in te past. Thanks again.

more options

I have same problem but do not use any z-index values. Links next to each other just are not recognized in FF7, but they are in IE9.