Elements in the option pane of an embedded option page are partially obscured
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
People
(Reporter: farblos, Unassigned)
Details
Attachments
(3 files)
Screenshot showing the obscured, focused input field.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Steps to reproduce:
Create a minimal extension consisting of the following two files in a newly created directory:
manifest.json:
{
"name": "Test",
"description": "Test",
"version": "2.8",
"options_ui": {"page": "options.html"},
"manifest_version": 2
}
options.html:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Options</title>
</head>
<body>
<input type="text" value="foobarbazfoobarbazfoobarbaz"/>
</body>
</html>
Start FF nightly with a fresh profile, go to about:debugging#/runtime/this-firefox and load above extension as temporary add-on.
Go to about:addons => extensions, select to show the extension preferences of the temporary "Test" add-on.
Actual results:
The ...foobarbaz... input field is partially obscured, see also attached screen shot.
Expected results:
The ...foobarbaz... input field is completely displayed, also the focus marker around when focusing it.
This might be related to bug 1881055, which I came across because of my other recent bug 1939206.
In that bug [:robwu] mentioned the removal of some gap in the option pane, and then I remembered being annoyed that I had to put an explicit margin around the option page body to get all elements nicely displayed...
|
||
Comment 2•1 year ago
|
||
Hello,
I’m not sure I reproduced the issue on my end, as I’m not entirely sure I understood from the screenshot what the issue is exactly. From what I can see, the input field is cut at the end i.e. the right border is not entirely displayed when both the field is unfocused and focused.
Going from the above assessment of the issue, on my end, the field is properly displayed in its’ entirety and is not cut at the right side. See the attached screenshot for more details. The state of the field shown in the screenshot is the same across the latest Nightly (136.0a1/20250107165124), Beta (135.0b1/20250106170344) and Release (134.0/20241230151726) on Windows 10 and Ubuntu 24.04 LTS.
Do let me know if I correctly understood what the issue is. Thank you !
|
|
||
Comment 3•1 year ago
|
||
Hi and thanks for looking into this.
Up-front: It turned out that the stack element removed with bug 1881055, which I suspect to cause this bug, also causes bug 1939206, so the discussion here may be mute already ...
But other than that I agree that in the latest nightly things look a tad better. However, the focus indicator is still incomplete. IOW, I want something like in the attached screenshot, which I have been able to get by adding a 4px margin to the option page body like this:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Options</title>
<style>body { margin: 4px; }</style>
</head>
<body>
<input type="text" value="foobarbazfoobarbazfoobarbaz"/>
</body>
</html>
Only that I strongly feel that I should not be responsible for adding that margin.
Does that clarify your question?
|
|
||
Comment 6•1 year ago
|
||
Hello farblos and thank you !
Yes, all is clear now and I do agree that the focus indicator is incomplete. I will mark this report as New.
|
||
Comment 7•1 year ago
|
||
This behavior is triggered by the options_ui.browser_style manifest property, which for Manifest V2 extension is still set to true by default for the options_ui page (where as for Manifest V3 extension that is a deprecated feature and implicitly opt-ed out).
In particular the CSS rule injected by options_ui.browser_style that triggers this issue is the margin: 0 being set here:
MV2 extension can opt-out from the browser_style injected css rules by explicitly setting browser_style to false in the manifest field:
{
"manifest_version": 2,
...
"options_ui": {"page": "options.html", "browser_style": false},
...
}
MV3 extensions instead would not need this because browser_style is implicitly set to false and deprecated as mentioned earlier in this comment.
Thanks for clarifying, Luca!
Feel free to close this bug as you consider appropriate.
Description
•