From the UTest bug report:
---- ACTION DETAILS ----

Action Performed:
1. Log in using iPad
2. Click 'Go to full form' and tap into the body of the new post

or

1. Log in using iPad
2. Open a post to add a comment
3. Try to add text to the comment body by tapping in body text box

or

1. Log in using iPad
2. Open events and create a new event
3. Try add text to the description by tapping into the body text box

Expected Result:
Can add text using default text editor option

Actual Result:
Cannot add text using default text editor, the keyboard never appears after repeatedly tapping into the box. Only the plain text editor seems to work. See attached recording.

Additional Info:
Reproduced issue in the following environments:
Apple iPad (Retina) Wifi - iOS 6.1.3 Safari
Apple iPad (Retina) Wifi - iOS 6.1.3 Chrome

Error Code/Message:

---- ENVIRONMENT ----

Mobile Maker:Apple,Mobile Carrier:Verizon Wireless,Mobile Operating System:iOS,Mobile Major Operating System Version:iOS 6.x,Mobile Model:iPad (Late 2012) Wi-Fi,Mobile Operating System Version:iOS 6.1.3

---- UTEST PROPERTIES ----

uTest Bug Id: 700265
Title: Default text entry box does not accept input from iPad, keyboard does not appear
Status: New

Type: GUI
Frequency: Every Time
Severity: Critical

Product: CM (3.0 nightly)
Test Cycle: Commons 3.0
---- UTEST Attachment ----

Bug700265_IMG_0662.MOV : https://utest-dl.s3.amazonaws.com/1114/1758/28449/null/bugAttachment/Bug...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Zarabadoo’s picture

FileSize
21.25 KB

I have been playing around with this bug, and am able to reproduce. This is likely not as critical as we think, though. One can enter the editing mode, but you have to tap on the already active text to get it to work. When editing an existing post this should be a non-issue. It is only problematic with a fresh node with an empty body. In that case the tap must be on the first line of the field.

issue-2030087-solution.png

Considering the size of people's fingers, it may not be as big of a deal on an actual device.

Zarabadoo’s picture

Assigned: Zarabadoo » ezra-g
FileSize
525 bytes

I found a fix, but it does require making CKEditor use the theme css. To me, this is a plus as the wysiwyg will reflect the styles more appropriately. I have comitted the changes needed to Commons Origins. Attached is a patch to Commons WYSIWYG to enable the setting on a fresh install. An update hook will likely be needed to set it on existing installs.

ezra-g’s picture

Status: Active » Needs review
FileSize
1.07 KB

Thanks, zarabadoo!

Here's #2 with the upgrade path.

Devin Carlson’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
322.96 KB
322.98 KB
163.43 KB
153.7 KB

Tested #3 against a fresh and an existing Commons install. The patch successfully changes the CKEditor profile for filtered_html to use the theme's CSS.

I'm not sure about the non-white background and the lack of spacing between the editor's borders. Are those both by design?

Original body field on the node/add form:
original_node_add.png

With the patch:
updated_node_add.png

ezra-g’s picture

Status: Reviewed & tested by the community » Needs review

I'm not sure about the non-white background and the lack of spacing between the editor's borders. Are those both by design?

They're not by design. Do those happen on non-touch devices as well as the iPad?

Devin Carlson’s picture

Status: Needs review » Reviewed & tested by the community

I just confirmed with Zarabadoo that I was having a local issue with the old CSS getting cached. #3 looks good on both desktop and mobile devices (iPhone/iPad).

ezra-g’s picture

Status: Reviewed & tested by the community » Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.