* 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.
<rdar://problem/17379745>
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.
Created attachment 234013 [details] [PATCH] Proposed Fix
Comment on attachment 234013 [details] [PATCH] Proposed Fix Sounds very reasonable to me.
Comment on attachment 234013 [details] [PATCH] Proposed Fix Clearing flags on attachment: 234013 Committed r170554: <http://trac.webkit.org/changeset/170554>