Setting focus() to an input Element in a popupwindow opened by a backgroundscript does not work
Categories
(Thunderbird :: Add-Ons: Extensions API, defect)
Tracking
(thunderbird_esr102+ fixed, thunderbird107 affected)
People
(Reporter: G.Gersdorf, Assigned: john)
References
Details
Attachments
(2 files)
|
1.20 KB,
application/x-zip-compressed
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-esr102+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Minimalistic Add-on:
==background.js:
async function start() {
let win=await messenger.windows.create({
url: "focus.html",
type: "popup",
});
}
start();
==focus.html
<!DOCTYPE html>
<html>
<head>
<script src="focus.js"></script>
<title>Focus Test</title>
</head>
<body>
<input id="email" type="text"/>
<input id="delay" type="number" min="0" max="10" size="2"/>
</body>
</html>
== focus.js
async function load() {
console.log('focus at start: '+document.activeElement.tagName);
let email=document.getElementById("email");
setTimeout(()=>{
email.focus();
console.log('focus now '+document.activeElement.tagName+' id='+document.activeElement.id);
}, 500);
}
document.addEventListener('DOMContentLoaded', load, { once: true });
Actual results:
Console output shows, that the focus is indeed on the correct element. But actually the text element is not highlighted and does not accept input.
Something interesting: If you click on one of the arrow icons of the number field, the text element now gets highlighted and accepts input.
Expected results:
The text element should be highlighted and accept input.
|
Reporter | |
Comment 2•3 years ago
|
||
Finally i've found the solution:
In addition to 'element.focus()' you need a 'window.focus()'.
Is this intended behaviour (since TB88) or is it still a bug?
|
Assignee | |
Comment 3•3 years ago
|
||
In what order? First focus the window?
|
|
Reporter | |
Comment 4•3 years ago
|
||
Seems to be irrelevant
|
|
Assignee | |
Comment 5•3 years ago
|
||
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 6•3 years ago
•
|
||
Thanks Günter, I was finally able to get behind this due to your findings. The entire browser was not focused, so an focused element inside of it did not appear as focused.
|
|
Assignee | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/40fb5b228dfa
Set focus to extension browser, so focused elements will actually appear as focused. r=mkmelin
|
|
Assignee | |
Comment 8•3 years ago
|
||
This has been broken again by https://phabricator.services.mozilla.com/D160172 but will be fixed by https://phabricator.services.mozilla.com/D160071.
I will add a test for this in Bug 1797910.
|
|
Assignee | |
Comment 9•3 years ago
|
||
Comment on attachment 9299853 [details]
Bug 1732559 - Set focus to extension browser, so focused elements will actually appear as focused. r=mkmelin
[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
No focus on active elements after load of WebExtension page.
Testing completed (on c-c, etc.):
On Daily for more than 20 days, on Beta since merge day (14.11)
Risk to taking this patch (and alternatives if risky):
Low.
|
||
Comment 10•3 years ago
|
||
Comment on attachment 9299853 [details]
Bug 1732559 - Set focus to extension browser, so focused elements will actually appear as focused. r=mkmelin
[Triage Comment]
Approved for esr102
|
||
Comment 11•3 years ago
|
||
| bugherder uplift | ||
Thunderbird 102.5.1:
https://hg.mozilla.org/releases/comm-esr102/rev/af1f89354628
|
|
||
Comment 12•3 years ago
|
||
| bugherder uplift | ||
Thunderbird 102.5.1:
https://hg.mozilla.org/releases/comm-esr102/rev/bbf216e50e6a
Description
•