Open Bug 1390212 Opened 7 years ago Updated 11 months ago

Parent element won't get focus when child with fixed position is clicked

Categories

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

56 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: dusan, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

I have an element B with fixed position inside an element A with tabindex attribute set to 0. When I click on the element B, the parent element (A) should receive focus. Demo: https://jsfiddle.net/b5srz33t/2/


Actual results:

Nothing. The event seems to be ignored and the parent element (A) will not receive focus.


Expected results:

It should work like in other browsers. The parent element (A) should receive focus.
Component: Untriaged → Layout
Product: Firefox → Core
Component: Layout → Event Handling
Do you think this is related to bug 1265239?
Flags: needinfo?(dusan)
I don't think so. BTW: I can't reproduce 1265239.
Flags: needinfo?(dusan)
Thank you for verifying!

smaug, what do you think about this bug?
Flags: needinfo?(bugs)
Priority: -- → P2
Element A's frame is not ancestor of element B's frame since B is fixed (per attached frame tree dump), even though A is B's parent in content tree. So [1] finds no frame to focus while traversing up in the frame tree.

[1] http://searchfox.org/mozilla-central/rev/00fa5dacedb925022f53d025121f1a919508e7ce/dom/events/EventStateManager.cpp#3102,3111-3119
Neil or Alex might have an opinion here.

We've used frame tree forever to look for focusable area.
But I guess in case of mouse click, we might not need to use it, just focus some ancestor.
Flags: needinfo?(surkov.alexander)
Flags: needinfo?(enndeakin)
Flags: needinfo?(bugs)
It seems the fixed element is not even in geometrical boundaries of its parent, so it doesn't look totally wrong with me if the parent doesn't get focused. Having said it seems to be the browsers compatibility issue, and if everybody does it, then we probably should do it as well. I'm surprised though a bit there's no a web standard saying how the DOM focus should be managed.
Flags: needinfo?(surkov.alexander)
We've always focused by layout objects (nsFrames) whereas webkit/chrome have focused in dom order I think. I believe our behaviour is more correct as evidenced by the testcase here. If there was a less contrived testcase that showed a real-world issue then it might be worth looking at though.
Flags: needinfo?(enndeakin)
Ok, I have created a real-world DropDownButton sample: https://jsfiddle.net/304rozpp/.

1. Show popup by moving focus to the button.
2. Try to write something into the input.
3. Try to click on the label.
4. Is that expected behavior? I think not.

I will answer some questions that came to my mind:

Q: Why is the popup placed inside the button?
A: Putting the popup to the end of body would allow me to use absolute positioning instead of fixed. But it would make styling of the popup a bit cumbersome. And it wouldn't solve my issue.

Q: The button has relative position. Why I don't use absolute positioning?
A: Because I need to display the popup over parent element with overflow set to hidden. That's why I need to use fixed positioning. I think there is no other way.

Q: Can I solve this problem with JavaScript?
A: Yes I can. But it's an ugly and error-prone solution.
Component: Event Handling → User events and focus handling
Severity: normal → S3

This is expected behavior because an element with a fixed position is removed from the normal flow of the document and positioned relative to the viewport instead of its parent container.

When you click on a child element with a fixed position, the event is captured by that element and not propagated to its parent element. This means that the parent element won't receive the focus when the child with a fixed position is clicked.

If you want to ensure that the parent element receives the focus when the child with a fixed position is clicked, you could try adding a click event listener to the child element that explicitly sets the focus on the parent element. For example:

const child = document.querySelector('.child');
const parent = document.querySelector('.parent');

child.addEventListener('click', () => {
parent.focus();
});

This code attaches a click event listener to the child element that sets the focus on the parent element when clicked. However, note that this may not be desirable behavior depending on your specific use case. visit Watch WWE Raw Online

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: