Closed Bug 11425 Opened 25 years ago Closed 25 years ago

find doesn't render selection until the editor gets focus

Categories

(Core :: DOM: Editor, defect, P1)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: buster, Assigned: saari)

References

(
URL
)

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
this is a pretty important dogfood blocker.
Target Milestone: M10
*** Bug 11775 has been marked as a duplicate of this bug. ***
Blocks: 12658
moved to M11
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.
Target Milestone: M11 → M12
there's still some design work to do between me, joki, and hyatt for 10678
before this one can get done. set to M12.
Whiteboard: [PDT+]
Putting on [PDT]+ radar.
Priority: P2 → P1
Assignee: buster → saari
Status: ASSIGNED → NEW
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.
mass-moving all m12 bugs to m13
Blocks: 17907
Target Milestone: M13 → M12
Sorry, didn't intend to push out any PDT+ bugs. moving back to m12
*** Bug 17990 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
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?
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.
*** Bug 10678 has been marked as a duplicate of this bug. ***
Summary: [DOGFOOD] find doesn't render selection until the editor gets focus → find doesn't render selection until the editor gets focus
Whiteboard: [PDT+]
This is not dogfood as it is only a rendering issue. Removing the PDT+ and
dogfood.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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
this is EXCELLENT news!  thanks, chris!
Depends on: 9199
Whiteboard: waiting for 9199 to get fixed; basic find not working
Status: RESOLVED → VERIFIED
verified in 12/6 build.
No longer blocks: 17907
You need to log in before you can comment on or make changes to this bug.