kinmoz Assignee
	Description • 25 years ago

The editor stops accepting key input when typing a word that exceeds the current
line length. This happens on both Windows and Linux.

To reproduce:

1. Start the editor with a blank page.

2. Keep typing any non-space character till the text hits the right edge of the
content area and a horizontal scrollbar appears.

At this point, you would expect the content area to scroll to the left as you
type so that you can see what you are typing, but it doesn't.

If you place the caret in any of the visible text and type something, nothing
happens.

The editor is not receiving Key Events at this point.

If you

	kinmoz Assignee
	Comment 1 • 25 years ago

Just thought I'd mention that this used to work, so it is a regression.

	Akkana Peck
	Comment 2 • 25 years ago

Sure enough.  On gtk, the key event is getting generated, but it doesn't make it
as far as nsTextEditorKeyListener::KeyPress; someone else must be consuming the
event, or routing it somewhere else, before it gets to the editor.

	kinmoz Assignee
	Comment 3 • 25 years ago

Right, I'm currently tracing the key event path through the XP event handling
code to see who the culprit is.

	kinmoz Assignee
	Comment 4 • 25 years ago

Accepting bug. Marking as M11 blocker per beppe@netscape.com.

	leger
	Comment 5 • 25 years ago

Setting Severity to blocker.

	kinmoz Assignee
	Comment 6 • 25 years ago

kipp@netscape.com checked in a change to the method
nsContainerFrame::GetFrameForPointUsing() that corrects the algorithm used for
selecting a frame that contains a point to fix bug #1413.

    mozilla/layout/html/base/src/nsContainerFrame.cpp  revision 1.68

Before kipp's change, the call to GetFrameForPoint() in PresShell::HandleEvent()
would always return the RootFrame's child AreaFrame which had a content node
associated with it, so PresShell::HandleEvent() was able to call the content
node's HandleDOMEvent() method.

After kipp's change, GetFrameForPoint() returns the RootFrame, which has no
content node associated with it when the content area is larger than the
viewable area. This prevents us from calling HandleDOMEvent(), so the editor
can't process the key.

Kipp's change is okay, it just exposes the fact that our applications are not
using the EventStateManager FocusedContent tracking mechanism. It looks like the
EventStateManager's FocusedContent member is always NULL. This forces
nsPresShell::HandleEvent() to send all events including KeyEvents, through
the code that selects the frame to handle an event based on the Event's point.
The point in a KeyEvent structure is meaningless, in fact it is always (0,0).

Kipp has given me permission to back out his change for M11 so that we can get
it out the door. After M11 branches, I will check his fix back in so that we can
fix the problem properly.

	rubydoo123
	Comment 7 • 25 years ago

*** Bug 18028 has been marked as a duplicate of this bug. ***

	scalkins
	Comment 8 • 25 years ago

Adding lchiang, amusil and scalkins to CC as this affects AIM team.

	leger
	Comment 9 • 25 years ago

Putting on PDT+ radar.

	kinmoz Assignee
	Comment 10 • 25 years ago

I checked in a change to

    mozilla/layout/html/base/src/nsContainerFrame.cpp  revision 1.69

that backs out Kipp's fix for bug #1413 temporarily. I reenable his fix after
M11 branches and either reopen this bug, or file a new one, with dependencies on
a third bug that makes reference to the fact that the event manager is not
tracking focus content changes in the editor or textareas.

	kinmoz Assignee
	Comment 11 • 25 years ago

Cleared comment in whiteboard status field.

	rubydoo123
	Comment 12 • 25 years ago

linking to PDT+ tracking bug 12658

	sujay
	Comment 13 • 25 years ago

verified in 11/8 build.

	kinmoz Assignee
	Comment 14 • 25 years ago

This bug needs to be re-verified.

Fix checked into tip:

    mozilla/layout/html/base/src/nsContainerFrame.cpp revision: 1.73

Modified Kipp's fix for #1413 so that nsContainerFrame::GetFrameForPointUsing()
looks through any outside children even if it finds a normal child containing
aPoint.

r=joki@netscape.com

	lchiang
	Comment 15 • 25 years ago

I'll reopen this bug for the re-verification.

	sujay
	Comment 16 • 25 years ago

verified in 11/29 build.