Closed Bug 133304 Opened 22 years ago Closed 22 years ago

No blinking caret in mail body

Categories

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

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: baffoni, Assigned: aaronlev)

Details

(Keywords: regression, Whiteboard: EDITORBASE+ [adt2], waiting for a=)

Attachments

(1 file)

This fixes the problem by never touching the caret when the pref remains the same.
1.11 KB, patch
bryner
: review+
hewitt
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
When I compose a new message, I type in an address, hit tab, type in a subject,
hit tab.  I expect to see the blinking cursor now displayed in the body of the
message, but there is no cursor to be seen anywhere.  If I start typing, the
text I typed appears where you would expect it at the top of the composition
window, and so does the cursor, but until I type, the cursor is lost.

I have seen similar problem typing into form windows in the browser, but I can't
replicate the behaviour as reliably as in the mail composition window.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020325
-->varada. But probably an editor problem...
Assignee: ducarroz → varada
Same thing under MacOS 8.6
confirm based on above comment
is this a duplicate?

Aaron, Kin--do either of you know what might have broken this?
Assignee: varada → mjudge
Status: UNCONFIRMED → NEW
Component: Composition → Selection
Ever confirmed: true
OS: Windows 2000 → All
Product: MailNews → Browser
QA Contact: esther → tpreston
Hardware: PC → All
Summary: No blinking cursor in mail body → No blinking caret in mail body
Can someone test to see if this was broken by the following checkin:

03/09/2002 22:21 aaronl%netscape.com mozilla/ content/ events/ src/
nsEventStateManager.cpp 1.329 471/215  Fixes bug 66597, bug 103284, bug 114440,
bug 120023, bug 128741, bug 19259 . Cleans up browse with caret, makes it work
with XML content docs, creates keyboard toggle for it (Accel+shift+K),
synchronizes focus and document selection so that users can tab navigate
relative to their last find or click in text, or vice versa, makes tabbing move
relative to named anchor that has been jumped to. r=bryner, sr=alecf, a=asa
Looks like nsEventStateManager::SetCaretEnabled() is the 
thing that is shutting off the caret. The code looks like 
it was introduced in aaronl's checkin that he mentions 
above. (nsEventStateManager.cpp revision 1.329)

The caret is already visible in the mail compose area before 
nsEventStateManager::SetCaretEnabled() is called. I think the logic in this 
code in ResetBrowseWithCaret() needs to be reworked:

  // Make caret visible or not, depending on what's appropriate
  if (presShell)
    return SetContentCaretVisible(presShell, mCurrentFocus, *aBrowseWithCaret && 
gLastFocusedDocument == mDocument);

Perhaps we shouldn't be calling SetContentCaretVisible() at all unless 
*aBrowseWithCaret is true.

Here's the stack of how the caret is being turned off:


nsEventStateManager::SetCaretEnabled(nsIPresShell * 0x04891dc8, int 0) line 4501
nsEventStateManager::SetContentCaretVisible(nsIPresShell * 0x04891dc8, 
nsIContent * 0x00000000, int 0) line 4543 + 16 bytes
nsEventStateManager::ResetBrowseWithCaret(nsEventStateManager * const 
0x049f19c8, int * 0x049f1a70) line 4578 + 72 bytes
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x049f19c8, 
nsIPresContext * 0x04adc708, nsEvent * 0x0012ec10, nsIFrame * 0x0496bf50, 
nsEventStatus * 0x0012ea90, nsIView * 0x0496e260) line 512
PresShell::HandleEventInternal(nsEvent * 0x0012ec10, nsIView * 0x0496e260, 
unsigned int 1, nsEventStatus * 0x0012ea90) line 6091 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x04891dcc, nsIView * 0x0496e260, 
nsGUIEvent * 0x0012ec10, nsEventStatus * 0x0012ea90, int 0, int & 1) line 6020 + 
25 bytes
nsViewManager::HandleEvent(nsView * 0x0496df80, nsGUIEvent * 0x0012ec10, int 0) 
line 2064
nsView::HandleEvent(nsViewManager * 0x04a2cba0, nsGUIEvent * 0x0012ec10, int 0) 
line 306
nsViewManager::DispatchEvent(nsViewManager * const 0x04a2cba0, nsGUIEvent * 
0x0012ec10, nsEventStatus * 0x0012eb80) line 1869 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012ec10) line 83
nsWindow::DispatchEvent(nsWindow * const 0x0496e04c, nsGUIEvent * 0x0012ec10, 
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012ec10) line 886
nsWindow::DispatchFocus(unsigned int 105, int 1) line 4902 + 15 bytes
nsWindow::ProcessMessage(unsigned int 7, unsigned int 591194, long 0, long * 
0x0012efe4) line 3733 + 23 bytes
nsWindow::WindowProc(HWND__ * 0x000805ca, unsigned int 7, unsigned int 591194, 
long 0) line 1130 + 27 bytes
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()
nsEventStateManager::SendFocusBlur(nsEventStateManager * const 0x049f19c0, 
nsIPresContext * 0x04adc708, nsIContent * 0x00000000, int 1) line 3872
nsEventStateManager::SetContentState(nsEventStateManager * const 0x049f19c8, 
nsIContent * 0x00000000, int 2) line 3524
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x049f19c8, 
nsIPresContext * 0x04adc708, nsEvent * 0x0012f90c, nsIFrame * 0x0496bf50, 
nsEventStatus * 0x0012f718, nsIView * 0x0496e260) line 1660
PresShell::HandleEventInternal(nsEvent * 0x0012f90c, nsIView * 0x0496e260, 
unsigned int 1, nsEventStatus * 0x0012f718) line 6117 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x04891dcc, nsIView * 0x0496e260, 
nsGUIEvent * 0x0012f90c, nsEventStatus * 0x0012f718, int 0, int & 1) line 6020 + 
25 bytes
nsViewManager::HandleEvent(nsView * 0x0496df80, nsGUIEvent * 0x0012f90c, int 0) 
line 2064
nsView::HandleEvent(nsViewManager * 0x04a2cba0, nsGUIEvent * 0x0012f90c, int 0) 
line 306
nsViewManager::DispatchEvent(nsViewManager * const 0x04a2cba0, nsGUIEvent * 
0x0012f90c, nsEventStatus * 0x0012f808) line 1869 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f90c) line 83
nsWindow::DispatchEvent(nsWindow * const 0x0496e04c, nsGUIEvent * 0x0012f90c, 
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f90c) line 886
nsWindow::DispatchMouseEvent(unsigned int 302, unsigned int 1, nsPoint * 
0x00000000) line 4711 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 302, unsigned int 1, nsPoint * 
0x00000000) line 4963
nsWindow::ProcessMessage(unsigned int 513, unsigned int 1, long 2687066, long * 
0x0012fd20) line 3591 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x000805ca, unsigned int 513, unsigned int 1, long 
2687066) line 1130 + 27 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x019071a8) line 309
main1(int 1, char * * 0x00307380, nsISupports * 0x00000000) line 1350 + 32 bytes
main(int 1, char * * 0x00307380) line 1698 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
Assignee: mjudge → aaronl
Keywords: nsbeta1, regression
Whiteboard: EDITORBASE
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
We can't not do this when browse with caret is off, because browse with caret
can be turned off dynamically, in which case the next focus to a doc must turn
off the caret.

The problem is that we think that this is content, when it's really an editor
shell. If I had a test to tell when I'm in an editor docshell then I could fix
it. However, I'm told that it's a bad idea to do something based on when
something is an editor docshell.
Status: NEW → ASSIGNED
Keywords: nsbeta1 → nsbeta1+
Whiteboard: EDITORBASE → EDITORBASE+
May be related to bug 133121
Whiteboard: EDITORBASE+ → EDITORBASE+ [adt2]
In the case where there pref is never on, the browse with caret code to enable
or disable the caret is never called.

I've tested it thoroughly and tried to find a mode where there caret doesn't
show, and I can't.
Comment on attachment 76818 [details] [diff] [review]
This fixes the problem by never touching the caret when the pref remains the same.

r=bryner
Attachment #76818 - Flags: review+
Comment on attachment 76818 [details] [diff] [review]
This fixes the problem by never touching the caret when the pref remains the same.

sr=hewitt
Attachment #76818 - Flags: superreview+
Whiteboard: EDITORBASE+ [adt2] → EDITORBASE+ [adt2], waiting for a=
Attachment #76818 - Flags: approval+
Comment on attachment 76818 [details] [diff] [review]
This fixes the problem by never touching the caret when the pref remains the same.

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Keywords: adt1.0.0
adt1.0.0+ per ADT.
Keywords: adt1.0.0 → adt1.0.0+
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Is this meant to always show the caret no matter what? Or not show the caret
when caret browsing is toggled? With build id 2002040103, turn off caret
browsing then alt-tab into the compose window. The caret doesn't show at that
point but typing shows it (and inserts at the right point). Turning on caret
browsing causes it to work. (This might have been because I think I had caret
browsing enabled when I closed Mozilla, and then re-opened it; if this is the
case, then it requires a toggle no matter what to show it.)
Mailcompose should work as it always did. Try a build from today or later.
Verified fixed win XP build 2002041011, linux build 2002041011 and mac OS X
build 2002040908
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: