[jira] [Commented] (CB-5115) On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard
[
https://issues.apache.org/jira/browse/CB-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802704#comment-14802704
]
anchann commented on CB-5115:
-
More info for future people: I hit this problem on iOS8, about half the time by
the time the keyboard is up the input/textarea fields no longer have focus. The
way I solved it is by catching the touchstart event, preventing default action,
and then manually calling focus(). Seems to work reasonably well on iOS8 and
iOS9. Going to push this to production tonight and see if any problems arise.
$("body").on("touchstart", "textarea, input", (e): void => {
e.preventDefault();
$(e.target).focus();
});
> On iOS 7, events are dispatched to wrong elements when taping an input field
> pops the virtual keyboard
> --
>
> Key: CB-5115
> URL: https://issues.apache.org/jira/browse/CB-5115
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Affects Versions: 3.1.0
> Environment: iOS 7
>Reporter: Adrian Vasiliu
> Attachments: test_Cordova-pure-html.html
>
>
> On iOS 7, when a Cordova 3.1 app contains input fields (, ),
> the events such as "focus" and "click" can be dispatched to the wrong element
> when taping the field causes the virtual keyboard to show up.
> Apparently, the event dispatching mechanism is confused by the fact the page
> is pushed by the keyboard showing up: the events are dispatched to the
> element at the coordinate after the push, instead of the element at the
> coordinate of the initial tap gesture.
> Reproduced with Cordova 3.1 using Xcode 5.0 on Mac OS X 10.8.5, running on
> iPhone and iPad simulators and real devices.
> How to reproduce:
> Run on iOS 7 a Cordova 3.1 app using the code from the attached test file.
> The test contains several input elements, and a message area which displays a
> message for each "focus" and "click" events received by the input elements;
> the message includes the id of the element. When tapping an input element
> while the keyboard is not visible, the message shows that the event is
> received by wrong element. Also, the wrong input is focused. Differently,
> when the keyboard is already visible, the events are dispatched to the
> correct element.
> Notes:
> - Reproduced only when *not* using height:device-height in the meta tag, per
> the recommendation in the Cordova 3.1 doc
> (http://cordova.apache.org/docs/en/3.1.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS).
> - Setting KeyboardShrinksView to either true or false in config.xml does not
> matter for this issue.
> - The same test code works fine in a pure webapp in Safari on iOS 7.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-5115) On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard
[ https://issues.apache.org/jira/browse/CB-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128506#comment-14128506 ] Dan Caseley commented on CB-5115: - Info for future people: We hit a similar problem, characterised by the tapped input field ending up under the keyboard after the tap auto-scroll. We found this resolved by iOS 7.1. On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard -- Key: CB-5115 URL: https://issues.apache.org/jira/browse/CB-5115 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 3.1.0 Environment: iOS 7 Reporter: Adrian Vasiliu Attachments: test_Cordova-pure-html.html On iOS 7, when a Cordova 3.1 app contains input fields (input, textarea), the events such as focus and click can be dispatched to the wrong element when taping the field causes the virtual keyboard to show up. Apparently, the event dispatching mechanism is confused by the fact the page is pushed by the keyboard showing up: the events are dispatched to the element at the coordinate after the push, instead of the element at the coordinate of the initial tap gesture. Reproduced with Cordova 3.1 using Xcode 5.0 on Mac OS X 10.8.5, running on iPhone and iPad simulators and real devices. How to reproduce: Run on iOS 7 a Cordova 3.1 app using the code from the attached test file. The test contains several input elements, and a message area which displays a message for each focus and click events received by the input elements; the message includes the id of the element. When tapping an input element while the keyboard is not visible, the message shows that the event is received by wrong element. Also, the wrong input is focused. Differently, when the keyboard is already visible, the events are dispatched to the correct element. Notes: - Reproduced only when *not* using height:device-height in the meta tag, per the recommendation in the Cordova 3.1 doc (http://cordova.apache.org/docs/en/3.1.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS). - Setting KeyboardShrinksView to either true or false in config.xml does not matter for this issue. - The same test code works fine in a pure webapp in Safari on iOS 7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-5115) On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard
[ https://issues.apache.org/jira/browse/CB-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819204#comment-13819204 ] Shazron Abdullah commented on CB-5115: -- Is this related? : http://stackoverflow.com/a/19628776 On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard -- Key: CB-5115 URL: https://issues.apache.org/jira/browse/CB-5115 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 3.1.0 Environment: iOS 7 Reporter: Adrian Vasiliu Attachments: test_Cordova-pure-html.html On iOS 7, when a Cordova 3.1 app contains input fields (input, textarea), the events such as focus and click can be dispatched to the wrong element when taping the field causes the virtual keyboard to show up. Apparently, the event dispatching mechanism is confused by the fact the page is pushed by the keyboard showing up: the events are dispatched to the element at the coordinate after the push, instead of the element at the coordinate of the initial tap gesture. Reproduced with Cordova 3.1 using Xcode 5.0 on Mac OS X 10.8.5, running on iPhone and iPad simulators and real devices. How to reproduce: Run on iOS 7 a Cordova 3.1 app using the code from the attached test file. The test contains several input elements, and a message area which displays a message for each focus and click events received by the input elements; the message includes the id of the element. When tapping an input element while the keyboard is not visible, the message shows that the event is received by wrong element. Also, the wrong input is focused. Differently, when the keyboard is already visible, the events are dispatched to the correct element. Notes: - Reproduced only when *not* using height:device-height in the meta tag, per the recommendation in the Cordova 3.1 doc (http://cordova.apache.org/docs/en/3.1.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS). - Setting KeyboardShrinksView to either true or false in config.xml does not matter for this issue. - The same test code works fine in a pure webapp in Safari on iOS 7. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5115) On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard
[
https://issues.apache.org/jira/browse/CB-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804435#comment-13804435
]
Adrian Vasiliu commented on CB-5115:
Thanks for the investigation. I have also reproduced a different variant of
this misbehavior, which matches more closely the misbehavior that hurts hybrid
apps using Dojo Mobile. For this new test case just as for the initial one, I
have reproduced the issue with an iOS app using a UIWebView without Cordova
(tested on Xcode 5 5A1413, Mac OS X 10.8.5). And for both the initial and the
new test, the issue appears as a regression in iOS 7, since I don't reproduce
when running on iOS 6.
The root cause of the different misbehavior in these two tests might be the
same, or might be different. In doubt, thinking you may want to add this second
test case to a bug submission to Apple, let me describe the second test case:
Same as my initially attached test_Cordova-pure-html.html but with the
following slight CSS modification:
{code}
.msgArea {
height: 100px; /* instead of a percentage */
/* remaining similar as in the initial test case */
}
.clearButton {
height: 30px; /* instead of a percentage */
/* remaining similar as in the initial test case */
}
{code}
With this slight modification, the behavior in iOS 7 is the following:
1/ when touching one of the input element on the top - above the area that will
be covered by the virtual keyboard - the focus and click events are
received by the correct element (the one you touched).
2/ when touching an input element on the bottom - inside the area covered by
the keyboard as soon as it shows up - there is no event (thus, it is not
focused and typing on the keyboard does not fill the input element).
This differs from the behavior on iOS 7 of the initial test, which is that for
any input element - placed inside or outside the area that will be covered by
the keyboard - the events are received by the wrong element. Both tests do not
have this problem on iOS 6.
On iOS 7, events are dispatched to wrong elements when taping an input field
pops the virtual keyboard
--
Key: CB-5115
URL: https://issues.apache.org/jira/browse/CB-5115
Project: Apache Cordova
Issue Type: Bug
Components: iOS
Affects Versions: 3.1.0
Environment: iOS 7
Reporter: Adrian Vasiliu
Attachments: test_Cordova-pure-html.html
On iOS 7, when a Cordova 3.1 app contains input fields (input, textarea),
the events such as focus and click can be dispatched to the wrong element
when taping the field causes the virtual keyboard to show up.
Apparently, the event dispatching mechanism is confused by the fact the page
is pushed by the keyboard showing up: the events are dispatched to the
element at the coordinate after the push, instead of the element at the
coordinate of the initial tap gesture.
Reproduced with Cordova 3.1 using Xcode 5.0 on Mac OS X 10.8.5, running on
iPhone and iPad simulators and real devices.
How to reproduce:
Run on iOS 7 a Cordova 3.1 app using the code from the attached test file.
The test contains several input elements, and a message area which displays a
message for each focus and click events received by the input elements;
the message includes the id of the element. When tapping an input element
while the keyboard is not visible, the message shows that the event is
received by wrong element. Also, the wrong input is focused. Differently,
when the keyboard is already visible, the events are dispatched to the
correct element.
Notes:
- Reproduced only when *not* using height:device-height in the meta tag, per
the recommendation in the Cordova 3.1 doc
(http://cordova.apache.org/docs/en/3.1.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS).
- Setting KeyboardShrinksView to either true or false in config.xml does not
matter for this issue.
- The same test code works fine in a pure webapp in Safari on iOS 7.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5115) On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard
[ https://issues.apache.org/jira/browse/CB-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798240#comment-13798240 ] Shazron Abdullah commented on CB-5115: -- So essentially, this is an iOS 7 issue, not Cordova? Probably need to confirm in a non-Cordova app with just a UIWebView, for iOS 7. Cordova doesn't do anything fancy really. On iOS 7, events are dispatched to wrong elements when taping an input field pops the virtual keyboard -- Key: CB-5115 URL: https://issues.apache.org/jira/browse/CB-5115 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 3.1.0 Environment: iOS 7 Reporter: Adrian Vasiliu Attachments: test_Cordova-pure-html.html On iOS 7, when a Cordova 3.1 app contains input fields (input, textarea), the events such as focus and click can be dispatched to the wrong element when taping the field causes the virtual keyboard to show up. Apparently, the event dispatching mechanism is confused by the fact the page is pushed by the keyboard showing up: the events are dispatched to the element at the coordinate after the push, instead of the element at the coordinate of the initial tap gesture. Reproduced with Cordova 3.1 using Xcode 5.0 on Mac OS X 10.8.5, running on iPhone and iPad simulators and real devices. How to reproduce: Run on iOS 7 a Cordova 3.1 app using the code from the attached test file. The test contains several input elements, and a message area which displays a message for each focus and click events received by the input elements; the message includes the id of the element. When tapping an input element while the keyboard is not visible, the message shows that the event is received by wrong element. Also, the wrong input is focused. Differently, when the keyboard is already visible, the events are dispatched to the correct element. Notes: - Reproduced only when *not* using height:device-height in the meta tag, per the recommendation in the Cordova 3.1 doc (http://cordova.apache.org/docs/en/3.1.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS). - Setting KeyboardShrinksView to either true or false in config.xml does not matter for this issue. - The same test code works fine in a pure webapp in Safari on iOS 7. -- This message was sent by Atlassian JIRA (v6.1#6144)
