GNOME Bugzilla – Bug 699857
Press Enter in a text field should finish the edition and move to the next field
Last modified: 2018-05-22 15:04:18 UTC
When editing a text entry in a form, after Enter it is expected to finish the edition of that particular field and, hopefully, to move to the next field. The current behaviour moves the page forward.
Should it move to the next text field, or the next form field iyo?
(In reply to comment #1) > Should it move to the next text field, or the next form field iyo? Next form field. It can be a combobox, checkbox, etc. I think it should be treated as any GUI.
Ok. Hmm. I have some [RFC] patches, that add the functionality. And it seem to work for text fields. Any comments or review would be welcome for the approach. I am not sure how to handle other fields. When pressing enter on a text field and you go to another text field you are ready to start editing. But right now if you are at a text field, press enter and go to a checkbox, that box will be checked. And that doesn't seem right. Maybe we need to draw something to indicate focus on the boxes and an enter moves to focus and another enter selects. Or something. Any and all inputs welcome. Will post patches below. There are two preparatory patches: * one to not reverse the field_mapping_list in ev-poppler, because that will make prev in the list be next in the field. And that messes with at least me. * one to remove unused arguments to ev_view_handle_form_field.
Created attachment 248228 [details] [review] do not reverse field_mapping in poppler
Created attachment 248229 [details] [review] remove unsused arguments to ev_view_handle_form_field
Created attachment 248230 [details] [review] the imlementation of next form when pressing enter
Created attachment 248231 [details] [review] version 2 of next form when pressing enter (this one compiles!)
(In reply to comment #3) > Ok. Hmm. > > I have some [RFC] patches, that add the functionality. And it seem to work for > text fields. Any comments or review would be welcome for the approach. > > I am not sure how to handle other fields. When pressing enter on a text field > and you go to another text field you are ready to start editing. > > But right now if you are at a text field, press enter and go to a checkbox, > that box will be checked. And that doesn't seem right. Maybe we need to draw > something to indicate focus on the boxes and an enter moves to focus and > another enter selects. Or something. Yes, this is because form fields are not accessible with the keyboard yet, there's a bug for that, see https://bugzilla.gnome.org/show_bug.cgi?id=677348 > Any and all inputs welcome. Will post patches below. > > There are two preparatory patches: > > * one to not reverse the field_mapping_list in ev-poppler, because that will > make prev in the list be next in the field. And that messes with at least me. > > * one to remove unused arguments to ev_view_handle_form_field.
I see, I worked a bit more on this patch and it works ok now for text fields and choice fields. The button fields are trickier since they are not widgets. But as there seem to be work in progress on forms, should I abandon this? Should the bug be marked as depending on that bug (or another in that mix) or should it be marked WONTFIX or something else?
This seems closely related to bug 503706, which describes essentially the same feature but using Tab to move to the next field rather than Enter. Should we mark this as a duplicate?
Places I've seen pressing "Enter/Return" moves the cursor to next editable text field? Almost none. In Facebook's Messages interface, pressing enter key sends the typed message and editable field is cleared with cursor waiting to accept new input. That's the closes I can think of. Also, IMO pressing enter to go to next editable field is not intuitive, pressing enter to accept/send data is. Webpages have the behaviour of allowing you to navigate multiple editable text fields with Tab key (and space to select if the field is non-text field), so also do many GTK applications which have dialogs to take user information. I think this bug should be marked 'INVALID'?
Well, another example of an application that accepts Enter would be spreadsheets such as Gnumeric, where you can press Enter to get to the next row. But I agree that Tab seems like a more intuitive key for advancing to the next field. Since there's no such thing as accepting or sending data when filling out a form in Evince, I think we may as well accept both keys (in which case I think we should merge this bug and bug 503706).
(In reply to comment #12) > Well, another example of an application that accepts Enter would be > spreadsheets such as Gnumeric, where you can press Enter to get to the next > row. and it's quite obvious to me now that I don't use office-software >.< Good point, there. > Since there's no such thing as accepting or sending data when filling out a > form in Evince, I think we may as well accept both keys (in which case I think > we should merge this bug and bug 503706). OK by me.
My patch can trivially be changed to go to next on tab instead of the Enter key. In fact I just tried and have such a version spinning. And that makes it work in the same fashihon that Acrobat Reader works. Finish editing on Enter and go to next on Tab. But I don't know the best way forward. Will there be major reworking of how Evince represents forms with the Atk work? And right now this does not work for Checkbuttons, since they are not represented with a widget. So that needs some work. But again I do not now if I should persue this line of implementation or sit tight and see what the changes in forms will be. Carlos? Germán?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/341.