[web] Reuse same mediaQuery listener logic both for resize and theme listener

[Shagen Ogandzhanian (Schahen)]

The goal of this PR is to use the same code for listening media query events in both cases we are actually doing it:

• in theme listener
• in resize listener

Apart form the fact that reusing is beneficial, code that were used in theme listener was actually working in a broader set of browsers.

Also, this is preparation for having better approach for dispose.

Demo was updated to support theming (see screenshot)

Testing

manual

Release Notes

N/A

[Copilot]

Pull request overview

Refactors web media-query handling to reuse a shared listener implementation for both system theme changes and resolution/density changes, and updates the demo UI to better reflect system theming.

Changes:

• Introduce a reusable MediaQueryListener abstraction for matchMedia change handling (with legacy fallback APIs).
• Switch system theme observation and window density/resolution listening to use the shared listener.
• Update demo top bars to adapt colors based on system dark theme.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/window/SystemThemeObserver.web.kt	Replaces bespoke theme media-query wiring with shared MediaQueryListener.
compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/window/MediaQueryListener.kt	Adds shared media-query listener abstraction (add/remove listener + matches helper).
compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/window/ComposeWindowInternal.web.kt	Reuses shared listener for resolution/density change detection and adds disposal.
compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/events/DisposableEventListener.kt	Removes unused imports / minor cleanup.
compose/mpp/demo/src/commonMain/kotlin/androidx/compose/mpp/demo/Screen.kt	Updates Material2 top bars to apply theme-aware background/content colors.
compose/mpp/demo/src/commonMain/kotlin/androidx/compose/mpp/demo/ApplicationLayouts.kt	Makes top bar accent color theme-aware in the demo.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Apolo (ApoloApps)]

This clashes with #3216 😬

[Oleksandr Karpovich (eymar)]

It's a bit confusing to see a third branch when first 2 branches already cover true and false.
Then I looked at the matches() method and noticed that it returns Boolean?.

What do you think about creating a value class for the returned value?

For example:

internal value class MediaQuery private constuctor(private val matchResult: Int) {
    companion object {
          val NOT_SUPPORTED = MediaQuery(-1)
          val NO_MATCH = MediaQuery(0)
          val MATCH = MediaQuery(1)
    }
}

then your when becomes:

when(mediaQueryListener.matches()) {
            MATCH -> SystemTheme.DARK
            NO_MATCH -> SystemTheme.LIGHT
            else -> SystemTheme.UNKNOWN
}

[Oleksandr Karpovich (eymar)]

Or maybe it's not the responsibility of fun matches to notify about the unsupported state.
MediaQueryListener might have a static method for checking if queries are supported.

Then fun matches will return a Boolean without ?

[Oleksandr Karpovich (eymar)]

isMatchMediaSupported can be even evaluated once (by lazy) and reused in elsewhere.

[Shagen Ogandzhanian (Schahen)]

I absolutely don't mind having dedicated status if it's not overkill - Boolean? though is more or less an idiom for yes/no/we-don't-know but sure, performance-wise we won't lose anything and may be it will be clearer

[Oleksandr Karpovich (eymar)]

Apolo (@ApoloApps) I see that your PR will be able to reuse MediaQueryListener and it will get rid of systemThemeObserver. Did I miss any other conflicts?

[Apolo (ApoloApps)]

Apolo (Apolo (@ApoloApps)) I see that your PR will be able to reuse MediaQueryListener and it will get rid of systemThemeObserver. Did I miss any other conflicts?

DefaultWindowState is moved to a different file from ComposeWindowInternal and I remove anything related to MediaQueries from ComposeWindowState.
Would also be great to get a review from Web perspective!

[Shagen Ogandzhanian (Schahen)]

Hi Apolo (@ApoloApps) ! The changes you are working at in the dedicated PR do absolutely make sense, so don't takt this action as a neglect or devaluation of what you are doing

It's just that by definition the goal you are trying to achieve is more fundamental and thus will take more time compared to this small fix we'd better have so far.

Rebasing after some changes is part of workflow after all ;)