After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 261239 - TAB moves focus to unexpected places in Mailing Address tab of Contact Editor
TAB moves focus to unexpected places in Mailing Address tab of Contact Editor
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
2.6.x (obsolete)
Other All
: Normal major
: Future
Assigned To: Devashish Sharma
Evolution QA team
: 261366 261612 266862 270157 304424 337884 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-07-07 12:54 UTC by Andrew Cowie
Modified: 2006-08-17 08:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (78.27 KB, patch)
2005-09-08 07:58 UTC, Devashish Sharma
none Details | Review
TAB focus corrected. (116.29 KB, patch)
2006-08-09 11:36 UTC, ushveen kaur
none Details | Review
TAB focus corrected. (116.29 KB, patch)
2006-08-09 11:37 UTC, ushveen kaur
none Details | Review
Tab focus corrected. (116.72 KB, patch)
2006-08-10 08:52 UTC, ushveen kaur
none Details | Review
Some layout issues were there in the previous patch.All issues solved now. (117.56 KB, patch)
2006-08-11 03:42 UTC, ushveen kaur
none Details | Review
Resubmitted. (122.10 KB, patch)
2006-08-14 07:07 UTC, ushveen kaur
committed Details | Review

Description Andrew Cowie 2004-07-07 12:54:18 UTC
Situation: entering a Mailing Address tab of the Contact Editor in the
Contacts [addressbook] component. Two weirdo happenings:

1) When City is focused, and user presses TAB, the focus goes *backwards*
to the Address field. Down to Zip/Postal would make more sense.

2) When the "State/Province" field is selected/focused, and then user
presses TAB, the focus would logically go down to the next [as vertically
arranged] field, Country. Instead, focus goes *diagonally backwards* to PO Box.

Both are quite jarring.

AfC
Comment 1 Tino Meinen 2004-07-16 01:08:25 UTC
*** bug 261612 has been marked as a duplicate of this bug. ***
Comment 2 Tino Meinen 2004-07-16 01:16:10 UTC
Additional Information:
Pressing Shift-Tab, lets you move through every entry field in the
dialog, but in the opposite direction. So starting with the cursor in
the field for Addres, the field City is reachable just by using the
keyboard, but it's a drag to go through every field of the dialog just
to reach the next entry

There's IMHO no reason why tabs are neccesary in the Address field.
'Enter' gives a newline in the entry box, so people can have
flexibility in designing wierd address fields if they like.
Expected behaviour is moving to the next entry field upon Tab.

Giving a Tab in the City field, moves the cursor back again into the
Address field! (I would have just filled that in after City wouldn't I?)
Comment 3 Gerardo Marin 2004-10-28 20:01:01 UTC
*** bug 266862 has been marked as a duplicate of this bug. ***
Comment 4 André Klapper 2005-03-24 15:02:09 UTC
still valid in evolution-2.2.0.0.200503210410-0.snap.ximian.10.1;
retargetting to 2.3.
Comment 5 André Klapper 2005-03-24 15:31:39 UTC
*** bug 261366 has been marked as a duplicate of this bug. ***
Comment 6 André Klapper 2005-06-14 13:13:28 UTC
in order to destroy the UI component (as discussed with jpr, dobey, and nags),
changing component to contacts.
Comment 7 André Klapper 2005-07-16 17:17:06 UTC
*** Bug 270157 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Cowie 2005-07-17 04:44:09 UTC
Over one year elapsed. A simple bug which makes the data entry in the contact
editor rediculously annoying is *still* unresolved. <sigh>.

Oh, and I agree, TABs should not be allowed in the address field. It should move
the cursor to the appropriate next field.
Comment 9 Srinivasa Ragavan 2005-07-18 07:09:42 UTC
I feel, Address, City, Zip, State, PO, Country should be the right sequence.
Comment 10 Calum Benson 2005-07-28 10:40:33 UTC
Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.
Comment 11 Sushma Rai 2005-08-27 10:06:38 UTC
*** Bug 304424 has been marked as a duplicate of this bug. ***
Comment 12 Devashish Sharma 2005-09-08 07:58:25 UTC
Created attachment 51946 [details] [review]
Patch

This patch solves almost all the issues except that the default focus is not in
the right place.
Comment 13 Srinivasa Ragavan 2005-12-20 13:17:16 UTC
Devasish, hmm this patch is not right. It just does a hack, so that Shift-Tab doesnt work on text view, C+PageDown/UP doesnt work and so many other violations. I guess, if we find the root cause for crude tab order, that will be the great one, instead of this fix. 

We could take this if it had fixed the issue, but it solves a part and introduces a lot. So lets try to find the root cause of this.
Comment 14 Jeremy Cook 2006-01-13 01:14:55 UTC
(In reply to comment #9)
> I feel, Address, City, Zip, State, PO, Country should be the right sequence.
> 

I disagree with this.  My preference:  Address, City, State, Zip, Country.  PO Box can be eliminated completely, as this information can be place in the Address box.
Comment 15 Andrew Cowie 2006-01-13 01:36:10 UTC
I concur with Jeremy at #14, especially about discarding PO Box - although that's really a separate issue which needs its own bug as removing the field would require evolving any existing data stores.

For now, just having TAB skip the PO Box field would be good.

But otherwise, yes, Address:City:State:PostalCode:Country shold be the tab order and (more to the point) the field layout.

18 months elapsed and counting!

AfC
Comment 16 André Klapper 2006-04-10 12:23:29 UTC
*** Bug 337884 has been marked as a duplicate of this bug. ***
Comment 17 Richard Laager 2006-04-10 17:28:37 UTC
I think the severity on this should be raised. This makes it really difficult to efficiently enter contacts, as it makes using the keyboard essentially useless.
Comment 18 Andrew Cowie 2006-04-11 01:08:23 UTC
Good idea. "Essentially useless" is how I feel about it to.

So much so the only reason that I'm still struggling through with Evolution's contact editor anymore is that people are writing language bindings for evolution-data-server, and sooner or later I'll be able to use something else to fix up all those records I've already created!

But you're right, the contact editor is so hard to use as to make it "otherwise difficult/useless to use." so that's "major", isn't it?

evolution-hackers, I know you're busy with tasks to create wonderful new features, but its the little things that make an application useable. This bug has been bumped from next release to next release time after time. Can you not find it in your hearts to fix this? How about by 2.6.1, huh?

AfC
Comment 19 Calum Benson 2006-04-26 17:07:12 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 20 ushveen kaur 2006-08-09 11:36:47 UTC
Created attachment 70540 [details] [review]
TAB focus corrected.
Comment 21 ushveen kaur 2006-08-09 11:37:56 UTC
Created attachment 70541 [details] [review]
TAB focus corrected.
Comment 22 ushveen kaur 2006-08-10 08:52:17 UTC
Created attachment 70624 [details] [review]
Tab focus corrected.
Comment 23 ushveen kaur 2006-08-11 03:42:09 UTC
Created attachment 70687 [details] [review]
Some layout issues were there in the previous patch.All issues solved now.
Comment 24 André Klapper 2006-08-13 19:37:10 UTC
ushveen, is stuff like

<property name="label" translatable="yes">	       _Country:</property>
<property name="label" translatable="yes">	         _City:</property>
<property name="label" translatable="yes">  _State/Province:</property>

really necessary or is there a way to not abuse tabs/whitespace for layout issues?

there has not been any tabs/whitespace abuse before in that file and i'm not inclined to accept it, it's bad style. note that in the translators' po files, the string "	         _City:" will be added. this cannot be the best solution.
Comment 25 ushveen kaur 2006-08-14 07:07:35 UTC
Created attachment 70851 [details] [review]
Resubmitted.
Comment 26 Srinivasa Ragavan 2006-08-14 07:12:41 UTC
Andre, I agree, the white spacing is not a good solution. But I dont think it is possible to do it without this. This should be removed when we redesign this dialog. Ive asked her to resubmit, with white spaces in the non-translatable label.
Comment 27 Srinivasa Ragavan 2006-08-17 08:08:18 UTC
Fixed to HEAD. Should be part of 2.7.92(?)