Closed Bug 12232 Opened 25 years ago Closed 25 years ago

[EVENTTARG] events going to wrong element: visibility=hidden

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: dbaron)

References

Details

(Keywords: testcase)

Attachments

(2 files)

testcase, described in bug.
752 bytes, text/html
Details
Another test case using a hidden on top of a button (hover doesn't work)
253 bytes, text/html
Details
This is the second of two bugs I am filing on events going to the wrong elements. Bug 1413 also deals with this problem (for floats), bug 12231 for negative margins, and this one for visibility: hidden. They are related, but probably separate. There may be other existing bugs too... DESCRIPTION: Frequently, a group of elements overlap and the author sets the visibility property dynamically so that only one is shown. (I think) the events over that space should go to the one that is visible. Otherwise, strange things could happen. STEPS TO REPRODUCE: * Load attached testcase * click on paragraph ACTUAL RESULTS: The alert says: "You clicked on paragraph one." (Once bug 12231 is fixed, it will say three instead of one.) EXPECTED RESULTS: The alert should say: "You clicked on paragraph two." DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-08-16-08-M9
Summary: events going to wrong element: negative margins → events going to wrong element: visibility=hidden
Whiteboard: [TESTCASE]
Status: NEW → ASSIGNED
Target Milestone: M12
OS: Linux → All
Hardware: PC → All
ALSO DOES NOT WORK CORRECTLY ON: * Windows, apprunner, 1999-08-24-09-M10 Marking All/All.
*** Bug 16887 has been marked as a duplicate of this bug. ***
Doesn't this imply that 'visibility' is changing the z-index? (Note that certainly in the case of :hover, we want the event to go to all of the elements under the cursor, not just the visible one(s) or the top most one.) Hmm...
I disagree with both statements... It just means events only go to things that are visible. Furthermore, I think :hover should match the topmost element being hovered and all its ancestors. With perhaps something like what Ian said for tables... (I think. See the :hover bug for better thought out comments.)
:hover should definitely apply to elements with visible:hidden, otherwise pages using things like the following would not work: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/visible-dynamic.html An example of how this could be used: overlap a hidden, absolutely positioned element on top of another element, and when you hover over it make it visible. Simple and easy tooltips. We currently bubble events up the DOM, so that a click on an element is sent up all its parents if it is not grabbed along the way. (Right?) If the event gets to the top of the tree (the canvas), then (I guess!) we just drop it. Right? I suggest what we do is that we send the event to the top most element, and if it bubbles all the way to the canvas we then try to send it to the element underneath it (assuming of course that it is not an ancestor of the first), and if it still bubbles all the way up to the canvas (or up to a common ancestor, anyway) then we try again with the next element, and so on. That way events would not get lost, but would only get sent to one element. Hmm. I have already suggested this before, in bug 5693 (the :hover bug).
I Can't see it is sane that hidden element get events. Is that *expicitly* stated by the standard? The tooltip exampel can be solved by seting the tooltip visible on an mouseover event on the item belov (Who is explaind by the tooltip). Event going to hidden element vill mess upp common practise. If one have multiple dives with links on top off eachother for fast switching (by swiching visability) You definitly want the visably div get the event only. If the user click beside one link it wold be *verry* confusing if an hidden link in another div is called. Just user input /Lars
There is no W3C draft or recommendation, or any other standard, that, to my knowledge, says *anything* about when an element should receieve events. (With the possible exception of some very vague comments in HTML.) This will result in huge inconsistencies between implementations. IMO, either DOM2 should specify this in terms of the CSS rendering model or CSS should specify it. (Probably DOM2 should as an informative statement, and CSS3 should normatively.)
Target Milestone: M12 → M14
Once again cool but will also have to wait.
Summary: events going to wrong element: visibility=hidden → [EVENTTARG]events going to wrong element: visibility=hidden
*** Bug 23433 has been marked as a duplicate of this bug. ***
Summary: [EVENTTARG]events going to wrong element: visibility=hidden → [EVENTTARG] events going to wrong element: visibility=hidden
Target Milestone: M14 → M16
Moving M16.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
*** Bug 25075 has been marked as a duplicate of this bug. ***
*** Bug 25957 has been marked as a duplicate of this bug. ***
I have this bug fixed in my tree (modulo another bug on the test page with selection, that I'll look at tomorrow). Stealing bug...
Assignee: joki → dbaron
Status: ASSIGNED → NEW
Whiteboard: [TESTCASE]
Status: NEW → ASSIGNED
Target Milestone: M16 → M15
*** Bug 25357 has been marked as a duplicate of this bug. ***
*** Bug 11333 has been marked as a duplicate of this bug. ***
*** Bug 23477 has been marked as a duplicate of this bug. ***
*** Bug 30056 has been marked as a duplicate of this bug. ***
*** Bug 30056 has been marked as a duplicate of this bug. ***
Fix checked in 2000-03-21 18:39-18:43 PST.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The bug reappears in the build around March 20. Base on the example, click on the layer results in message: "you clicked on paragraph three.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 33736
Marking fixed again. Reopening a bug that was noted as "Fix checked in 2000-03-21" based on a March 20 build is probably not the best thing to do...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
*** Bug 35474 has been marked as a duplicate of this bug. ***
*** Bug 37087 has been marked as a duplicate of this bug. ***
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
verified on build 2001-07-30-trunk
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: