Allow parent blocks to specify their block drop zone.

[talldan]

Is your feature request related to a problem? Please describe.
Presently when dragging and dropping into child block lists, the InnerBlocks component acts as a dropzone.

In technical terms, this happens because the block drop zone is implemented in the BlockList component, and uses a reference to the DOM element for the block list:
https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/components/block-list/index.js#L108

Often the block list isn't or can't be styled to take up adequate space for drag and drop operations, and if a block list collapses to zero height (#25911), drag and drop isn't possible at all.

Preferably a block developer is able to specify any element in their block as the block drop zone to maximize usability.

Describe the solution you'd like
The useBlockDropZone hook is almost portable:

const dropTargetBlockIndex = useBlockDropZone( {
		element: ref,
		rootClientId,
} );

If this hook is used in a block edit, the dropTargetBlockIndex it returns could be passed into InnerBlocks:

<InnerBlocks dropTargetBlockIndex={ dropTargetBlockIndex } />

when this prop is passed, InnerBlocks could bypass its own useBlockDropZone hook.

Describe alternatives you've considered
I haven't looked into feasibility, but a supports.customBlockDropZone setting could also be a possibility. When this is present, a ref could be passed into the edit function:

edit( { blockDropZoneRef } ) {
  // ...
  return (
    <div ref={ blockDropZoneRef }>
        // ...
    </div>
  )
}

Which allows a block developer to specify which element should be considered a block drop zone.

[andrewserong]

I've implemented this in #56070. It's currently __unstableDropZoneElement from the perspective of useInnerBlocksProps, so as it's unstable (and I haven't tested using it with container blocks yet), I'll leave this issue open for now.

[andrewserong]

Just sharing a screengrab of the problem that I think this issue is intended to address based on the comment from #56070 (comment). If we add a Cover block and attempt to drag blocks within it, you have to carefully hover over one of the inner blocks — the padding area within the Cover block is not treated as a dropzone, and so if you're dragging within the top or bottom areas of the Cover block, it thinks you want to drag before or after the block, instead of within it:

2023-11-20.15.11.59.mp4

It'll be worth seeing if the new dropZoneElement prop from #56070 helps us address this.

[andrewserong]

Update: I've started a proof of concept over in #56312 that demonstrates that using dropZoneElement via useInnerBlocksProps and passing it a reference to the block's wrapper will fix the issue. Whether or not that's quite the right API for it, it seems a promising direction so far!