43517 - WE mouseevents in webcontrol disables the webdrag on Edge, Opera and Safari but not on Firef

OS: Windows 8

Xojo: Xojo 2016r1

Steps: add mousedown and mouseup event to a webcontrol that should be draggable, after that the control isn’t draggable anymore on Edge, Opera and Safari but not on Firefox.

The attached program shows it.

Expected Result:
mouseevents shouldn’t interfere with drag on all browsers

Actual Result:
they disable drag on several browsers

Workarounds:
?
?File attached: MouseDown-Up-Event-in-WebDrag.xojo_binary_project.zip

Andre Kuiper Today at 17:38

All this tested on Windows 10 !!

Andre Kuiper Today at 17:43

And on Safari (on windows 10) the second label doesn’t drag the text but the controlID (See picture)
?File attached: Drag_on_Safari_drags_controlID_instaed_of_the_text.png

<https://xojo.com/issue/43517>

These are limitations of the individual browsers.

[quote=260325:@Andre Kuiper]OS: Windows 8

Xojo: Xojo 2016r1

Steps: add mousedown and mouseup event to a webcontrol that should be draggable, after that the control isn’t draggable anymore on Edge, Opera and Safari but not on Firefox.[/quote]

Most of the time, Mouse events are echoed to the WebPage where you can catch them. After verification they are indeed within the boundaries of the control, do what you wanted to do in the control events.

Hi Michel,

The mouseevents aren’t the problem, they keep working but they are somewhat too active because they disable the dragactions.
Greg told above that this is a limitation of those browsers but personally i have more the feeling that the implementation of the sequence of mousedown–startdrag–drag–enddrag–mouseup is somehow getting mixed in the wrong order. I think this because the drag is a html5 activity and the mouseevents are javascript events.

[quote=260464:@Andre Kuiper]Hi Michel,

The mouseevents aren’t the problem, they keep working but they are somewhat too active because they disable the dragactions.
Greg told above that this is a limitation of those browsers but personally i have more the feeling that the implementation of the sequence of mousedown–startdrag–drag–enddrag–mouseup is somehow getting mixed in the wrong order. I think this because the drag is a html5 activity and the mouseevents are javascript events.[/quote]

Instead of using the control mouse event, use the webpage mouseevents, that will prevent the issue.

Nice idea Michel, unfortunately using the mouseevents higher in the chain of controls will disable all mouseevents of controls lower in the chain and therefor also disable the dragaction.

I reported that bug already on october 8th last year and that bug is verified but not solved.
<https://xojo.com/issue/39999>

[quote=260509:@Andre Kuiper]Nice idea Michel, unfortunately using the mouseevents higher in the chain of controls will disable all mouseevents of controls lower in the chain and therefor also disable the dragaction.

I reported that bug already on october 8th last year and that bug is verified but not solved.
<https://xojo.com/issue/39999>[/quote]

Hum. The control receives the event before the page.

That could be the explanation why mouseevents are blocked in controls lower in the chain because the mousedown happens in the control which is expanded/relayed to the parent control and so the implementation of mouseevents in the parent are handled just as if they exist in the child control.

That is why I think catching it in webpage would work.

Unfortunately not.