From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011213 BuildID: 2001121303 Select a text on a homepage and press Ctrl+F. Then the marked text should be copied automatically into the "Find in This File" dialogue. I think this is a useful feature.

-> sgehani

-> XPApps: GUI Features

It would be nice if this feature goes into moz 0.9.8 .

mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as qa contact. to find all bugspam pertaining to this, set your search string to "AppleSpongeCakeWithCaramelFrosting".

-> ui design

It would be nice if this feature goes into moz 1.0 . Attachment 63075 [details] [diff] works well for me.

I've been using Tobias' patch for a couple of days now both on CVS builds and 0.9.9, both on W2K, without any problems. It would be good to see this committed soon. Under Windows at least it adds "standard behaviour" to the Find mechanism - most (all?) Windows programs open the Find dialogue with any selected text pasted into the Find: textbox.

Comment on attachment 63075 [details] [diff] [review] I have written a patch. It is my first mozilla javascript, so check it well. Should the selectedStr override gFindInst.searchString (passed as an argument)? If not then don't calculate it if you don't need to. I don't like your choice of replaces, I would use 1) /^\s+/, "" 2) /\s+$/, "" (also you forgot the space after the comma) 3) /\s+/g, " " which collapses all whitespace runs to a single space. I do this because a single space will match any amount of whitespace. I don't like the whitespace differences at lines 115/124 and 126/135. I also doesn't like the way the dialog uses x ? x : y when it means x || y but that's not your fault. Oh, and if anyone wants to comment on my comments please CC me as well :-)

personally, i think i prefer /\s\s+/g, " " (note the second \s)

selectedStr mustn't override gFindInst.searchString I hope my choice of replaces are better now.

I wouldn't call this standard behavior for Windows apps. I'm on Windows 2000, and I am unable to find a single web browser that does this. I have tested Mozilla, IE, Opera, Netscape Communicator and Amaya. (Yes, I am aware that Amaya doesn't really count.)

+ dialog.findKey.value = selectedStr ? selectedStr : + (gFindInst.searchString ? gFindInst.searchString : findService.searchString); doesn't that mean that selectedStr will override the last search string?

> doesn't that mean that selectedStr will override the last search string? The last search string will be overwritten if selectedStr contains at least one character. Otherwise the last search string will be used. Did I understand you correctly? (My english skills are not very good...)

patch 63075 and 76034 are obsolete. thanks to neil@parkwaycc.co.uk

As per my comment 8 Tobias' patch has been working well for a few months now. This really should be committed and this bug closed.

if at all possible, i'd like to be able to access the previous search string (ctrl-z or down would be fine), but if necessary i can find/file a bug for that...

I agree with timeless that this would be a good feature but I believe that Tobias' patch addresses the subject of this bug (and it works reliably) and so should be committed. A search history, which is in keeping with Windows (don't know about other platforms) is a separate issue and should be filed as a new bug/RFE.

blaker: could you review my last patch (attachement 85038) please? timeless: you're able to access the previous search string if you don't select a word an hit ctrl+f.

Sister bug for Firefox: bug 250910

We now have the Firefox/Toolkit findbar on trunk. so WFM. On the SeaMonkey 2.0 branch we are only accepting security and stability patches so WONTFIX.

Comment on attachment 85038 [details] [diff] [review] patch v3 (included feedback from several people) (Update patch to current Hg/code and re-request review, if need be.)