found using 2002.04.03.09-static mozilla build on linux rh7.2. 1. go to a web page with frames, eg, http://wired.com/ 2. bring up the context menu (either for the page content, selection or a link). 3. observe the following duplicate menu accesskeys: a. for "w": Sho_w Only This Frame Open Frame in New _Window b. for "f": Bookmark This _Frame Save _Frame As... expected: a. per the spec at http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-3.html#Anchor-45980, shouldn't the "Show Only This Frame" item be removed? if yes, then that'll remove the duplicate "w"... b. per the spec, the menu accesskey for "Bookmark This Frame" should be the "m", as in "Book_mark This Frame". correcting this would take care of the duplication of "f".

kw-o-rama...

[show only this frame] was left out of the spec because it was too similar to [open frame in new window] and [open frame in new tab]. the differences between these two operations were so little, that we had to decide on one or the other in order to keep menus short.

Removing adt1.0.0. When there is a patch, r= and sr= add the keywork for approval.

Nav triage team: nsbeta1+/adt2

I strongly disagree that Show Only This Frame should be left out. Why would Open Frame in New Window be used more?

renominating for reconsideration, this isn't critical accessibility work. Users who must use the keyboard can still hit Open Frame in New Window by hitting the down arrow twice, which isn't much harder than hitting w once, and this isn't even a frequently used menuitem.

nsbeta1- per Nav triage team.

the presence of both methods opens a depth vs. breadth debate. i attempted to broadly cover real in-use scenarios, rather than offer deeper control of only a few. this is of course applied generally, but it is how we manage to keep menus short. the frame situation is unique addition of the submenu so if this item indeed has some sort of hidden advantage that was overlooked, it wouldn't be too painful to squeeze it in. Just give me more than the obvious, "i use it all the time and i simply love it"

"Open Frame in New Window" is mainly there for the purpose of breaking out of frames, isn't it? I contend that the common usage pattern for this would be to open frame in new window and then close the original window. With Show Only This Frame, we attempted to bypass this extra step by opening the frame in the same window. The item serves the common purpose of helping to break out of a frameset, which currently is an option the website offers (if it offers). I can't see of any reason why you'd break a frame out into a new window but still want the original frameset open. (I still don't see why this is critical for machv/beta1).

It isn't; this is way down the list of things we need to worry about. Marlon, the triage team acknowledges that this deviation from the spec is a defect, but it doesn't come close to being required for MachV. nsbeta1-/1.1.

Comment on attachment 88760 [details] [diff] [review] fix r=db48x

nominating --has patch, to boot. :)

Nav triage team: nsbeta1+/adt3

Nav triage team: nsbeta1-

why was this minused? there's a patch here --unless it's obsolete. over shuehan, but reassign as needed.

Nav triage team: nsbeta1+/adt3

*** Bug 194901 has been marked as a duplicate of this bug. ***

Comment on attachment 88760 [details] [diff] [review] fix sr=alecf

I ask that you back this out now. This discussion was not over, yet a patch was made and checked in. This is not acceptable behavior. Where is the MOA?

Comment on attachment 88760 [details] [diff] [review] fix This patch is incomplete. The entity can't be removed without removing the XUL using it.

we'd consider a fix but not blocking on this

Comment on attachment 123025 [details] [diff] [review] patch I think blake makes a strong enough case to keep "Show Only This Frame" for now.

ok then, keep menuitem and just change accesskeys

Comment on attachment 123041 [details] [diff] [review] patch r=jag No need for the change in nsContextMenu.js though.

r=varga

Comment on attachment 123041 [details] [diff] [review] patch sr/a=sspitzer

checked in

vrfy'd fixed with 2003.05.19.08. thanks, shuehan!