In iPad: Combo boxes do not open selections #2571
Comments
|
Note: We are using the new class BrowserComponent of CN1. |
|
We need sample code that reproduces the issue and ideally screenshots |
|
We are initially attaching images which evidence the problem: The first image was taken from the APP (downloaded from App Store) running on iPad (iOs version 12.0) and shows a simple form containning just one select component: When we tap the selection nothing occurs: The second image was taken from the same APP (downloaded from App Store) running on iPhone 6s (iOs Version 12.0) and shows the same simple form containning just one select component: When we tap the selection the options are presented correctly for selection: We´ll next work on a simple project do help isolationg the problem. Thanks for first return. |
|
Is that with a web UI? |
|
The link bellow has a simple project for diagnosis. |
|
I found multiple mentions of a problem related to select in newer versions of iOS e.g. https://forums.developer.apple.com/thread/84585 @shannah One of the suggestions was to migrate to |
|
If that migration to WKWEBVIEW will be compatable with the new CN1 Bridge-Java-JavaScript-API we think this approach is valid. |
|
WKWebview is the way to go long-term. But there will likely be some compatibility hiccups. It enforces CORS where UIWebView did not, and it apparently has issues with file:// URLs, so we would need to embed a local webserver... I won't know the full extent of the issues until I implement it. |
|
In that case we would probably need to make this optional. Ideally in runtime so a developer can decide. If not maybe as an |
|
This issue is related to z-layering. I can reproduce it on both iOS 11.4 and iOS 12.0.1 on my iPad Air 2. If I switch off Z-layering, the test case works. Looking into it further to see if I can find a fix. |
This turned out to be an issue with the way we were doing Z-Layering. When adding a peer component, we were adding a peer components UIView to the parent of the root view. Unfortunately, this technically places it outside the view hierarchy - even though it appeared to work. Resolved the problem by instead re-rooting the view hierarchy with a new UIView above the previous EAGLView. There were some places where the view controller (CodenameOne_GLViewController) would call self.view and expect that it would be the EAGLView. This can no-longer be assumed. If there have been any peer components added, then self.view will return the new UIView root (the parent of the EAGLView). To help with this, I added a new eaglView method in CodenameOne_GLView controller which will always return the EAGLView. I have swapped out all of the places where an EAGLView was explicitly assumed via cast. It is possible that there are other situations where it is implicitly assumed, but we'll have to squash those as we find them. Also added a macro EAGLVIEW for [[CodenameOne_GLView Controller] instance] eaglView] for convenience. Tested with a few different apps in test suite so far and appears to not have broken anything - but this is a pretty low-level change so it could have far-reaching effects.
This issue occurs only when running on iPad. The same build (published on APP Store) runs correctely on iPhone´s.
We´ve tested on iPhone 6s in versions 11.4.1 and 12.0 and it runs correctely.
In iPad Mini running same versions 11.4.1 and 12.0 the bug occurs.
The text was updated successfully, but these errors were encountered: