Summary: | [iOS][WK2] <select> tapping "next" does not save new picker value | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> | ||||
Component: | WebKit2 | Assignee: | Joseph Pecoraro <joepeck> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | enrica, joepeck | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Joseph Pecoraro
2014-06-27 13:42:08 PDT
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> |