Rationale in bug 411929 comment 86.

Also, if we do this, do we want to change the entity name to make everyone aware of the change, or do we want this to be English-specific?

When filing bugs for triage, please don't just reference other bugs. This bug should be self-contained so that we can actually work off it. To paste comment 86 by Alex in here: Ok, that makes considerably more sense. I think we should give Private Browsing the P access key. In addition to being a more direct menu access key, anyone who was previously making regular use of the clear private data window will likely want to leverage Private Browsing, under the theory that it isn't really about when the data was removed (now preemptively instead of retroactively), but that the user wants to achieve privacy. The first time they invoke private browsing using the muscle memory of trying to get to a different part of the interface they might be slightly confused or frustrated with the change, but overall they should be able to adapt to a better model of dealing with privacy (going off the record, instead of shooting the reporter).

My current thinking is to post about the rationale for this change in .l10n, and to make this change without a keychange. Rationale: - B works - P is better - a key change wouldn't actually convey why P is better than B - the better key might already be chosen in a locale, or not be available, making this a noop anyway We might at some point between b3 and RC 1 do another mxr search and CC the remaining folks with B on this bug, or CC firefoxl10n@hotmail.com right away when we decide what to do. That said, I don't have the full context, and comment 2 doesn't fully enlighten me, why we have chose B at one time over P. Conflict with Fx3's "Clear Private Data..."? Did we actually have both menu items in parallel at one time? Or is this just on whether muscle memory hurts or wins?

(In reply to comment #3) > That said, I don't have the full context, and comment 2 doesn't fully enlighten > me, why we have chose B at one time over P. Conflict with Fx3's "Clear Private > Data..."? Did we actually have both menu items in parallel at one time? Or is > this just on whether muscle memory hurts or wins? Back when I started to work on the private browsing feature about a year ago, we did have "Clear Private Data..." in the Tools menu, so I chose B as the accesskey, and apparently stuck to that. I also believe that when landing bug 411929, we still did have that menu item, so actually no-one thought of changing the access key. Regarding the muscle memory thing, I agree that it would break it for those used to the old menu item, but given the prompt we show by default when entering the PB mode, and the fact that in the long run, those users will get accustomed to the new behavior, and also that keyboard users may have been more used to Accel+Shift+Del which we are not breaking, I vote to do this without changing the entity name.

Actually, here's the proof of why we landed the B accesskey: <https://bugzilla.mozilla.org/attachment.cgi?id=345852&action=diff#a/browser/locales/en-US/chrome/browser/browser.dtd_sec2> :-)

Comment on attachment 362278 [details] [diff] [review] Patch Not sure why you requested review from Axel, this won't impact other locales.

Sorry, Mike, putting this back on the late-l10n tracker, for the following reasons: - The reason why we change this accesskey now probably exists in localizations, too. I.e., there used to be a conflict, which is now resolved, and the new accesskey is chosen to follow a different semantic. - There are a flock of locales without keyboards that use en-US accesskeys, and would benefit. - Any check-in that triggers builds raises the eyebrows of the community. It's not that we should do something as severe as changing the key name, but we should include this change in our outreach of string changes towards 3.1 final.

Sure, okay, that's a more liberal version of late-l10n than I think we've used in the past, but it's up to you. I'm still going to go ahead and approve it though, since I think that there's no actual harm being done here. We've changed accesskeys without flagging them for past releases, since I don't think the semantic of the string is changing, we're just using something that's a better fit now that we can.

Comment on attachment 362278 [details] [diff] [review] Patch we should get this in for b3

http://hg.mozilla.org/mozilla-central/rev/cdfbe284c207 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/729c493cb0c2

Verified fixed with: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090301 Minefield/3.2a1pre Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20090301 Shiretoko/3.1b3pre

https://litmus.mozilla.org/show_test.cgi?id=7573 added to Litmus.

Marcia, this is about the access key inside the tools menu and not about the keyboard shortcut. The shortcut should already be covered in other Litmus tests AFAIR. But should we really test the access key? I don't think so. We don't do this for all the other menu entries.

Posted to http://groups.google.com/group/mozilla.dev.l10n/browse_frm/thread/d8481810d7f85375# to get localizers alerted to pick this up. Lot's of "B" in mxr.

We actually did not have a Litmus test for it. Because of the regressions that happened on the Mac after Leopard was shipped (and the differences between Tiger and Leopard that were noted by the [keyhell] status whiteboard entry) I added a set of tests in the Mac Keyboard suite to cover the various file menu shortcuts so when we need to do a regression test for 10.6 they are all mapped out. (In reply to comment #14) > Marcia, this is about the access key inside the tools menu and not about the > keyboard shortcut. The shortcut should already be covered in other Litmus tests > AFAIR. But should we really test the access key? I don't think so. We don't do > this for all the other menu entries.

Alright. That info I've missed. Setting in-litmus+ again.

Not happy with the shortcut 'control+shift+P' this shortcut is usually used for 'page setup' (for some reason Firefox isn't using these) a better one should be 'control+alt+P'

An automated test makes no sense for this bug.