Because forms could be easily hidden behind other elements, and checking if those forms are hidden that way comes at the expense of CPU.

Autofill is a bad idea in general. I've never willingly used it, yet somehow I'll discover that somehow there's still autosaved form data in my browser. Better turn the thing off all together.

Feels like the number of things to turn off is growing out of hand.

It's been way out of hand for a long time and every update of every crucial piece of software has something new. The only major software I haven't felt to need to comb through all the settings looking for new useless features, telemetry, nag screens, re-enabled previously disabled garbage, etc. after every update is Linux.

Linux is a kernel though.

you don't need to comp through the windows NT changelog either. Its the bundled adware that's the problem, and you can get that in some linux distributions as well.

Sorry, Xubuntu.

I’m not a browser engineer, but I’m pretty sure checking if an element is rendered on the screen is not CPU intensive. Browsers maintain an entire rendering tree (parallel to the DOM) for that exact reason.

because it's hard to determine whether something is visible. what if it's offscreen? what if it's partially off screen? what if it's 0% opacity? what if it's 0.001 opacity? what if it's 1px height/width? what if something is overlaid on top of it?

The browser should never auto fill.

The browser should display an autofill preview as an overlay, and only add it to the DOM after the user gives confi

If users are disabling the feature, then another approach may be needed, e.g. a config setting so that only 100% visible, 0% obscured forms will be auto-filled. Allow users to whitelist the known-good scenario.

Most importantly, the page could easily wait until the login manager fills it in, and then immediately hide the form.

Can the browser prevent visibility changes to auto-filled forms?

I feel like that'd be a terrible user experience on non-malicious sites

The parent is demonstrating the complexity of the problem, not providing a comprehensive list of tests. It wouldn't be a problem if we knew the list.

And I'm arguing the problem isn't that complex.

The problem is 99% solved if you assume that a "visible" form must be completely within the current view, at 100% opacity and unobscured by other elements. Apply the same heuristics used by bots to avoid honeypots and fake forms.

It is not 99% solved by that assumption because if those are the properties used to detect visibility then they will not be the methods used to avoid detection.

Obviously setting a property such as visible=false will lead to an invisible form element. Is there a way to detect other invisible form elements, like if one was hidden behind another part of the UI?

The browser could build a reverse index of the pixel->DOM object mapping

So you build that and then do some sort of full scan over the pixels to figure out what's hidden? Sounds really slow