Closed Bug 63705 Opened 24 years ago Closed 24 years ago

Select contents of textfield in Find in this Page upon loading

Categories

(SeaMonkey :: UI Design, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(5 files)

In cases where we remember the last find text and prefill it in the Find in 
this Page dialog, we should select all the text upon loading.  Attaching a 
patch which does this, fixes the context persistence (setting checked="" wasn't 
properly pre-checking the appropriate checkboxes), and does other clean-up.

Upon fixing the persistence, I noticed that the case sensitive checkbox was 
checked by default upon loading the dialog (even though I hadn't previously 
checked it).  After some digging, I found that mLastCaseSensitive was set to 
PR_TRUE in the nsFindComponent constructor, while the other two 
(mLastSearchBackwards and mLastWrapSearch) were set to PR_FALSE.  Simon, cvs 
blame says you did this back in 6/99 in rev. 1.19.  Any idea why 
mLastCaseSensitive should be PR_TRUE by default?
.
Assignee: ben → blakeross
cc'ing alec for sr
Status: NEW → ASSIGNED
Priority: -- → P3
*** Bug 63729 has been marked as a duplicate of this bug. ***
Doing this with code specific to the Find dialog seems unhealthy, as it implies
that every dialog will have to do the same thing -- and since this is expected
behavior for every dialog, they shouldn't really have to do it individually.

I think that (apart from the unrelated cleanup of the Find dialog, to make the
checkboxes persistent between searches) this should be a duplicate of bug 28583.
Whenever a text field takes focus, by any means other than clicking in it, its
contents should be selected.
Matthew: I'll file a bug to remove it (and the similar Open Web Location code) 
once that bug is fixed.  Please resummarize bug 28583 to include every case 
except clicking, though (not just tabbing).
cc'ing timeless for review
MPL not NPL. Please don't use a contributor section rely on cvs blame.

i'd prefer not to give my r= until the license is settled, but if someone says 
we use NPL then you can take this as my r=.
OS: Windows ME → All
Hardware: PC → All
mind doing a diff -bw so we can see what ACTUALLY changed? :)
heh, I had to use norton utilties ncompare in order to understand the changes.
Attached patch [patch] -bwuSplinter Review
alec, have time to sr this (crap) before you go vacationing?
Just noticed the modeline says C++.  Fixed in my tree.
a couple of things:





+    dump("*** ERROR ACCESSING FIND COMPONENT!\n");



is this ever likely to fail, and warrant this human readable message that an 

optimized build will never show unless it is run with a console? A user of a 

debug build (the only one likely to see any debug output as the result of failing 

to create the find component) may be more impressed with the actual js exception, 

which can be obtained by removing the try... catch



also, it looks like you're setting the checked attribute on checkboxes directly.. 

.checked is supposed to work... 

Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reopening for a little more cleanup.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
jag/timeless, r=?
Status: REOPENED → ASSIGNED
r=jag
cc'ing ben for a= on this last bit of cleanup that clearly doesn't belong in 
thsi bug ;)
Rest of cleanup checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
vrfy fixed using 2001.05.29.0x comm bits on linux, winnt and mac.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: