[r216] Textbox dragging bug

Problem Description

There seem to be a problem with textboxes and them getting focused when dragging your mouse over them, even when you are interacting with other elements.

When you for instant drag a sprite around the screen and you happen to drag it over a textbox, it will start selecting the text inside the textbox.

It seems broken in the sense that you would expect the program to focus on the sprite being dragged and not starting to select text inside the form controls if these doesn't have focus.

Attach a Capx

https://dl.dropboxusercontent.com/u/109921357/Textbox%20dragging%20bug/Textbox_dragging_bug.capx

Description of Capx

Just contain some textboxes and a sprite with drag/drop behaviour.

Steps to Reproduce Bug

Drag the sprite over the textboxes.

Observed Result

Expected Result

That the focus would stay on the sprite and any mouse interaction with the textbox would be ignored. That selecting text inside a textbox would only happen if the textbox it self have first been activated by a mouse click, and that simply holding down the mouse button and dragging above them wouldn't give them focus.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

Windows 7

Construct 2 Version ID

r216

I doubt this is a bug.

As is outlined throughout the manual with regard to Form elements, they are rendered last above the canvas, so it seems logical that when moving over it, it would be top-most element and get focus.

I doubt this is a bug.

As is outlined throughout the manual with regard to Form elements, they are rendered last above the canvas, so it seems logical that when moving over it, it would be top-most element and get focus.

You might be correct. I believe the reason the form controls act the way they are is because they are web controls or what to say. But you would normally not select content of textbox in a non web control by simply dragging the mouse over it. So whether its possible to change that or whether its considered a bug im not sure of.

But regardless of that problems does occur as you can see in my example when dragging a sprite around and suddenly form controls get focus when you would assume they wouldn't.

So maybe its possible to add an exception or change the textbox so in order to select its content, you have to make an actually click on it to give it focus and not just by dragging the mouse over it, when the button is down. In a normal program that is not considered a mouse click, but again whether its possible or not i don't know, but think it would be a good fix to the already troublesome form controls.

You can avoid selecting the TexBox by simply unfocus it when you drag the sprite:

Sprite| DragDrop is dragging -> TexBox| set unfocused.

But the TextBox is always above the game canvas, so you will drag the sprite along behind the TextBox.

If you want to avoid that, you have to make your own TextBox.

You can avoid selecting the TexBox by simply unfocus it when you drag the sprite:

Sprite| DragDrop is dragging -> TexBox| set unfocused.

But the TextBox is always above the game canvas, so you will drag the sprite along behind the TextBox.

If you want to avoid that, you have to make your own TextBox.

That works fine, guess that is fine enough as a fix

This is tricky to work around - if you type on the comment box on this page, you can still select its text sometimes by dragging from outside the textbox. It even seems to focus the control sometimes, even though the click started outside the control. This kind of browser-default behavior is tricky to correctly disable: if you just say "disable mouse moves", then you can't select text at all inside the control, but trying to define how to say "disable when the click did not originate from this control" requires app-wide pointer tracking with support for mouse, touch and pointer events for cross-browser support, and co-operation between different plugins that need this kind of feature. So it's actually pretty complicated.

I think it's a fairly minor issue that is easy to workaround with that event, but I'll leave the report open in case future refactoring of the runtime can resolve this.

If it helps, here is a tutorial on making your own text box using an offscreen textbox as the actual input.

https://www.scirra.com/tutorials/624/te ... box/page-3

This is tricky to work around - if you type on the comment box on this page, you can still select its text sometimes by dragging from outside the textbox. It even seems to focus the control sometimes, even though the click started outside the control. This kind of browser-default behavior is tricky to correctly disable: if you just say "disable mouse moves", then you can't select text at all inside the control, but trying to define how to say "disable when the click did not originate from this control" requires app-wide pointer tracking with support for mouse, touch and pointer events for cross-browser support, and co-operation between different plugins that need this kind of feature. So it's actually pretty complicated.

I think it's a fairly minor issue that is easy to workaround with that event, but I'll leave the report open in case future refactoring of the runtime can resolve this.

As you say its not the end of the world this issue and there are workarounds. But thought that if it turned out to be a simple fix, it might as well be done. But thanks anyway.

If it helps, here is a tutorial on making your own text box using an offscreen textbox as the actual input.

https://www.scirra.com/tutorials/624/te ... box/page-3

Thanks for that, its a good tutorial. Unfortunately nothing that addresses my particular problem as I actually prefer using the "standard" design rather than a sprite font textbox in this case.

But there are many uses for what is done in that tutorial, so thanks for that.

I believe the behavior is for selecting large portions of a web page to be copied or printed. It selects all it can when dragging over all the text boxes. When you think of it that way, it's obvious why they did it that way.