[Bug]: BrowserWindow.getTrafficLightPosition() returns { x: 0, y: 0 }

[bpasero]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

18.3.5

What operating system are you using?

macOS

Operating System Version

12.4

What arch are you using?

arm64 (including Apple Silicon)

Last Known Working Electron version

No response

Expected Behavior

Either BrowserWindow.getTrafficLightPosition() should return undefined if not specified or the actual value it has.

Actual Behavior

BrowserWindow.getTrafficLightPosition() returns { x: 0, y: 0 } when not set custom.

Testcase Gist URL

No response

Additional Information

No response

[codebytere]

This was done initially for backwards compatibility reasons - @zcbenz do you think we might want to change this?

[ckerr]

The docs say:

win.getTrafficLightPosition() macOS

Returns Point - The custom position for the traffic light buttons in frameless window.

This doc isn't as clear as it could be (it should be explicit on what gets returned when there's no custom value) but I agree it ought to be undefined -- (a) that follows more to the spirit of the existing docs, and (b) otherwise there's an edge case because it's impossible to know whether a return value of (0, 0) indicates a custom value or is just the default.

[MarshallOfSound]

This was done initially for backwards compatibility reasons - @zcbenz do you think we might want to change this?

Changing this isn't viable, it would be an undetectable breaking change for lots of apps. We could add a new API getCustomTrafficLightPosition (or something similarly named) that returns null when their is no custom position and update the setter that takes null as a valid argument to reset the position to the system default.

Updating the setter is semver/minor but changing an existing getter to potentially return null is semver/major. Adding a new API and deprecating the old one for removal in ~two releases is probably the best option.

[zcbenz]

The API behaved this way since it was introduced, so basically all existing apps are relying on it and we can not just change the behavior. I agree we should introduce a new API and deprecate this one.

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[bpasero]

bump