Closed Bug 21304 Opened 25 years ago Closed 25 years ago

[EVENTTARG] invisible div prevents click to div below

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
All
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mikeque, Assigned: dbaron)

References

(
URL
)

Details

(Whiteboard: [PDT-])

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.
Assignee: troy → joki
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)
Target Milestone: M13
Target Milestone: M13 → M14
Moving M14.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fixed
Status: RESOLVED → REOPENED
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
Summary: invisible div prevents click to div below → [EVENTTARG] invisible div prevents click to div below
Resolution: FIXED → ---
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.
Assignee: joki → dbaron
Status: REOPENED → NEW
Status: NEW → ASSIGNED
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...
Target Milestone: M14 → M15
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.
Keywords: beta1
Whiteboard: [PDT-]
Putting on PDT- radar for beta1.
Fix checked in 2000-03-21 18:43 PST. [ mikeque: Note that this fix is *not* in beta1. ]
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.