Keyboard shortcuts no longer working on iPad? [fixed in v1.805]

Comments

• jks

  March 2 edited March 2

  So I have a newer iPad now. How exactly is it you're doing keyboard input on an iPad? Because in the newer version of iOS I have I don't see a way in the browser(s) to bring up an on-screen keyboard for anything but form input (e.g. frequency input).

  Are you using like a bluetooth keyboard?

  Update: I guess you must be because it seems the "Magic keyboard" is bluetooth. Something else I need to buy now, lol
• dl3led

  March 2 edited March 2

  Thanks for taking care of this issue!

  I'm using Apple's "Magic Keyboard" (external keyboard/cover combo for iPad-acutally not bluetooth but wired connection). A bluetooth keyboard will probably show the same behaviour. A simple USB keyboard connected to the iPad (via USB adapter) will do, you don't need to buy a Magic Keyboad-(but it's cool to use an iPad with Magic Keyboard together with the KiwiSDR ;-).

  When using external keyboards iPadOS does not show the on-screen keyboard (even if form input is required!), but allows input at any time, therefore using cursor keys, frequency input and keyboard shortcuts was always possible (until it stopped working some time ago). I used it (and liked it very much) for years ;-).
• dl3led

  March 2 edited March 2

  Just guessing from the code (I didn't hook up my iPad to my Mac/Web Inspector yet):

  
  

  openwebrx.js:

  function keyboard_shortcut_init()

  {

  if ((kiwi_isMobile() && !mobile_laptop_test) || kiwi_isFirefox() < 47 || kiwi_isChrome() <= 49 || kiwi_isOpera() <= 36) return;

  ...

  w3_el('id-kiwi-body').addEventListener('keydown', keyboard_shortcut_event, true);

  
  

  
  

  return => The 'keydown' event listener will not be added.

  kiwi_isMobile probably resolves to true because of kiwi_isTouch?

  An iPad can be a touch device and a keyboard device at the same time!

  
  

  kiwi_util.js:

  function kiwi_isMobile() { return (force_mobile || kiwi_isTouch() || kiwi_is_iOS() || kiwi_isAndroid() || (kiwi_isSmartTV() == 'Samsung') || mobile_laptop_test); }

  function kiwi_isTouch() { return kiwi_touch; }

  
  

  document.onreadystatechange = function() {

  ...

  // It seems iPads no longer return "iPad" in the user agent (iPhones still return "iPhone").

  // So use more generic (and recommended) way of determining touch/mobile devices.

  // see: developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent#mobile_device_detection

  // NB: don't use "'maxTouchPoints' in navigator" because very old iPads don't support "in" keyword.

  if (navigator.hasOwnProperty('maxTouchPoints')) {

  kiwi_touch = (navigator.maxTouchPoints > 0);

  } else

  ...
• dl3led

  March 2

  In the meantime I connected the iPad to the Mac and used the debugger to look at the detection logic when running on the iPad.

  Actually maxTouchPoints greater 0 is not the culprit.

  It's the media query for "(pointer:coarse)" that causes kiwi_touch to be set to true, and the existence of "orientation" would cause it to be set to true as well.

  I was able to modify the result using the debugger, and the shortcuts reappeared.

  But there seems to be no way to find out if a physical keyboard is connected.

  How about this change in keyboard_shortcut_init? This way all other kiwi_isMobile() cases remain "mobile", but any macOS system (including iPad, which Apple now considers being macOS as well) will have the keyboard shortcuts.

  --------------------------------------------------------------------------------------

    if ((kiwi_isMobile() && !mobile_laptop_test && !kiwi_isMacOS()) || kiwi_isFirefox() < 47 || kiwi_isChrome() <= 49 || kiwi_isOpera() <= 36) return;

  --------------------------------------------------------------------------------------

  I'm still trying to compile and test this change, but it takes forever on a BeagleBone, and I had to try several times until I realized that kiwisdr.min.js.gz is no longer built from sources locally ;-).
• jks

  March 2

  You're pretty brave if you're going to go looking at that stuff. It's a mess due to the evolution of browser changes (particularly by Apple/mobile) over the years.

  Note that there is a "developer" mode you can use with the Kiwi code that uses the .js files directly. That is, you don't have to do a make install and build the .gz and memory cache files. Just do a plain make and then a "./d" in the top level directory to run (all this over ssh of course). Make sure to disable the background running of the server first via an "msd" (make stop_disable). The compilation of the .cpp/.c files is cached too. So there is only incremental compilation after the first time.
• dl3led

  March 2

  Great, I will try that tomorrow! And I will change to the BBAI64, compilation is much faster there.

  Meanwhile I found shortcuts already work again using this patch, but direct frequency input is missing.
• jks

  March 2

  Yes, you will find all that code interacts badly with other parts of itself. Lots and lots of corner cases. And lots of blame to go around. Evolving web standards (just look at how bad the MDN (Mozilla developer network) documentation has become). My bad coding practice of "doing just enough to make it work" because I have 3000 other things to get done, etc.
• dl3led

  March 4 edited March 4

  I see what you mean--just spent two days looking at the sources and 120 km thinking while riding my bicycle ;-) ...

  Having no framework that takes care of all the details is probably a challenge and requires a lot of work. On the other hand it allows you to create a web gui that's really outstanding!

  Thanks for the hints regarding ./d - I remember having used it 5 years ago when I wrote an extension, but almost forgot about it. It's really much faster (especially together with the BBAI64) and much easier to handle in the debugger. I also tried make xc, but some things seem to be not up to date (Debian 11?).

  I tried to find a lean solution for my problem that will (hopefully) not break your mobile detection logic. It has two part: one to be able to override the default ('mobile' on the iPad) using the URL option 'desktop' and using the 'desktop' gui (which works fine on an iPad Pro), and a second one where I managed to use the 'mobile' gui, but enable keyboard shortcuts and frequency entry anyway.

  You can see the diffs on Github: https://github.com/marzusch/KiwiSDR.git, branch dl3led-develop

  https://github.com/jks-prv/KiwiSDR/compare/master...marzusch:KiwiSDR:dl3led-develop

  The first change (force_desktop in kiwi.js and kiwi_util.js) can't possibly break anything. The second change (in openwebrx.js) is currently limited to kiwi_isMacOS and limited to the iPad's/site's "Request Desktop Website" setting-which is, however, the default, but can be switched to "Request Mobile Website". And so far I only tested Safari (on iPad and Mac).

  And there is a problem remaining (not new, it is also there in 1.804): when editing other input fields (e. g. "Your name or callsign" in the top area), when finishing the edit with Enter the field flashes, but the focus remains in this field. When using the 'mobile' gui without keyboard shortcuts, it is not as severe (the cursor stays in the field and the on-screen keyboard stays open), but when using the physical keyboard any shortcuts that follow will go into the name field. To get out ot fhe field it is necessary to click on the frequency input field.

  It seems that the 'mobile' flag in freqset_select causes w3_field_select not to change focus and selection, but only apply blur (which I cannot see on the iPad). This should better be fixed before applying the second change (the first being independent). But I don't understand the intention of the code in freqset_select/w3_field_select yet.

  Let me know what you think about the proposed changes... ;-)
• jks

  March 4 edited March 4

  1) I have not kept the XC (cross-compile) stuff current because I don't use it. What I do is first compile on my Mac to get the syntax errors out. Then compile on a BBAI using "ma" to get -O1 (faster compile, better gdb tracebacks) and the Clang address sanitizer.

  2) My bluetooth keyboard shipped today, so I can start to look at this soon.

  3) A few days ago I fixed the problem with the popup keyboard not getting dismissed after use of the "return" key in fields (e.g. name/callsign field). Now that I have a more modern iPad and can look at these issues more carefully. I'm also now turning off auto capitalize, auto correct and auto complete that more recent iOS and Safari versions impose.
• dl3led

  March 9

  Thanks a lot for bringing back keyboard shortcuts in v1.805!

  Tested with Apple's Magic Keyboard on the iPad Pro.
• ww6d

  March 10

  Shortcuts also working with my iPad Air and a Logi keyboard. Thank you!

  73, Doug WW6D