Open Bug 1904356 Opened 3 months ago Updated 3 months ago

Figure out why the content process doesn't see the mouse-up event on the content process in X11 in the test-case for bug 1901764.

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

People

(Reporter: emilio, Unassigned)

References

Details

I'm not sure why, but having the anonymous text node as the event target makes the content process (well EventStateManager at least) not see the mouseup event...

Masayuki, do you have any idea? I'm fairly baffled at that but I can't dig much into it right now.

I don't know, but I guess that it's consumed by unexpected capturing or DnD session. Edgar, do you have any ideas?

Flags: needinfo?(echen)

This mouseup happens before the drag session starts, and it happens only if you hit the text, not if you hit the <select> itself (e.g. the padding or the arrow button)

Hmm, the target is considered here. However, looks like there is no ifdef. Is the <select> structure different only on X11 build? I guess, no...

No, that's the puzzling thing

When I debug on both Windows and X11, capturingContent here is set to <memupopup>. Then, eventTargetData.mFrame is computed to the primary frame for the (probably) right target, <browser>, once here. However, it's reset to the the primary frame for <menupopup> here. So, eMouseUp shouldn't be dispatched in the content process even on Windows.

Then, I check the behavior on Windows, then, I don't see eMouseUp reached into the content process even on Windows. Did you misunderstand the cause of bug 1901764?

Flags: needinfo?(echen) → needinfo?(emilio)

The way I was approaching this was checking wayland vs x11 (or x11 with and without the fix for bug 1901764). In the working case, I see us hitting this codepath on the content process...

Flags: needinfo?(emilio)

I'm still not sure the platform differences, though.

When you press on the text in the <label>, eventContent here is set to the text node. When you press on the button in the <select>, the eventContent is set to the <select>.

Then, DetermineDragTargetAndDefaultData is called to consider targetContent. Then, nsContentAreaDragDrop::GetDragData is called and finally, DragDataProducer::Produce() is called.

In DragDataProducer::Produce(), it returns "cannot drag" when the drag target is <select> because it's a non-<object> form control. However, it's the text node in the native anonymous subtree, it returns "can drag" as usual. Therefore, when you press the button in <select>, EventStateManager cannot find a proper drag target and stop starting to drag. However, when you press the text, it'll reach this loop to find a draggable target in the flattened tree. Then, this loop returns draggable element in the parent tree.

So, I think that this tree should stop the native anonymous subtree boundary and/or parent non-<object> form control at least.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.