52727 - when searching a frame, Search menu item should be Find in Active Frame

Status: VERIFIED WONTFIX

(SeaMonkey :: UI Design, defect, P4)

Description

[sairuh (rarely reading bugmail)]

...right now it still says, Find in the Page. the backend, ie, searching within 
a frame *does* work, it's just that there's no visual indication within the 
Search menu (or which frame is active, but that's another bug :) that you're 
actually searching within a frame. (page in the frame context implies the main 
frameset, imo, rather than the active frame.)

Comment 1

[sairuh (rarely reading bugmail)]

this feature is part of communicator 4.x, too.

Comment 2

[sairuh (rarely reading bugmail)]

on the "give the user a indication in the UI" note, this would prolly go hand in 
hand with bug 41443 (which alas, has been minused).

Comment 3

[Blake Ross]

This would be easy, but again the problem is the damn minused "show focus in 
frame" bug (so the user still doesn't really know what frame he's searching 
in).  Still, I guess the word change would be better than nothing.

Comment 4

[Blake Ross]

I am going to checkin tonight to add the string "Find in this Frame" (I assume 
that's what you meant, since its counterpart is "Find in _this_ Page"?) just to 
workaround the i18n UI text freeze requirement, and we can implement this after 
beta3.

Comment 5

[Blake Ross]

Attachment: patch just to add the strings

Comment 6

[Blake Ross]

brendan, could you please review & approve this simple patch just to get the 
strings in before text freeze?  i'm afraid that law may not still be around 
tonight... 

Comment 7

[Bill Law]

r=law

Comment 8

[Brendan Eich [:brendan]]

a=me

/be

Comment 9

[Blake Ross]

Thanks.  However, when I went to sleep at 2am EST last night, the tree was still 
closed...so I clearly couldn't check this in.  Is it too late now?

Comment 10

[Jesse Ruderman]

"Find in this frame?"  What does "this" refer to?

IMO, should be "Find in active frame".

Comment 11

[sairuh (rarely reading bugmail)]

jesse, good point! esp since showing active frame isn't implemented --might as
well attempt to clarify in the menu... resummarizing.

Comment 12

[Matthew T (active 1999-2002)]

Sorry to spoil the party, but I think we're making the user's life unnecessarily 
difficult here.

Analogy: A user shouldn't have to care that a page is composed entirely of 
Javascript, unless it is necessary to expose this technical detail -- e.g. if a 
script error occurs. Similarly, a user shouldn't have to care that a page is made 
up of frames, unless it is necessary to expose this technical detail -- e.g. for 
tabbing (so we need to show focus for frames), or printing (so we need to ask 
which frame), or saving (ditto).

In the case of finding text, the user does not need to know that the page is made 
up of frames. That's completely irrelevant to the task. A text search should 
start at the first frame, and go through the frames in order.

Comment 13

[Blake Ross]

I agree.  Marking WONTFIX, but we need a new bug to search through frames in 
order (we currently just search the active frame).

Comment 14

[sairuh (rarely reading bugmail)]

i couldn't find such a bug existing, so i filed bug 63241...

Comment 15

[sairuh (rarely reading bugmail)]

v