Closed Bug 18006 Opened 25 years ago Closed

[M11 BLOCKER] [DOGFOOD] Can't set focus in empty GFX textareas

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: kinmoz, Assigned: kinmoz)

References

Details

(Whiteboard: verify 11/8 build) 

If I save the following HTML into a local file, then type in the URL to load it,
I can't set focus inside the textarea. Any text I type goes into the URL bar.

<html>
<body>
<form>
<textarea rows=10 cols=20></textarea>
</form>
</body>
</html>

The wierd thing is that I can set the focus in textareas with content or blank
textareas that have the attribute "wrap=hard" set.
Severity: normal → major
Priority: P3 → P2
Target Milestone: M11
with code pulled yesterday morning, I do not see this problem at all on WinNT
with a debug build.  If it's legit, then it's something that was introduced
yesterday.  Hyatt, Saari, did you guys know about anything that changed
since early yesterday morning that might effect focus in this case?
To my knowledge, nothing changed that would have caused this. FYI, the only thing

I've seen like this in my focus testing is the native Windows OS window for

sidebar not accepting focus.
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.
I think you can get focus in the text field, but you have to click at the
extreme left edge of the text control.  That implies to me that the embedded
webshell has been sized wrong, maybe 0 or 1 pixel wide, something dumb like
that.  I'll look into it.  I think that clears saari/hyatt and any focus issues.
Assignee: buster → kin
ah, just saw kin's note.  sounds like he has a handle on it, assigning it to
him.  thanks, kin!  you might want to change the summary to more accurately
reflect what's going on here.
Status: NEW → ASSIGNED
Accepting bug.
Severity: major → blocker
Priority: P2 → P1
Summary: [DOGFOOD] Can't set focus in empty GFX textareas → [M11 BLOCKER] [DOGFOOD] Can't set focus in empty GFX textareas
I thought I had marked this one already -- setting as M11 blocker
Can you give us some example testcases which block dogfood use?
well, you couldn't type a comment into the Additional Comments: field of
bugzilla, because that's an empty textarea.  You couldn't post to mozillazine or
any other site that supported chat/feedback/talkback forms.
you can't easily select any text entry field -- for example, access bugzilla and
try typing in some text.
Whiteboard: Waiting for code review approval from kipp@netscape.com
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.
Whiteboard: Waiting for code review approval from kipp@netscape.com
Cleared comment in whiteboard status field.
Whiteboard: verify 11/8 build
All you have to do to verify this bug is to load the following HTML:

<html>
<body>
<form>
<textarea rows=10 cols=20></textarea>
</form>
</body>
</html>

You won't be able to click in the textarea and type if the bug is still there.
Depends on: 18092
Blocks: 12658
linking to PDT+ tracking bug 12658
Status: RESOLVED → VERIFIED
verified in 11/8 build.
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
You need to log in before you can comment on or make changes to this bug.