Firefox Nightly 87.0a1 20210202214809 on Windows 8.1, 125% OS level zoom

Steps to reproduce:

1. Open https://bugherder.mozilla.org/?cset=0ed0d98d5d14ac1434e45ed6bb0963b31a07e498&tree=mozilla-beta
2. Wait for it to load and click the button "Submit the changes" afterwards.

Actual result:
Input textbox is missing border at the top.

Expected result:
Input textbox with border on all 4 sides.

[Tracking Requested - why for this release]: Regression in form control rendering on Windows.

Weird. To be clear this works if you enable widget.disable-native-theme-for-content and reload the page, right?

This seems like an issue with the Windows theme. Will dig.

Just to confirm, if you open devtools, and add padding: 0 to that element, you start seeing the border again, right?

And if you do that and change the zoom (with the mousewheel, or Ctrl+, or what not), are there zoom levels where you don't see it?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Just to confirm, if you open devtools, and add padding: 0 to that element, you start seeing the border again, right?
No.

With the default config:
top border missing: 100%, 110%, 210%, 220%
left border missing: 340%

With widget.disable-native-theme-for-content:
Has borders on all sides at all zoom levels.

Deactivating the body style rule font: 100%/1.5 Helvetica Neue, Helvetica, Arial, sans-serif fixes the issue.

Ok, so this is not a regression. I can repro the same way on release if I add the following rule using devtools:

input[type="submit"], button {
    padding-block: 1px;
}

And I can see missing borders without that just at different zoom levels. So my patch basically changed where the <input> ended up on the screen.

So per the above this is not really a regression... I tried to hunt down the source of wrong snapping in nsNativeThemeWin / gfxNativeWindowsDrawing, but I'm not particularly familiar with that code nor windows debugging, so it might take a while... Jeff, do you know someone who might be familiar with the native windows painting code?

I've been looking and there is some really sketchy snapping (some from bug 382458 etc).

If this isn't a regression presumably we continue ignoring it until non-native themes ship?

Yeah, that's likely a good option. Spending our time getting the non-native theme ready to ship is probably smarter.

AIUI this is nightly only right now?

No, this is a long-standing bug in our windows code, I can repro before my change. Enabling the non-native theme on Windows will fix this.

Alright thanks, updating flags.

The non-native theme was enabled in bug 1615105.