Bug 134409 – [iOS][WK2] <select> tapping "next" does not save new picker value

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Joseph Pecoraro]

* TEST:

    <select>
        <option>Cyan</option>
        <option>Magenta</option>
        <option>Yellow</option>
        <option>Black</option>
    </select>
    <br><br>
    <select>
        <option>Red</option>
        <option>Green</option>
        <option>Blue</option>
    </select>

* STEPS
1. Tap the first <select>
2. Move the wheel to a "Yellow"
3. Tap Next in accessory
  => "Cyan" is still selected. Expected "Yellow" to be selected.

[Joseph Pecoraro]

<rdar://problem/17379745>

[Joseph Pecoraro]

So, two potential issues here.

1. We were accidentally not calling endEditing in -_stopAssistingNode in WK2.
  - I think this should always be the case to ensure we call -controlEndEditing which only <select> cares about

2. Calling endEditing in -_stopAssistingNode is too late in this case. It seem in the WK2 model:
  - UIProcess tells the WebProcess to move focus to the next field
  - WebProcess updates the assisted node
  - WebProcess tells the UIProcess to start assisting a new node
  - if the UIProcess at this point says "update the value of the assisted node" it updates the wrong node

So it seems like we should handle -accessoryTab in a special way. We don't want to do everything that stopAssistingNode does (it starts dismissing the keyboard) but we do want the control to endEditing. I say we trigger the endEditing at this point because we know we are going to change focus and run the rest anyways.

Patch to follow.

[Joseph Pecoraro]

Created attachment 234013 [details]
[PATCH] Proposed Fix

[Enrica Casucci]

Comment on attachment 234013 [details]
[PATCH] Proposed Fix

Sounds very reasonable to me.

[WebKit Commit Bot]

Comment on attachment 234013 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 234013

Committed r170554: <http://trac.webkit.org/changeset/170554>