[dogfood] in composer, editor never gets a Focus notification

VERIFIED DUPLICATE of bug 9701

Status

()

Core
Editor
P1
major
VERIFIED DUPLICATE of bug 9701
18 years ago
16 years ago

People

(Reporter: buster, Assigned: David Hyatt)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-], URL)

(Reporter)

Description

18 years ago
launch editor from browser task menu, so default edit page loads
notice the caret, it's above the first line of text and really small
the selection at this point is Sel. Collapse to 031F90AC __moz_text 0 according
to debug output (turning on DEBUG_SELECTION in nsRangeList.cpp)
(Reporter)

Updated

18 years ago
Priority: P3 → P1
Target Milestone: M11

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 1

18 years ago
This is because the caret is in a text node which contains just whitespace. I
think the code that sets the initial selection for the editor needs to be a bit
smarter.

Comment 2

18 years ago
Could someone point me at the code where this might be addressed?

Updated

18 years ago
Assignee: sfraser → buster
Status: ASSIGNED → NEW

Comment 3

18 years ago
Reassigning this, due to current focus on performance issues.
Steve, IsEditable needs to return true for <BR> nodes/frames, so that the caret
ends up being placed on the first one. What happens now, in mail compose, is that
the caret ends up in the signature, because that's the first node that contains
text.
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
Summary: caret in odd place when editor launched → [blocker] caret in odd place when editor launched
Whiteboard: fix in hand, waiting for permission
Target Milestone: M11 → M10
(Reporter)

Comment 4

18 years ago
this looks like a usability blocker, quite easy to fix, very low risk.  simon
has already code reviewed.

Comment 5

18 years ago
ok.  checkin. thanks
(Reporter)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand, waiting for permission
(Reporter)

Comment 6

18 years ago
fixed, a=chofmann, r=sfraser

Updated

18 years ago
Status: RESOLVED → REOPENED

Comment 7

18 years ago
I don't see any carat when launching editor....reopening this one...

Updated

18 years ago
Resolution: FIXED → ---

Comment 8

18 years ago
Clearing Fixed resolution due to reopen.

Comment 9

18 years ago
Using the 19999100618 M10 candidate commercial build on NT, I'm seeing the caret
appear initially before the "H", and then disappear.

User must click in document in order for the caret to reappear.

Updated

18 years ago
Target Milestone: M10 → M11

Comment 10

18 years ago
Moving to M11.  sujay, please Release Note for M10 at:
http://bugzilla.mozilla.org/show_bug.cgi?id=14872
(Reporter)

Comment 11

18 years ago
I think this is simply the content area failing to get focus.  Selection is set
in the correct place in the document.
(Reporter)

Updated

18 years ago
Summary: [blocker] caret in odd place when editor launched → [dogfood] caret in odd place when editor launched
(Reporter)

Comment 12

18 years ago
marking dogfood, because it makes the app a pain to use.  removing blocker,
since no one is actually blocked on this. Sent a note to simon, hyatt, and pink
asking about focus.

Updated

18 years ago
Summary: [dogfood] caret in odd place when editor launched → [dogfood-pd-] caret in odd place when editor launched

Comment 13

18 years ago
Not a dogfood blocker.  sorry...adding pdt-

Updated

18 years ago
Summary: [dogfood-pd-] caret in odd place when editor launched → [dogfood][pd-]caret in odd place when editor launched

Updated

18 years ago
Summary: [dogfood][pd-]caret in odd place when editor launched → [dogfood][PDT-]caret in odd place when editor launched

Updated

18 years ago
Summary: [dogfood][PDT-]caret in odd place when editor launched → [dogfood]caret in odd place when editor launched
Whiteboard: [PDT-]
(Reporter)

Updated

18 years ago
Assignee: buster → hyatt
Status: REOPENED → NEW
Summary: [dogfood]caret in odd place when editor launched → [dogfood] in composer, editor never gets a Focus notification
(Reporter)

Comment 14

18 years ago
with recent focus change landings, I think this got broken.  The problem is the
editor never gets a focus message.  Set a break in
nsTextEditorFocusListener::Focus(nsIDOMEvent* aEvent),
run apprunner -edit
editor focus handler never gets called.  It used to, it still should.

Updated

18 years ago
Blocks: 16654

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 15

18 years ago
*** This bug has been marked as a duplicate of 9701 ***

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 16

18 years ago
verified in 10/22 build.
You need to log in before you can comment on or make changes to this bug.