I am testing my CodenameOne app on the iOS simulator.
It is good practice to test on the main iOS versions.
My app has a BrowserComponent as main interface, where a list of Frames is displayed.
Text inside the frames is not selectable. This is ensured by means of
iframe.style.pointerEvents="none";
Mouse events are managed to address single press and long press. It is accomplished by means of detecting the events
"touchstart"
and
"touchend"
and computing the time interval. Javascript callbacks are used.
(also "touchmove" is detected to cancel some events so just "pure" touches are detected)
This works fine in the CN1 simulator, Android devices, and
on iOS simulator with iOS 10, iOS 11, iOS 14
but
it does not work on
iOS 12. iOS 13
What happens is that the mouse events are consumed by the BrowserComponent in such a way that the selection handles appear and the text is selectable.
I had to reinvent the wheel because I am using this CN1 cross-platform tool.
There is also an opened issue:
https://github.com/codenameone/CodenameOne/issues/3378
it is why I am not using "mousedown" and "mouseup" events. But it is not bad to use "touch" events on mobile devices.
(Furthermore I have to say that those "touch" events are useful also in the SwiftUI version, that uses WKWebView, to manage the mouse events as my app needs. It is because I have to use the same Javascript code in both apps.
But there is not the "selection handles appearing" issue with WKWebView. It is only tested on iOS 14, so I cannot say more about that.)
Now it does not work on iOS 12, 13.
I have a SwiftUI version of my app for iOS 14. So the CN1 version was mainly intended for older versions. If iOS 12 and 13 are "gone", it is not useful to publish it just for iOS 9,10,11, I think.
What's wrong with iOS 12, 13 with CN1? Has it special issues with some major changes in those OS versions that were not addressed?
If it is fault of the flaky BrowserComponent on the iOS simulator, it also has to be considered that the mouse events handling works on iOS 14, 11, 10.
So will it be flaky also on the real devices?
How to solve the issue?
Related
I have implemented reading the touch force for haptic touchscreen as per https://developer.mozilla.org/en-US/docs/Web/API/Touch/force
If I test in chrome debug tools on a PC (set to mobile) then it will register the force as 1 (as far as I can tell there's no way to simulate a different pressure). So I know the code it correct.
However on my iPhone XR which does have a haptic screen it always registers as 0.
The compatibility table says Safari on iOS support it, and I haven't been able to find anything that says you need to request the user permission for the feature (like you would with device orientation).
Any ideas why it isn't working?
on caniuse you have more details on support for iOs Safari, please check your safari iOs version is >= 14.5.
It used to be (before iOS 8) that Safari couldn't natively animate on scroll, you had to stop scrolling to see the animations. Safari solved that issue, but when accessing the same website on Chrome (running in iOS) the issue persists. I read that chrome hasn't yet updated this on iOS. I know that it works great on Android... so... Is there a way to test for this "feature" either with modernizr or other js? I would like to disable animations on scroll if they are not supported. I've been able to accomplish this by checking which browser the user is using, but it would be easier if I could just check whether the functionality is available.
Before iOS 8, iOS would pause painting while the user was scrolling. This behavior was discontinued for applications using WKWebView but remains for browsers using UIWebView — this is why you only see the old behavior for certain third-party applications.
One approach is to detect whether your page is loaded inside WKWebView or not. An answer to another question suggests testing for indexedDB support. indexedDB is the only HTML5 feature difference between the WKWebView and UIWebView.
The snippet from the other answer suggests how to do this:
if (navigator.platform.substr(0,2) === 'iP'){
//iOS (iPhone, iPod or iPad)
if (window.indexedDB) {
//WKWebView
}
}
In Safari Mobile on iOS <8, all Javascript was paused while the user was scrolling. Since the release of iOS 8, this is no longer the case, as you can read here:
http://developer.telerik.com/featured/scroll-event-change-ios-8-big-deal/
This is great news. Executing Javascript while scrolling (if done right), opens the possibility for many usability enhancements (like sticky menus) and effects (like parallax).
Is there a way to get the same thing in Chrome Mobile on iOS?
The same website states that the first mobile browser that supported live scroll events was Chrome on Android 4.0. If that's the case, why is it still disabled in the newest Chrome on iOS?
This might be the answer:
https://code.google.com/p/chromium/issues/detail?id=423444
If the new Javascript handling is tied to the new Nitro Javascript Engine used in Safari Mobile (and in WKWebView), then we will have continuous scroll events in Chrome Mobile as soon as they switch to use WKWebView instead of UIWebView.
EDIT: As of version 48.0.2564.87, Chrome uses WKWebView on iOS, and continuous scroll events are working!
In a standalone web-app launched from homescreen, on iOS 8.1(8.0),
touch events (touchstart, touchmove, touchend) are not firing on inputs/textareas, but on the same device in Safari they are.
I've tested the same web-app on iOS 6 and everything works as expected.
Has anyone encountered the same problem and found workaround for this issue?
Maybe there is official bug report? Unfortunately, I've found nothing on this subject.
Seems that touchevents in a standalone web-apps launched from homescreeen are back with iOS 8.1.3
:-)
In a web-app, on iOS 8.1, touch events (touchstart, touchend, etc.) don't seems to be transferred to iFrames, but on the same device in Safari they are.
I tested the same web-app on iOS 7 and again, the touch events are transferred to the iFrame perfectly. So basically, the problem seems to be directly related to iOS 8.
Unfortunately, I didn't found any documentation on the subject.
Anyone have encounter the same problem, found a workaround or know if there is an official bug report?
Thanks