Closed
Bug 11425
Opened 26 years ago
Closed 25 years ago
find doesn't render selection until the editor gets focus
Categories
(Core :: DOM: Editor, defect, P1)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: buster, Assigned: saari)
References
()
Details
(Whiteboard: waiting for 9199 to get fixed; basic find not working)
see bug 10678. Until the editor knows what kind of blur it's gotten, it can't
know whether to render/unrender selection on focus/blur. For a variety of other
bugs, I've made it so it renders/unrenders. But when we lose focus to
chrome/dialogs, we don't want to do this.
Severity: normal → major
Status: NEW → ASSIGNED
Depends on: 10678
Priority: P3 → P2
Summary: find doesn't render selection until the editor gets focus → [DOGFOOD] find doesn't render selection until the editor gets focus
*** Bug 11775 has been marked as a duplicate of this bug. ***
Comment 4•25 years ago
|
||
Does this bug reflect the same problem as the fact that select-all doesn't show
everything highlighted, and you have to click back in the document (which is
wrong, that should undo the select-all and collapse the selection to a caret) to
see the highlighting? If not, we need a dogfood bug on that issue.
I think this problem is a symptom of missing functionality described in bug
10678. It sounds like the select-all problem is another symptom of the same
thing, focus is being inappropriately removed from the content area. I'm not
sure if it's worth a separate bug or not.
there's still some design work to do between me, joki, and hyatt for 10678
before this one can get done. set to M12.
Updated•25 years ago
|
Priority: P2 → P1
assigning to saari, cc hyatt. I believe they still have some infrastructure
work to do before this can be fixed. Please assign back to me when your part is
done, and I'll do whatever needs to get done in the editor to make things right.
Comment 9•25 years ago
|
||
mass-moving all m12 bugs to m13
Updated•25 years ago
|
Target Milestone: M13 → M12
Comment 10•25 years ago
|
||
Sorry, didn't intend to push out any PDT+ bugs. moving back to m12
Comment 11•25 years ago
|
||
*** Bug 17990 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•25 years ago
|
||
You're going to get a blur when a new window pops up and deactivates the
previous one. You just are, it is the way of the DOM. It sounds like you want
new functionality available from the DOM, such as activate and deactivate events
for top level windows. Am I right here?
Assignee | ||
Comment 13•25 years ago
|
||
I just tried this, and it is only a rendering problem... It looks perfectly
usable to me. In other words, not dogfood.
And if you're going to reply, read my previous statement, and reply to that too.
Assignee | ||
Comment 14•25 years ago
|
||
*** Bug 10678 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Summary: [DOGFOOD] find doesn't render selection until the editor gets focus → find doesn't render selection until the editor gets focus
Whiteboard: [PDT+]
Assignee | ||
Comment 15•25 years ago
|
||
This is not dogfood as it is only a rendering issue. Removing the PDT+ and
dogfood.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 16•25 years ago
|
||
I just tried this out on build 1999111608 build on win95, this is what I did:
1. launch apprunner, accessed a lengthly page
2. selected File | Edit Page
3. selected Edit | Find and entered a word that would render in the next
scrolled window (probably using the wrong term)
RESULT: the editor displayed the correct area within the page, the word was
highlighted, and subsequent Find Again worked too.
Marking fixed
Reporter | ||
Comment 17•25 years ago
|
||
this is EXCELLENT news! thanks, chris!
Depends on: 9199
Whiteboard: waiting for 9199 to get fixed; basic find not working
Comment 18•25 years ago
|
||
verified in 12/6 build.
You need to log in
before you can comment on or make changes to this bug.
Description
•