44116 - Everything disabled in editor after typing

Status: VERIFIED FIXED

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

Description

[Akkana Peck]

Run the browser on a url that has a textarea in it, e.g. mozilla
"http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser"
Copy some text in an external app, and paste (I used middle-mouse paste).
Click on the taskbar icon at the bottom to bring up composer. 
Click in the composer window and type a few characters.  

Everything in the upper toolbar greys out, and so do most of the useful menu
items.

Comment 1

[Simon Fraser [no longer active]]

I can't repro this on Mac.

Comment 2

[Akkana Peck]

This doesn't happen on every linux machine, either.  It happens every time on my
machine (RH 6.2) but doesn't happen on Kin's (RH 6.1).

In goUpdateCommand in globalOverlay.js, adding an "else dump" after the "if
controller" case shows that there's no controller for any of the editor
commands.

Uncommenting the line:
    window._content.focus();
at line 138 of editor.js makes the problem go away (but that line was commented
out because of IME problems on Mac).

Apparently the text field in the browser is somehow messing with the focus, so
that after clicking in the editor the focused element isn't right.

Comment 3

[Akkana Peck]

Saari and I spent some time debugging this.  The fundamental problem seems to be
that NS_ACTIVATE isn't called on the window until long after Focus is called, so
when the nsXULCommandDispatcher gets a Focus call, it thinks that focus is
suppressed, and returns immediately.

This seems to be a problem with the gtk handling of focus.  If I move the
DispatchFocus() and Release() calls in nsWindow::SetFocus() to after the call
that passes NS_ACTIVATE, then the bug goes away -- subject to a few other
existing bugs.

I should mention, this bug only occurs using pointer focus, not in
click-to-type.  In pointer focus, following the above steps, no activate is sent
to the window, and if the mouse is outside the editor window when it first pops
up, no focus call is sent to it either.  If I move the mouse into the window,
handle_toplevel_focus_in is not called; but if I move the mouse out and back in,
it is called the second time.  (Bug in gtk?  This is on a RH62 system with
gtk+-1.2.6-7.)

If you click after the first mouse-in and then attempt to type, everything greys
out and stays that way, even after subsequent mouse outs/ins, even after the
change to send activate before focus.  So this patch improves things, but
doesn't completely fix the problem.

Comment 4

[Akkana Peck]

Correction, it's handle_mozarea_focus_in, not handle_toplevel_focus_in, that
isn't called on the first mouse in, but is on subsequent mouse ins. 
handle_mozarea_focus_in is the one that dispatches an ns focus event.

Comment 5

[leger]

Putting on [dogfood+] radar. 

Comment 6

[kinmoz]

Adding [e-mail] to Cc list.

Comment 7

[Akkana Peck]

Pav said he would look into this -- that maybe the top window event isn't
passing the mouse-in event to its child.  Pav, pass it back to me if that isn't
the problem.

Comment 8

[Stuart Parmenter]

I see us not getting the focus in until the 2nd time around as well... I tried
looking through this, but I am not really sure what is going on.  Blizzard, care
to take a look?

Comment 9

[Christopher Blizzard (:blizzard)]

I spend a good part of yesterday and today working on this bug.

Comment 10

[Christopher Blizzard (:blizzard)]

Attachment: patch me harder

Comment 11

[Christopher Blizzard (:blizzard)]

Attached is a patch that seems to fix the problem.  It's also been tested in
embedding and works.  One thing that I've noticed is when the editor window
doesn't have focus anymore that the caret still blinks in it.  This is the case
on windows as well so it doesn't seem to be the platform specific focus code. 
I'm looking for reviews and comments.

Comment 12

[R.K.Aa.]

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

Comment 13

[Christopher Blizzard (:blizzard)]

Wow, for a dogfood blocker bug everyone is really quiet.

Comment 14

[Stuart Parmenter]

r=pavlov

Comment 15

[Akkana Peck]

The patch does cure the problem, both to my Linux display, and remotely
displaying to an SGI server.

Comment 16

[Akkana Peck]

r=akkana (subject to some minor points I sent to blizzard, mostly turning off
the debugging output).

Comment 17

[Christopher Blizzard (:blizzard)]

a=brendan, checked in.

Comment 18

[sujay]

verified in 7/12 build.