115630 - selection should be automatically copied to Find dialog

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Tobias Weibel]

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.

Comment 1

[John Morrison]

-> sgehani

Comment 2

[Samir Gehani]

-> XPApps: GUI Features

Comment 3

[Tobias Weibel]

Attachment: I have written a patch. It is my first mozilla javascript, so check it well.

Comment 4

[Tobias Weibel]

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

Comment 5

[sairuh (rarely reading bugmail)]

mass moving open bugs pertaining to find in page/frame to [e-mail] as
qa contact.

to find all bugspam pertaining to this, set your search string to
"AppleSpongeCakeWithCaramelFrosting".

Comment 6

[Blake Ross]

-> ui design

Comment 7

[Tobias Weibel]

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

Comment 8

[parish]

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 9

[[e-mail]]

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 :-)

Comment 10

[timeless]

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

Comment 11

[Tobias Weibel]

Attachment: second try

selectedStr mustn't override gFindInst.searchString

I hope my choice of replaces are better now.

Comment 12

[Jonas Jørgensen]

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.)

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

+  dialog.findKey.value           = selectedStr ? selectedStr :
+                                   (gFindInst.searchString ?
gFindInst.searchString : findService.searchString);

doesn't that mean that selectedStr will override the last search string?

Comment 14

[Tobias Weibel]

> 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...)

Comment 15

[Tobias Weibel]

Attachment: patch v3 (included feedback from several people)

patch 63075 and 76034 are obsolete.

thanks to [e-mail]

Comment 16

[parish]

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.

Comment 17

[timeless]

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...

Comment 18

[parish]

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.

Comment 19

[Tobias Weibel]

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.

Comment 20

[Robin Monks]

Sister bug for Firefox: bug 250910

Comment 21

[Philip Chee]

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 22

[Serge Gautherie (:sgautherie)]

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.)