Closed
Bug 92100
Opened 24 years ago
Closed 24 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•24 years ago
|
||
Assignee | ||
Comment 2•24 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•24 years ago
|
||
putting in 9.4 to get on Simon's radar
Priority: -- → P3
Target Milestone: --- → mozilla0.9.4
Assignee | ||
Comment 4•24 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•24 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•24 years ago
|
||
Sure, I'll take the bug back.
Comment 8•24 years ago
|
||
r=valeski
Assignee | ||
Comment 9•24 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•