[Windows][Built-in Browser] cua_drag emits mouse events but does not start native HTML5 drag-and-drop

Summary

In the Codex Desktop built-in browser on Windows, cua_drag successfully emits pointer and mouse events, but does not initiate a native HTML5 drag-and-drop session for elements using draggable="true".

The same page and equivalent coordinate path work correctly through the Chrome browser backend.

Environment

• OS: Windows
• Surface: Codex Desktop built-in browser
• Browser plugin bundle observed locally: browser/26.721.41059
• Target page: localhost
• Drag source: native HTML element with draggable="true"

Minimal reproduction

~~~html
<div id="source" draggable="true">Drag me</div>
<div id="target">Drop here</div>

<script>
const events = [
"pointerdown", "pointermove", "pointerup",
"mousedown", "mousemove", "mouseup",
"dragstart", "drag", "dragenter", "dragover",
"drop", "dragend"
];

for (const type of events) {
document.addEventListener(type, event => {
console.log(type, event.target.id);
});
}

target.addEventListener("dragover", event => event.preventDefault());
target.addEventListener("drop", event => {
event.preventDefault();
target.textContent = "Dropped";
});
</script>
~~~

1. Serve the page from http://127.0.0.1.
2. Open it in the Codex built-in browser.
3. Invoke the browser drag operation with a multi-point path from the center of #source to the center of #target.
4. Inspect the emitted DOM events and final target state.
5. Repeat the same operation through the Chrome browser backend.

Actual result

Built-in browser:

~~~text
pointerdown: 1
mousedown: 1
pointermove: 66
mousemove: 66
pointerup: 1
mouseup: 1

dragstart: 0
dragenter: 0
dragover: 0
drop: 0
dragend: 0
~~~

The drag command completes, but the element is not dropped.

Chrome backend using the same page and equivalent coordinate path:

~~~text
pointerdown: 1
mousedown: 1
dragstart: 1
drag: 61
dragenter: 3
dragover: 61
drop: 1
dragend: 1
~~~

The target reaches the expected dropped state.

Expected result

Either:

1. cua_drag should support native HTML5 drag-and-drop and produce the normal dragstart → dragenter → dragover → drop → dragend sequence; or
2. the built-in browser should declare that native HTML5 DnD is unsupported instead of reporting a successful generic drag operation.

Why this appears to be an API/backend contract gap

The current drag request contains a coordinate path and modifier keys, but does not expose:

• a drag mode such as pointer versus html5;
• HTML5 DataTransfer / drag data;
• a nativeHtml5Dnd capability;
• a postcondition indicating that a drag session or drop was actually created.

A mouse path alone is not guaranteed to initiate HTML5 DnD. Chrome DevTools Protocol also models mouse input and drag input separately: Input.dispatchMouseEvent versus Input.dispatchDragEvent with DragData.

This does not establish which lower-level primitive the Codex built-in browser currently uses; that implementation detail was not available during diagnosis.

Suggested improvements

• Add an explicit drag mode: mode: "pointer" | "html5".
• Expose backend capabilities such as pointerDrag and nativeHtml5Dnd.
• For HTML5 mode, support drag data and semantic drag/drop dispatch.
• Return whether a native drag session was established, rather than only whether the input path was delivered.
• Add a cross-backend conformance test using a native draggable="true" element.
• Test a complete cycle: successful drop, recovery/reset, and a second drop.

References

• WHATWG HTML drag-and-drop: https://html.spec.whatwg.org/multipage/dnd.html
• Chrome DevTools Protocol Input domain: https://chromedevtools.github.io/devtools-protocol/tot/Input/