328026 - [FAYT] typing a composed/accented character starts FAYT in Midas and selects character (when autostart is enabled)

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[the Falcon]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0

When editing rich text in Gmail and typing characters with accents (such as á or ü) on keyboards that require two keystrokes to do so (such as Dutch or U.S.), typing the accent mark starts find-as-you-type. This is really annoying as it can cause you to overwrite text you've just written (since find-as-you-type selects it) or make the text editing field lose focus (depending on the circumstances).

Reproducible: Always

Steps to Reproduce:
1. Log in at https://mail.google.com/mail/
2. Click "Compose Mail".
3. Make sure you are in rich formatting mode (click "Rich formatting", if necessary).
4. Move focus to the text editing field for the body of the message (the field below the "Subject:" field).
5. Type the accent mark ´ (option-E on Dutch or U.S. keyboard; on other keyboards, such as Finnish, there is a separate key for this, usually somewhere on the right; use Keyboard Viewer to figure it out).
6. Type the character a.
Actual Results:  
After step 5, a ´ appears in the status bar, but note that there's no message indicating that find-as-you-type has started.
After step 6, the status bar displays the message «Text found: "á"», and Camino selects the á you have just typed.

Expected Results:  
Find-as-you-type should not have started.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I can't reproduce this, both with Gmail's evil keyboard shortcuts on and with them off.  Do you have autostart enabled for FAYT, perhaps?

Comment 2

[the Falcon]

Ah, yes indeed, I do have Immediate Type & Find enabled in CamiTools.

Comment 3

[Chris Lawson (gone)]

Yeah, I can repro this with FAYT autostart=true, but I can't seem to get it to select the character.

Regardless, FAYT should definitely NOT be activating when the focus is in a text field.

cl

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Interestingly, single-key characters (µ as opt-m, for instance), don't trigger anything, but any sort of "composed" character (the opt-diacritic-plus-letter WEur accents, CE/EE and transliteration diactritics using US Extended layout (ṣ, opt-x s), and even the hamza dead-key on the Arabic keyboard (used to seat the hamza) will trigger this.  

The one exception I've seen to the "composed character rule" the Unicode Hex Input keyboard's raw Unicode input (opt plus codepoint, e.g. opt-0123 for ģ), which does not trigger FAYT).

I wonder if FAYT is confusing a "compose" event in the Midas box with its start event?  Or maybe this is one of the "bugs lurking" in mapping all the events between Cocoa, Gecko, and the middleman <http://wiki.mozilla.org/Mac:Cocoa_Widgets#International_Input_bugs>

FAYT once triggered thusly in Midas in Camino also doesn't appear to ever time out, which may be related.

We need someone to check in SeaMonkey to see what it does here with autostart enabled; I tried to look in Firefox, but Fx has perverted FAYT into the Find toolbar, so FAYT/Fx doesn't behave the same at all anymore (I couldn't repro, FWIW).

(Also reproduces on the Midas demo <http://www.mozilla.org/editor/midasdemo/>, so it's not something funny with Gmail trapping keystrokes like other bugs, either.)

Comment 5

[Samuel Sidler (old account; do not CC)]

This also happens in SeaMonkey 1.0/Mac (with autostart on).

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Since this happens in SeaMonkey, it's not Cocoa widget mapping foo, so moving to Core and FAYT (although it might be Editor; I searched both and saw nothing obvious).

Happens on both 1.8.0-branch and trunk.

Comment 9

[Philip Chee]

Not sure why [e-mail] moved this from Core to SeaMonkey as it appears to be originally a Camino bug.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #9)
> Not sure why [e-mail] moved this from Core to SeaMonkey as it appears
> to be originally a Camino bug.

Because someone moved the FAYT component from Core to SeaMonkey (because SeaMonkey and Camino were the only consumers of extensions/typeaheadfind/ at that time, and the bug was a Core:FAYT bug; see comment 4, comment 5 and comment 6).

Anyway, now we're the only consumer (because Toolkit FAYT *still* isn't embedding-friendly), so it can move back.

Philip, if you find any similar orphans during your triage, please do let us know; I'm probably not cc'd to most bugs that got moved to Core components that later got moved to SeaMonkey ;)  Thanks!

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I suspect we can fix this bug by backporting BWC's more in-depth Midas check: http://mxr.mozilla.org/camino/source/camino/src/browser/BrowserWindowController.mm#4292

to FAYT's more naïve Midas check: http://mxr.mozilla.org/camino/source/camino/typeaheadfind/nsTypeAheadFind.cpp#2866

In particular, I bet the problem on the Midas demo and Gmail is that we're in a (i)frame.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Possible fix

Not only did I misread our code, but that's not the problem in FAYT, either.

The FAYT Midas check isn't being hit at all; in fact, nothing ever appears to call nsTypeAheadController::IsCommandEnabled (I'm not sure what might, or how the editor command stuff works)!

However, nsTypeAheadFind::IsTargetContentOkay has a check for various text-type areas, and weaving in a Midas check there appears to fix this bug, since that method actually get called. 

It's, uh, C++ GeckXPCOM, so I'm flailing around wildly without a life jacket, but Camino does not appear to blow up with this patch installed.

Comment 13

[Stuart Morgan]

Comment on attachment 512307 [details] [diff] [review]
Possible fix

>+  if (!fm)
>+    return NS_OK;

Uses braces, since all the other early returns do.

This function returns a PRBool, so everything should be PR_TRUE or PR_FALSE. Probably we want FALSE here, since if we can't figure out what's going on with focus we should probably not trigger FAYT.

>+  if (!domWin) {
>+    return NS_OK;
>+  }

Same here.

sr=smorgan with those changes.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

http://hg.mozilla.org/camino/rev/8760bafb5dcb with those changes.