document.activeElement returns <body> on Mac OS
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: robotichead, Unassigned)
Details
Attachments
(2 files)
Screenshot of firefox on mac with issue
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Pre
~~
Mac OS 10.14.4
Using Firefox nightly
Method
1. Create simple web-page as described in CODE section below
2. Open up the web-page in Firefox
3. Open up the dev tools - make sure the "Console" tab is available
3. Click on the button on the page
-- CODE --
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<form action="/" type="POST">
<label>Enter text: </label><input type="text">
<input type="submit">
</form>
<script>
document.addEventListener('submit', function(e) {
e.preventDefault();
console.log(document.activeElement);
})
</script>
</body>
</html>
-- END CODE --
Actual results:
The script in the page will run and do the following things;
1. prevent the page default behaviour
2. print to console the output "<input type='submit'>"
Expected results:
Page defaults are prevented, however the console output is of the body and not the input submit button.
This is only happening on the MAC version, I have tested it on browser stack for Windows 10 and it will output the input. I will hopefully test with Linux at home.
|
Reporter | |
Comment 1•6 years ago
|
||
I have tested on Linux also and it is producing the expected results. This is only effecting MAC
Can repro on macOs 10.12.6
This seems to affect all kind of buttons.
I tried running a bisect on this and while I couldn't find the exact range, it was already broken in v8, so I don't think it still qualifies as a regression (even though it was working in 3.2).
Also note that :active pseudo-class is correctly set to given elements, even searching for [...document.querySelectorAll(':active')].pop() will return the button, (however this can't be used in OP's case: at the time the submit event fires, this pseudo-class already has been removed).
Attaching an other test case.
|
||
Comment 3•6 years ago
|
||
I'm adding a component in order to involve the development team in reviewing this issue.
Feel free to move it to a more appropriate one if necessary.
Thanks for reporting!
|
||
Comment 5•6 years ago
|
||
From https://www.w3schools.com/jsref/prop_document_activeelement.asp
Note: For iOS, elements that are not <input type="text">, will not get focus assigned to them. The property will then return BODY or null.
Looks like we have the same behavior as it described.
Do you still think it is a bug?
No offense but, are you really taking w3schools.com as ref for what behavior you should implement?
Moreover when here it seems it's just a note about a quirk in one OS that's known for having its default browser not always following the specs, thought I even doubt what it really means since different browsers run on "iOS" and I would be surprised Chrome made such a quirk jut for their iOS builds.
Now, the specs are here, but there is no mention of <input> there, so you may have to dig somewhere else, I didn't took the time to find the exact specced behavior yet, but on my desktop, Firefox is the only one exposing this behavior.
And please, avoid w3schools.com.
|
|
||
Comment 7•6 years ago
|
||
(In reply to Kaiido from comment #6)
No offense but, are you really taking w3schools.com as ref for what behavior you should implement?
Sorry for the misunderstanding, I don't mean that.
I just want to make sure the syptom.
For me, the problem is the "submit input" don't get focused after being clicked.
Since it is not focused, we return body for document.activeElement.
Yes, the underlying problem is indeed button-like UI do not receive focus when clicked, even though they are :active.
I can't find what the specs have to say about this, but this behavior seems to appear only in macOs's version of FF.
Every other browsers, or even FF on Windows do set the focus on these elements when clicked.
|
||
Comment 9•6 years ago
|
||
Hi Neil,
Referring to this comment https://bugzilla.mozilla.org/show_bug.cgi?id=756028#c5 , I wonder if this bug behavior is intentional for Mac convention. Could you help confirm please? Thank you.
|
||
Comment 10•6 years ago
|
||
Yes, buttons on Mac should not be focused when you click on them. You'll find the same behaviour on Chrome and Safari on Mac.
|
|
||
Comment 11•6 years ago
|
||
Right now, Chome on Mac has the same behavior as other platforms.
|
|
Reporter | |
Comment 12•6 years ago
|
||
Please confirm the following then;
- This is not being looked at because it is deemed a MAC OS functionality?
- The function (document.activeelement) now has inconsistent functionality between the different OS versions?
- Will another function be implemented so it does return the element, i.e trueActiveElement()?
This inconsistency should be documented at https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot/activeElement, as a simple note that with Mac OS it will return <body> as a result in the coded example above.
Also note Chrome will return "<input type='submit'>" and does show consistent results between the different OS.
|
|
||
Comment 13•6 years ago
|
||
Close, but not quite correct. Normal MacOS behaviour is to not focus buttons (or most UI controls) when clicking on them. This can be seen in other applications. However, it is also common practice to clear the focus on web pages anytime the mouse is clicked on them. The result is that clicking the mouse on a button clears the focus, which has the effect of moving it to the document.
The activeElement property doesn't behave any different though - it is still returning the current focus correctly. When nothing in an HTML document is focused, the body element is returned.
Chrome seems to have implemented some different behaviour where a button does take focus when clicked but doesn't show this visually.
Description
•