Closed
Bug 92100
Opened 23 years ago
Closed 23 years ago
When searching in frames, selection is visible in > 1 frame
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: ccarlen, Assigned: ccarlen)
Details
(Keywords: topembed)
Attachments
(1 file)
1.86 KB,
patch
|
Details | Diff | Splinter Review |
1) Go to a site with frames. 2) Search for a word which is found in one frame - it will be hilited. 3) Find next. 4) If the word exists in a subsequent frame, the word is hilited but the word remains hilited in the previous frame. The selection should be un-hilited in the previous frame.
Assignee | ||
Comment 1•23 years ago
|
||
Assignee | ||
Comment 2•23 years ago
|
||
The patch fixes it. If a find was successful and a selection was made, the frame is remembered. If, next time through, we find in a different frame, the selection that we set before is cleared. Do we think this is the right behavior? If so, can I get r=?
Comment 3•23 years ago
|
||
putting in 9.4 to get on Simon's radar
Priority: -- → P3
Target Milestone: --- → mozilla0.9.4
Assignee | ||
Comment 4•23 years ago
|
||
While the patch here fixes it, it's more of a workaround. The find code is already setting focus on the window in which the find occurred. I think the focus code, which must un-focus the previously focused window, should collapse the selection in the unfocused window.
Comment 5•23 years ago
|
||
The patch looks OK to me; it's better to do this in the Find code than the selection/focus code (there are other bugs about how selection should look on framed pages). sr=sfraser on the patch. Conrad, do you want the bug back?
Assignee | ||
Comment 6•23 years ago
|
||
Sure, I'll take the bug back.
Comment 8•23 years ago
|
||
r=valeski
Assignee | ||
Comment 9•23 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•