Created attachment 306743 [details] [diff] [review] patch removing the items in TB The access key localPath.accesskey in am-server-top.dtd and am-serverwithnoidentities.dtd (both in mail/.../messenger and in suite/mailnews/.../pref) is superfluous: it directs one to the text field, but this text field is not editable. Since there are really a lot of options on this window (too much?), it gets very hard to find suitable letters for the access key in localizations (English has double access keys there as well). Therefore, it would be best just to remove it.
Additionally, the key newsrcFilePath.accesskey probably can be removed as well, for similar reasons.
Created attachment 306753 [details] [diff] [review] just setting them blank Ok, silly me, one cannot just remove them, instead, I made them blank.
seems like the access keys should be removed from the xul as well, instead of just making them blank.
(In reply to comment #3) > seems like the access keys should be removed from the xul as well, instead of > just making them blank. So you do agree that they should be removed in the first place? (Before I start putting more time in this.)
Created attachment 307441 [details] [diff] [review] remove from .dtd and .xul As you suggested, removing them altogether. Also in suite, since they share the mailnews code. Tested, works fine.
To answer Neil's question on IRC: Yes, it makes the most sense to remove them from readonly textboxes (more so than other controls) since these will most likely only be used to copy & paste the path. OK with me.
Patch checked in. Hendrik, please mark as fixed if there's no more changes to be done on this bug. Checking in mail/locales/en-US/chrome/messenger/am-server-top.dtd; /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/am-server-top.dtd,v <-- am-server-top.dtd new revision: 1.10; previous revision: 1.9 done Checking in mail/locales/en-US/chrome/messenger/am-serverwithnoidentities.dtd; /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/am-serverwithnoidentities.dtd,v <-- am-serverwithnoidentities.dtd new revision: 1.4; previous revision: 1.3 done Checking in mailnews/base/prefs/resources/content/am-server.xul; /cvsroot/mozilla/mailnews/base/prefs/resources/content/am-server.xul,v <-- am-server.xul new revision: 1.124; previous revision: 1.123 done Checking in mailnews/base/prefs/resources/content/am-serverwithnoidentities.xul; /cvsroot/mozilla/mailnews/base/prefs/resources/content/am-serverwithnoidentities.xul,v <-- am-serverwithnoidentities.xul new revision: 1.33; previous revision: 1.32 done Checking in suite/locales/en-US/chrome/mailnews/pref/am-server-top.dtd; /cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/pref/am-server-top.dtd,v <-- am-server-top.dtd new revision: 1.44; previous revision: 1.43 done Checking in suite/locales/en-US/chrome/mailnews/pref/am-serverwithnoidentities.dtd; /cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/pref/am-serverwithnoidentities.dtd,v <-- am-serverwithnoidentities.dtd new revision: 1.7; previous revision: 1.6 done
(In reply to comment #7) > Patch checked in. Hendrik, please mark as fixed if there's no more changes to > be done on this bug. Do I need to take any actions to percolate this to l10n?
(In reply to comment #8) > Do I need to take any actions to percolate this to l10n? No, L10n tinderboxen turn orange automatically when a checkin removes/adds string IDs.