Borowser Widget Blocking Keyboard

If you find an issue in LiveCode but are having difficulty pinning down a reliable recipe or want to sanity-check your findings with others, this is the place.

Please have one thread per issue, and try to summarize the issue concisely in the thread title so others can find related issues here.

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

Post Reply
TR-i
Posts: 9
Joined: Fri Jul 21, 2006 4:06 am

Borowser Widget Blocking Keyboard

Post by TR-i » Thu Aug 26, 2021 12:47 am

LC Indy 9
MacBook Pro

Create a new stack and place a browser widget on the first card. Get a beep whenever a key is pressed on the keyboard. onKeyPress in main stack is not triggered except for escape key. No keys are passed to Javascript in the browser except backspace.

stam
Posts: 702
Joined: Sun Jun 04, 2006 9:39 pm
Location: London, UK

Re: Borowser Widget Blocking Keyboard

Post by stam » Thu Aug 26, 2021 12:20 pm

Not sure if that is a bug?

If you add a text field to the stack the issue disappears, even if the field doesn't have the focus.
I suspect the browser object does not respond to keystrokes directly and you need to add something that will.

I think possibly people show/hide the browser in circumstances where this will be an issue.
Then again i have no real experience with this, so others may chime in!

Stam

TR-i
Posts: 9
Joined: Fri Jul 21, 2006 4:06 am

Re: Borowser Widget Blocking Keyboard

Post by TR-i » Thu Aug 26, 2021 9:29 pm

I suspected it was something dopey like that- just needed to hear it from someone.

You'd expect that keyboard events would go to the stack before the widget, especially if the widget is going to eat all of them.

TR-i
Posts: 9
Joined: Fri Jul 21, 2006 4:06 am

Re: Borowser Widget Blocking Keyboard

Post by TR-i » Thu Aug 26, 2021 9:44 pm

Also, just tried adding an input field and apparently it does require focus for the beeping to stop. Back to the drawing board...

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7809
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Borowser Widget Blocking Keyboard

Post by dunbarx » Tue Aug 31, 2021 2:59 pm

Also, just tried adding an input field and apparently it does require focus for the beeping to stop.
What is "onKeyPress"?

Anyway, do you mean that you have, say, a mouseUp handler in the card or stack script that beeps if you click somewhere on the card, but does not beep if you click on the widget?

I have never used a widget, but I am not surprised that it is trapping common events. For example, if you invoke the beeps with any sort of "mouse-like" message, like "mouseUp", mouseDown" or "mouseStillDown", clicking on the widget seems to trap them. But if you use "rawKeyDown", for example, the message passes through the widget just fine.

I cannot imagine how adding another control to the card could possibly have an effect of any kind on the message path through the widget itself.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6174
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Borowser Widget Blocking Keyboard

Post by jacque » Tue Aug 31, 2021 7:05 pm

I don't see that problem, I have a browser widget in use on a card which loads a web form from the internet. I can type into the form and submit it.

In the widget's property inspector, is "allowUserInteraction" selected?
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

TR-i
Posts: 9
Joined: Fri Jul 21, 2006 4:06 am

Re: Borowser Widget Blocking Keyboard

Post by TR-i » Wed Sep 01, 2021 2:03 am

In this instance I am not using any HTML controls. Instead, I am drawing to the screen with a Javascript library that displays WebGL.

To reproduce, start Livecode, create a new stack with a browser instance in it, run the stack and give it focus, then type away and enjoy the beeping. Mouse events do not cause any beeping.

Also, put a rawKeyDown handler anywhere you like- no keyboard events will reach it while the browser widget has focus.

And yes, ‘allowUserInteraction’ is on.

Post Reply

Return to “Bug Triage”