Closed Bug 1615026 Opened 4 years ago Closed 4 years ago

Snapping issues with file button with widget.disable-native-theme-for-content=true


(Core :: Widget, defect, P2)




Tracking Status
firefox75 --- fixed


(Reporter: emilio, Assigned: emilio)




(2 files)

Attached image Screenshot
No description provided.

Other buttons seem fine.

Thanks for filing. This is also true on other platforms.

Summary: Snapping issues with file button on Linux with widget.disable-native-theme-for-content=true → Snapping issues with file button with widget.disable-native-theme-for-content=true
Blocks: 1615830

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies)
Priority: -- → P2
No longer blocks: 1381938
Blocks: 1615105

I took a look at this bug and I've noticed that by setting padding: 1px; on the <input type="file"> control, the button border is displayed correctly. This made me think that a fix similar to bug 1618260 might do the trick here. Alternatively, I was thinking that we might be able to set this extra padding in nsNativeBasicTheme::GetWidgetPadding, but I haven't been able to do so properly so far. Emilio, what do you think?

Flags: needinfo?(emilio)

Ah, so this is not due to antialising, but because the <button> paints outside of its border area, and the <input type="file"> has overflow: hidden by default, and also -moz-appearance: none; (so GetWidgetPadding doesn't do anything).

(You should check the "Show browser styles" checkbox in devtools btw, comes handy to see what's going on. Also devtools.inspector.showAllAnonymousContent, so that you can inspect the anonymous <button> and so on).

I think the best approach here would be to make the button not paint outside of its border box. You can see the same issue with data:text/html,<span style="display: inline-block; overflow: hidden"><button>ABC</button></span>, and same for <input>.

Maybe we should subtract the border width somewhere we're not subtracting it from?

Flags: needinfo?(emilio)

I can try to poke, I think we're just missing one pixel somewhere in the widget code :)

Flags: needinfo?(emilio)

And I suspect fixing this would also fix almost all the issues I found with my Android try run, which were antialiasing issues in adjacent form controls.

Blocks: 1618202

...and properly pixel-snap while at it, as otherwise my test would fail fuzzily.

Stroke() paints a stroke from the middle of the path, so it'll paint
one-half-of-the-width outside of the rect.

We need to deflate it by half the border width so that the stroke covers exactly
the area we want.

Assignee: nobody → emilio
Attachment #9130936 - Attachment description: Bug 1615026 - Ensure that native theme doesn't stroke outside of its rect. r=mstange,spohl → Bug 1615026 - Ensure that non-native theme doesn't stroke outside of its rect. r=mstange,spohl
Pushed by
Ensure that non-native theme doesn't stroke outside of its rect. r=mstange
Flags: needinfo?(emilio)
See Also: → 1620120
Pushed by
Annotate new test as failing on Mac.
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Regressions: 1620246
No longer blocks: 1615830
You need to log in before you can comment on or make changes to this bug.