See URLand try to click on link in text area. A containing div contains an invisible div. The invisible div prevents any clickthrough to visible contianing div. The w3 CSS2 spec is vague relating to this, but it does work OK in MSIE 4,5.

Probably known issue

I saw this before always. If div "A" contains div "B", but the width of div "A" is smaller than the width of div "B", although you can see "B" you can't click on anything inside of it (or on it)

Moving M14.

fixed

Had to back out the change. The fix was causing problems with a specific case of view event handling in mail/news. Will work on more during M14

Clearing FIXED resolution due to reopen.

I think the change you (joki) made was not to send events to views that had transparency (rather than were completely transparent). I'm surprised it didn't cause more problems than it did. The real fix for this bug is in the individual GetFrameForPoint methods anyway, since an element with visibility: hidden can have children with visibility: visible. I have a bunch of other changes to GetFrameForPoint methods in my tree right now, and I will try to add the necessary fixes for this bug sometime over the weekend. I'll want to test my other changes very thoroughly, so don't expect them in for a while... I think this bug is a duplicate of bug 12232 anyway.

I have the above changes in my tree (mostly), and they fix this bug when the visible and hidden elements are in the same view, but don't fix it when they aren't. The complete fix for this bug actually requires some changes to the view system too, since, due to things being invisible, PresShell::HandleEvent might not be able to find a frame. When that happens, other views need to be tried... The problem is that nsView::HandleEvent assumes that PresShell::HandleEvent always handles the event sucessfully. This could either be fixed by passing aHandled to the PresShell::HandleEvent or by using the return value of PresShell::HandleEvent. I'll poke around and see which is the better solution...

I'm taking this bug since I have a fix for it in my tree.

The fix I made was shooting to fix the view level part of this. The reason it used the transparency flag is that if you look deeper in the code the transparency flag and the visibility flag don't actually always do what you would think they do. The visibility flag, for example, is *never* set to hidden. However, the transparency flag often mirrors the hidden state of the view. I knew when I set it that it didn't always mirror the hidden state but at the time hadn't been able to find any case inside the mozilla app where it caused problem so half fixed was better than none. Anyway I agree, the view system may need some mods to finish this. However, I'm not entirely sure on what you propose. With the exception of visibility I think view targetting is correct. So therefore if a specific element is hidden within a view there's a good chance the event should still be constrained to the view. (i.e. an event hitting and invisible element inside a visible div should will still hit the div, not what's under the div). But we don't currently deal with the base visibility of the view which we still have no way to determine.

However, it must fall through to the next view when everything in the view is hidden, which is the case in the URL for this example. I'll send you my changes to review once I've tested them a bit more, unless you want to see them sooner...

The view is pretty much analagous to the div and so the case where the div is hidden *should* correspond to the view being hidden. That's what I'm attempting to fix.

Moving to M15. I have the changes in my tree to fix this, but there are some other things that need to be fixed before they're ready. Nobody's suggested that this is critical for beta1...

This really does affect rendering strategies. I would consider this critical. I had to build a significant part of the HotBot.com result page around this bug.

In response to your comments, I'll mark beta1 to see what PDT thinks.

Putting on PDT- radar for beta1.

Fix checked in 2000-03-21 18:43 PST. [ mikeque: Note that this fix is *not* in beta1. ]

Is this being fixed?

mikeque - This has been fixed in Mozilla builds since March 22. That was after the Netscape beta1 branched from the trunk for stabilization. However, the fix should be in M15 (to be released real soon now...) and in beta2.

Maeking verified fixed in the July 11th build.