You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As title. It is as if some non-scrollable part of the UI has programmatically received focus, and clicking into the article does not alter that focus. Even clicking through to a link fails to focus key presses appropriately in the iframe.
Workaround is to search for an article and load it. Then focus is returned to the article and keyboard works again. Workaround for scrolling is to use mouse / scrollbars.
This would be highly disconcerting bug for users without a touchscreen. It's not clear to me at what point this regression crept in.
The text was updated successfully, but these errors were encountered:
After further investigation, this is a non-critical bug in jQuery mode, and more of a critical bug in SW mode. Fortunately SW mode is experimental in the UWP app, and is still very much a minor use case for packaged apps (they are optimized for working fast in jQuery mode).
In jQuery mode, after using the random button or the configuration button, the user must click into the article to use keyboard scrolling, but this consistently works. The user can also select text for copy and paste (a useful function).
In SW mode, however, after using the random button (or config) it is impossible to click into the article to focus it. Therefore the only way of regaining focus on the article is as described in my first post above. It is also impossible to select text with the mouse in SW mode. These things are undoubtedly linked. Mousedown is probably being absorbed by the way clicks are detected in SW mode (for opening new windows) and being swallowed under certain circumstances. It is because of this kind of difficulty that we closed kiwix/kiwix-js#680 in Kiwix JS. 😮
Jaifroid
changed the title
After clicking on configuration or random, occaionally the keyboard becomes unresponsive
After clicking on configuration or random, occasionally the keyboard becomes unresponsive
Jun 7, 2021
Now fixed and publsihed for Service Worker mode (the mode most affected). For JQuery, this will need to await the update cycle. Fix includes eradication of the underlying issue with click capture on the document, and addition of a focus on the iframe window when the Home tab is displayed.
As title. It is as if some non-scrollable part of the UI has programmatically received focus, and clicking into the article does not alter that focus. Even clicking through to a link fails to focus key presses appropriately in the iframe.
Workaround is to search for an article and load it. Then focus is returned to the article and keyboard works again. Workaround for scrolling is to use mouse / scrollbars.
This would be highly disconcerting bug for users without a touchscreen. It's not clear to me at what point this regression crept in.
The text was updated successfully, but these errors were encountered: