kinmoz Assignee
	Description • 25 years ago

In today's Win32 build. There is no caret in the Composer window. This seems to
be Win32 specific.

There are caret's in TextFields, TextAreas, and MessageCompose.

	kinmoz Assignee
	Comment 1 • 25 years ago

Accepting bug.

	kinmoz Assignee
	Comment 2 • 25 years ago

There are actually several problems here. The first problem is that there was
code added to

    mozilla/layout/events/src/nsEventStateManager.cpp   revision 1.89

that keeps track of the last focused content. On windows gLastFocusedContent is
being set in PreHandleEvent() when an NS_ACTIVATE event is received, which
prevents the NS_GOTFOCUS event it receives next from being processed.

saari@netscape.com has a fix for this that he will checkin soon, but here's the
little change we tried in my source tree to fix the problem:



Index: nsEventStateManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/events/src/nsEventStateManager.cpp,v
retrieving revision 1.89
diff -c -r1.89 nsEventStateManager.cpp
*** nsEventStateManager.cpp     1999/12/01 09:09:42     1.89
--- nsEventStateManager.cpp     1999/12/02 01:18:38
***************
*** 342,349 ****
        }

        if (mDocument) {
!         NS_IF_RELEASE(gLastFocusedContent);
!         mCurrentTarget->GetContent(&gLastFocusedContent);

          mCurrentTarget = nsnull;

--- 342,349 ----
        }

        if (mDocument) {
!         //NS_IF_RELEASE(gLastFocusedContent);
!         //mCurrentTarget->GetContent(&gLastFocusedContent);

          mCurrentTarget = nsnull;



The second problem is that the composer window is getting the focus event before
the document and editor exist, and we currently depend on the editor to make the
caret visible for us when it receives a focus event.

With saari's fix in place, the only way to get the caret to appear in composer
is to click in another window and click back into composer, which generates the
focus event needed to make the caret visible.

We need some other mechanism the editor can use that is not event based, maybe
some sort of interface it can query, after it is instantiated, to see if it has
focus and should make the caret visible.

	leger
	Comment 3 • 25 years ago

Pretty sure this a dup.  beppe, can you find?

Caret not necessary for dogfood.

	kinmoz Assignee
	Comment 4 • 25 years ago

If you are referring to bug #20106 (caret disappears after some edit
operations), it is NOT a dup.

I marked this bug as DOGFOOD because there is no caret at all now. This makes it
very hard to see where your input is going to go.

	Charles Manske
	Comment 5 • 25 years ago

This is ludicrous. The caret is a basic visual part of editing.
How we can not consider this PDT+ dogfood is totally beyond me, IMHO.
Please reconsider.

	rubydoo123
	Comment 6 • 25 years ago

PDT team, I think you may want to reconsider this one -- there is no caret
whatsoever, nadda. The only way you can tell where your focus point is, is to
start typing. That means, we will be getting lots of bug reports saying that
folks can't select within the compose window, their conclusion would be that
they can't enter data because they don't see their caret anywhere -- that would
be in composer, in form fields and in mail compose.

	leger
	Comment 7 • 25 years ago

Putting on PDT+ radar.

	kinmoz Assignee
	Comment 8 • 25 years ago

Below is a fix for nsEventStateManager.cpp that will get us back to where we
were last week ... that is where we had to click in the content area before it
would get focus and display the caret.

I'm currently waiting for saari@netscape.com to give his thumbs up, or take
ownership of it for checkin.

Ideally what we would want is to allow the XUL/JavaScript application to
register some notification method, that would get called after the document and
editor were instantiated, so that it could give focus to the editor's content
area. We aren't there just yet, so this fix will have to do for now.

Here's the patch/fix:


Index: nsEventStateManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/events/src/nsEventStateManager.cpp,v
retrieving revision 1.89
diff -r1.89 nsEventStateManager.cpp
247,254c247,254
<                         if(!contextOwner) break;
<
<                         nsCOMPtr<nsIScriptGlobalObject> globalObject;
<                         contextOwner->GetScriptGlobalObject(getter_AddRefs(glo
balObject));
<                         if(!globalObject) break;
<
<                         globalObject->HandleDOMEvent(aPresContext, &event, nsn
ull, NS_EVENT_FLAG_INIT, &status);
<                                               gLastFocusedDocument->HandleDOME
vent(aPresContext, &event, nsnull, NS_EVENT_FLAG_INIT, &status);
---
>                         if(contextOwner){
>                           nsCOMPtr<nsIScriptGlobalObject> globalObject;
>                           contextOwner->GetScriptGlobalObject(getter_AddRefs(g
lobalObject));
>                           if(globalObject) {
>                             globalObject->HandleDOMEvent(aPresContext, &event,
 nsnull, NS_EVENT_FLAG_INIT, &status);
>                             gLastFocusedDocument->HandleDOMEvent(aPresContext,
 &event, nsnull, NS_EVENT_FLAG_INIT, &status);
>                           }
>                         }
287,295c287,294
<                 if(!contextOwner) break;
<
<                 nsCOMPtr<nsIScriptGlobalObject> globalObject;
<                 contextOwner->GetScriptGlobalObject(getter_AddRefs(globalObjec
t));
<                 if(!globalObject) break;
<
<                 globalObject->HandleDOMEvent(aPresContext, &focusevent, nsnull
, NS_EVENT_FLAG_INIT, &status);
<                               mDocument->HandleDOMEvent(aPresContext, &focusev
ent, nsnull, NS_EVENT_FLAG_INIT, &status);
<
---
>                 if(contextOwner) {
>                   nsCOMPtr<nsIScriptGlobalObject> globalObject;
>                   contextOwner->GetScriptGlobalObject(getter_AddRefs(globalObj
ect));
>                   if(globalObject) {
>                     globalObject->HandleDOMEvent(aPresContext, &focusevent, ns
null, NS_EVENT_FLAG_INIT, &status);
>                     mDocument->HandleDOMEvent(aPresContext, &focusevent, nsnul
l, NS_EVENT_FLAG_INIT, &status);
>                   }
>                 }
345,346c344,345
<         NS_IF_RELEASE(gLastFocusedContent);
<         mCurrentTarget->GetContent(&gLastFocusedContent);
---
>         // NS_IF_RELEASE(gLastFocusedContent);
>         // mCurrentTarget->GetContent(&gLastFocusedContent);

	rubydoo123
	Comment 9 • 25 years ago

linking to composer pdt+ tracking bug

	kinmoz Assignee
	Comment 10 • 25 years ago

Fix checked in:

    mozilla/layout/events/src/nsEventStateManager.cpp  revision 1.93

Reviewed: saari@netscape.com

Fix should appear in the 12/07/99 builds.

	sujay
	Comment 11 • 25 years ago

will verify in 12/7 build.

	sujay
	Comment 12 • 25 years ago

verified in 12/7 build.