1. Jun 15, 2022
  2. Jun 14, 2022
  3. Jun 13, 2022
  4. Jun 11, 2022
  5. Jun 10, 2022
  6. Jun 08, 2022
  7. Jun 07, 2022
  8. Jun 06, 2022
  9. Jun 05, 2022
    • Marc Durdin's avatar
      chore(web): add BrowserStack to command-line · 6340a59d
      Marc Durdin authored
      6340a59d
    • Marc Durdin's avatar
      chore(web): switch on additional BrowserStack reporting · f521b6ce
      Marc Durdin authored
      Per support case with BrowserStack, am turning on deeper
      reporting for BrowserStack-based testing in karma.
      f521b6ce
    • Marc Durdin's avatar
      chore: add 14.0 entries to beta HISTORY.md · 949f2cf4
      Marc Durdin authored
      949f2cf4
    • Marc Durdin's avatar
      fix(android): check index validity in getCurrentKeyboardInfo · 958fbd3e
      Marc Durdin authored
      This fixes crash reported as #6703. This issue was first reported in
      14.0.282-stable. I have done a careful review of changes in 14.0.282
      (and 14.0.281) but have been unable to find any changes that could have
      bearing on this.
      
      The basic issue is that there appears to be some circumstances where
      `KMManager` thinks that it has a keyboard loaded (ref
      `SystemKeyboardLoaded` variable), but `KMKeyboard.currentKeyboard` is
      still `null`.
      
      The crash has been reported for only a very small set of users, 119 at
      time of fix, but average reports per user is over 100. As is usual with
      this type of thing, a small fraction of those users are reporting the
      majority of crashes. I have not found any real commonality across the
      error reports -- they are geographically dispersed, across multiple
      device types and Android versions.
      
      Note that this addresses the error at hand but as I am unable to
      reproduce the issue, does not necessarily address the root problem, so
      there may still be other issues reported even after this is fixed.
      
      A longer-term refactor would eliminate `SystemKeyboardLoaded` because
      from what I can tell, we should always be able to determine that from
      the state of `KMKeyboard.currentKeyboard`. However, the state
      entanglement is a lot deeper than just those two variables, with cross
      references to keyboard indexes between `KMManager` and `KMKeyboard`
      which need to be resolved (`KMKeyboard` should *never* refer to
      `KMManager`).
      958fbd3e
  10. Jun 04, 2022
  11. Jun 03, 2022