Maybe this can just replace __experimentalWidthProvider?

That'd be nice. Would leave it for follow-up, though.

To consider: whether it's useMediaQuery's job to consider this context, or expect the component that calls it to fetch the right window and pass it to useMediaQuery

The problem is that not only do several components use useMediaQuery, but several hooks also depend on it. So, if we wanted to get rid of this idea of implicit context and require components themselves to pass a Window instance, we'd have to touch a lot of pieces across Gutenberg.

So which is worse:

• Making all those edits and risk breaking something in the process?
• Adopting this implicit Window context and risk forgetting an edge case where it was actually/accidentally intended that useMediaQuery use the global instance?

I think #76424 is an instance of that type of edge case. The button appender is being opened from within the canvas but it expects its responsive behaviour to go by the width of the viewport.

We should also take into account that useMediaQuery is public so there are likely third party plugins using it. For that reason, it's best not to change its default behaviour.

What if instead we defaulted to the current behaviour and optionally allowed passing a window instance? Then we could do so for anything in the canvas that calls this function and wants it to respect canvas sizing.

Passing the window is exactly what I suggested to @mcsf before, I think I prefer the explicitness of it. If this hook didn't exist at all and people were using the native event handler themselves, they're have to use the right window as well. I think it's good for whoever is using the hook to be aware of what window they use instead of a magic context.

For #76424 though, ideally that modal/popover should be mounted outside the iframe instead of inside the iframe.

What if instead we defaulted to the current behaviour and optionally allowed passing a window instance?

Yes, this is what I was trying to articulate here and saying that, though reasonable, it entails touching the consumers.

It's true though that, if we simply make the window argument optional and let it default to the global window, that might satisfy both concerns of back-compat and soundness. Thoughts?

Where should this live? I only put it in compose because the dependency chain between producers and consumers is:

block-editor (consumer) -> compose (producer)

I like the readability of this ref 😄 and can't think of any advantage to useBlockElementRef here.

There are no other places that I know of; the block visibility was the one that was obviously broken (and prompted my initial attempt in #75156.)

There don't seem to be many places where we rely on viewport matching to determine behaviour in the editor canvas; where we do this PR is testing well. For instance, site logo allows resizing only on large viewports, but the size at which the resize handles disappear in this branch seems sensible to me.

With useRefEffect, element is guaranteed. Maybe you just wanted to change it to a regular ref callback?

Why is this even memo'ed in the first place?

I assume it might need to be memo'ed so that subscribe and getValue have stable references when passed in to useSyncExternalStore?

I'm not sure I'm following what's happening here. Why are we setting the current property on a function? Also, isn't this the same as doing view: ref.ownerDocument.defaultView below? Either way it doesn't re-render the component, and it looks like re-rendering seems necessary here? In which case we should probably set some state? If we don't set state, It's better practice to pass down the whole ref object so it's always fresh.

I logged out defaultViewRef.current to check what's going on (this is the post editor):

[useBlockProps] defaultViewRef.current at render time: undefined
[useBlockProps] defaultViewRef.current at render time: Window {window: Window, self: Window, document: document, name: 'editor-canvas', location: Location, …}

Those first two renders are undefined, but it looks like the editor triggers a re-render shortly after mount, which then assigns the iframe's Window.

I didn't observe any issues during the initial render, so it works in practice 😄 But possibly incidentally.

I tried setting state, and there are quite a few more renders:

	const [ view, setView ] = useState();
	const defaultViewRef = useRefEffect( ( element ) => {
		setView( element.ownerDocument.defaultView );
		return () => setView( undefined );
	}, [] );

But the re-render happening on purpose coz setView is saying "something changed, re-render."