[Bug]: screen.getAllDisplays() and desktopCapturer.getSources() order no longer matches (29.3.2, 30.0.2)

[Galkon]

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

29.3.2, 30.0.2

What operating system are you using?

macOS

Operating System Version

Sonoma 14.4.1

What arch are you using?

arm64 (including Apple Silicon)

Last Known Working Electron version

28.3.1

Expected Behavior

When using multiple displays, it is expected that screen.getAllDisplays() returns the displays in the same order as sources returned from:

await desktopCapturer.getSources({
    types: ['screen'],
    thumbnailSize: thumbnailSize
  })

• Display index: 0
  • Screen display ID by index: 3
  • Source display ID by index: 3
• Display index: 1
  • Screen display ID by index: 1
  • Source display ID by index: 1
• Display index: 2
  • Screen display ID by index: 2
  • Source display ID by index: 2

electron-28.3.1-working.mov

Actual Behavior

In 29.3.2, 30.0.1, 30.0.2, on my setup with 3 monitors, it started providing mismatching orders between the two every time.

• Display index: 0
  • Screen display ID by index: 3
  • Source display ID by index: 2
• Display index: 1
  • Screen display ID by index: 1
  • Source display ID by index: 3
• Display index: 2
  • Screen display ID by index: 2
  • Source display ID by index: 1

electron-30.0.2-broken.mov

Testcase Gist URL

https://gist.github.com/Galkon/f467fdaf8f03cc0aac9f811e2a54c04d

Additional Information

This was working for me on this computer earlier this week. I have a KVM switch, which I had to rearrange the ports yesterday, and since then I've had this issue.

Downgrading to electron 28.3.1 resolves the issue. Upgrading back to 29.3.2 or 30.0.1, 30.0.2 again reintroduces the issue.

I've since changed my code to match display.id to sources.display_id to get around this unexpected behavior -- obviously this change will be more reliable -- but I wasn't sure if it was intended for this to have changed or not.