accens in gmail compose don't work if field is reached by "tab"

[Leandro]

Binary package hint: firefox

When typing e-mails on Gmail on Firefox 3.6.3, if the text field is reached
using the 'tab' key, accent input using a dead-key keyboard don't work.

That is, I cannot type á, é, í, etc.

However, if instead of going to the field by pressing 'tab' y go to it
with the mouse and cilcking, it works.

This is a firefox bug, not a ubuntu bug, because MacOS users are
having the same problem, as reported here:

http://www.google.com/support/forum/p/gmail/thread?tid=6df88c711e266a76&hl=en

I'm posting it here so people knows about it and maybe can communicate to
firefox developers, I'm not sure they are aware of that.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Fri May 21 16:00:18 2010
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox

[Dmose (dmose)]

Changing to Mac only, as that's all we're sure of at this point. I can't reproduce this using the 3.1a1RC1 build on Mac, when I type option-e, I see this character:

´

Setting to UNCONFIRMED at the moment for that reason.

I suspect that David has some sort of OS X system preference related to international keyboard layouts set. David, is that the case?

I've CCed _Tsk_ hoping for help on the regression / regressionwindow-wanted stuff. _Tsk_, is a CC like this actually necessary, or do you have some other mechanism in place (eg a bugzilla whine) to keep you apprised of new bugs with those keywords?

Assuming this bug does get confirmed as happening 100% of the time (_Tsk_, I bet you have keyboard settings similar to davida, perhaps you're a good person to do this?), I think it should be marked as blocking 3.1 beta 1.

[David-ascher (david-ascher)]

fyi, i'm using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100121 Lanikai/3.1b1pre

dmose, if you type option-e you should see ´ with an underline and then if you then type 'e' the two chars will combine to form an é. So it sounds like you're seeing the right behavior. I don't think keyboard layouts are relevant here. (I use an en-US keyboard layout).

My build is a few days old, maybe it'll go away w/ the next nightly.

[Dmose (dmose)]

Ah, indeed, it is working right for me in 3.1a1RC1 which was built longer ago than the builds you have. Perhaps this is a more recent regression...

[Blake Winton (bwinton)]

Works for me on Mac OS X 10.6.2.

src-central - c539ad59cb6c, and (just gotten) 00eb70fa04c4.
mozilla-central - ffab97de1041 and (just gotten) a8810d63a74a.

Works on both new message and replys.
Works on both html and plain text.

Hope this helps narrow down the problem space.

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

(In reply to comment #1)
> I've CCed _Tsk_ hoping for help on the regression / regressionwindow-wanted
> stuff. _Tsk_, is a CC like this actually necessary, or do you have some other
> mechanism in place (eg a bugzilla whine) to keep you apprised of new bugs with
> those keywords?

Thqt4s good; I don4t use Whines as I read all incoming bugmail ( with a few exceptions of resolved threads)

> Assuming this bug does get confirmed as happening 100% of the time (_Tsk_, I
> bet you have keyboard settings similar to davida, perhaps you're a good person
> to do this?), I think it should be marked as blocking 3.1 beta 1.

so for me with french keyboard layout : I get a nice ê while pressing alt-e, If I switch to non French keyboard (in the menu bar) I get a nice é.

David do you have the issue in -safe-mode too ?

[Vseerror (vseerror)]

diacritic / accent bugs with recent activity http://bit.ly/bxxNDA

[Jonathan Protzenko (jonathan-protzenko)]

I experienced the same issue in the mail compose window in Thunderbird 3.1beta1 on Ubuntu Hardy.

One-stroke accented keys are fine: using my French keyboard, I can write things such as é or à using one stroke. However, if I need to write û for instance, I need to hit the "^" dead key and then "u" key. I Thunderbird 3.1beta1, I get just "u" instead of "û".

This happened the first few times I launched beta1. After I restarted Thunderbird two or three times, the problem went away but I thought I'd mention it.

[Vseerror (vseerror)]

is message compose they only place where this is a problem? what about address book, search, etc?

[Jonathan Protzenko (jonathan-protzenko)]

Only in the message compose window. It's very random and usually disappears after a few minutes. I get the feeling it's related to spellcheck somehow. The last time I was able to reproduce the bug (by luck) the "Spell" item from the compose window toolbar was greyed out. I was unable to type ê when suddenly there was some kind of a "reflow" in spellcheck: the red wavelets under some words went away and I was able to immediately type ê after that. It's very vague and random, I'll try to put more information here as soon as I'm able to determine more precisely the root cause.

[Jonathan Protzenko (jonathan-protzenko)]

Ok I finally managed to narrow it down.

Steps to reproduce:
1. Ctrl-N to open a new compose window
2. Set the sender using keyboard only
3. Use tab to jump to the subject then to the body compose area

Results:
The "Spell" button in the compose toolbar is grayed out and I can't enter ê. If I click using the mouse in the body compose area, then the "Spell" button becomes normal and I can enter whichever â ô û I want. This happens again if I move using the mouse to the subject then use tab to move to the body compose area.

[Vseerror (vseerror)]

Jonathan, davida, does this work correctly in an earlier release? ftp://ftp.mozilla.org/pub/thunderbird/releases/

I'd say a 50-50 chance something related is already reported but nothing pops out for me from this query https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&field0-0-0=short_desc&bug_severity=major&bug_severity=normal&bug_severity=minor&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&longdesc=click%20spell&type0-0-0=anywordssubstr&value0-0-0=click%20spell&component=Composition&component=Message%20Compose%20Window&component=Spelling%20checker&field1-0-0=short_desc&product=Core&product=MailNews%20Core&product=Thunderbird&longdesc_type=allwordssubstr

[Jonathan Protzenko (jonathan-protzenko)]

Was working fine with 3.0.3. I'll test with 3.1a1 tomorrow.

[Jonathan Protzenko (jonathan-protzenko)]

Working fine in latest-comm1.9.1 (3.0.5pre). Not working in Lanikai alpha1 on an up-to-date Debian testing. Same behaviour (need to gain focus in the compose area using the mouse to be able to enter diacritics).

[Dmose (dmose)]

CONFIRMing, since more than one person has seen this. Jonathan, any chance you could do a binary search of nightly builds in order to figure out exactly when this regression was introduced? That could allow us to find the code change that did it...

[Jonathan Protzenko (jonathan-protzenko)]

Last good nightly: 2009-06-10 First bad nightly: 2009-06-11

Pushlog: http://hg.mozilla.org/comm-central/pushloghtml?fromchange=f1fcff5eb061&tochange=6c5a94b9bba2

(I ran mozregression twice to make sure I wasn't mistaken).

I don't have a clue as to why might have caused this. The GTk version looks the same... (I first thought it was linked to that). Feel free to ask for more tests if you need to.

[Dmose (dmose)]

Thanks much for tracking down when this happened! I think this is much more likely to be a regression in Gecko than in Tb itself, which means that the mozilla-central pushlog is likely where the real changeset culprit is...

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

(In reply to comment #16)
> Thanks much for tracking down when this happened! I think this is much more
> likely to be a regression in Gecko than in Tb itself, which means that the
> mozilla-central pushlog is likely where the real changeset culprit is...

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-06-10&enddate=2009-06-11

Possible culprit :
 Bug 397986
 Bug 178324

[David-ascher (david-ascher)]

Neil, any guesses? (see comment #10)

[Tristan Grimaux (info-tristangrimaux)]

Same bug here using Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a5pre) Gecko/20100413 Shredder/3.2a1pre.

In the same computer, running Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100203 Shredder/3.0.2pre everything is working OK!

New Mail, tab to get to the body part and start writing: no diacritics. If I type the acute sign, and then the e, it appears the normal e, not the é. If I type the ñ which is a single letter on my keyboard, it appears ok.

If I click on the body with the mouse, I can start typing any character, everything works fine.

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

(In reply to comment #18)
> Neil, any guesses? (see comment #10)

Neil Ping !

[Enn (enndeakin)]

I don't see this bug in current builds, although I did see it in an older build I found lying around. It may have been fixed by the recently checked in bug 544277. Bug 542060 looks to be the same problem.

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #21)
> I don't see this bug in current builds, although I did see it in an older build
> I found lying around. It may have been fixed by the recently checked in bug
> 544277. Bug 542060 looks to be the same problem.

I've tested a couple of nightlies either side, and it looks like that is the situation.

If anyone can try either side of the specific changesets mentioned in bug 544277 that would be useful to help us know for sure.

[Bienvenu (bienvenu)]

taking to see if trunk patch in bug 544277 applies on 1.9.2, and if so, if it solves the problem.

[Masayuki (masayuki)]

FYI: Only on mac, the deadkeys are processed by IME framework.

[Bienvenu (bienvenu)]

Created attachment 444489
possible moz-central fix

Neil, is it crazy for us to try to backport this patch to 1.9.2 to fix this issue for Thunderbird? I had to get around the fact that 1.9.2 doesn't have GetPrimaryFrame, but the patch does seem to fix the bug. If it's crazy, is there a less crazy subset or approach we could try for tb 3.1 w/ 1.9.2? Thx for any insight you can provide.

[Enn (enndeakin)]

Comment on attachment 444489
possible moz-central fix

      nsIMEStateManager::OnTextStateFocus(presContext, aContent);
>+ } else {
>+ nsPresContext* presContext = presShell->GetPresContext();
>+ nsIMEStateManager::OnTextStateBlur(presContext, nsnull);
>+ nsIMEStateManager::OnChangeFocus(presContext, nsnull);
>+ if (!aWindowRaised) {
>+ aWindow->UpdateCommands(NS_LITERAL_STRING("focus"));
>+ }

These few lines may be the only change you actually need to fix this bug.

If not, I can look at the patch in more detail and see.

[Bienvenu (bienvenu)]

Created attachment 444523
minimal patch

yes, thx much, this much smaller patch also fixes it. So, we might land this on our own branch, but it would be nice to get it into 1.9.2, if that's an option.

[Enn (enndeakin)]

Comment on attachment 444523
minimal patch

I assume you didn't mean to remove the blank line.

[Bienvenu (bienvenu)]

(In reply to comment #28)
> (From update of attachment 444523 [details])
> I assume you didn't mean to remove the blank line.

no and yes :-) but mainly no. I had to patch the file by hand, and x-code likes to muck with the formatting so much that I lost track of what the code looked like before. I'll attach a diff w/ the blank line restored.

[Bienvenu (bienvenu)]

Created attachment 444757
fix blank lines

Carrying forward Neil's review, requesting sr. Standard8, which version of 1.9.2 are we shipping 3.1 with? I assume it's worth asking for 1.9.2 approval.

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #30)
> Carrying forward Neil's review, requesting sr. Standard8, which version of
> 1.9.2 are we shipping 3.1 with? I assume it's worth asking for 1.9.2 approval.

So I'm currently planning 1.9.2.4, and given their current issues there, I'm proposing that we land this on a relbranch.

However, we should still get it into 1.9.2, so 1.9.2.5 would be the next one there.

I'm moving this into a core component where we can get approval and FF can track landing.

[Bugzilla-standard8 (bugzilla-standard8)]

Created attachment 444869
Patch with unit test changes from bug 544277

This patch includes the test changes from bug 544277 attachment 440226 - those are needed to keep the mochitests passing on 1.9.2 and help to verify this fix.

I've pushed this to try server, and assuming it passes, then it'll be sr+.

[Bugzilla-standard8 (bugzilla-standard8)]

Comment on attachment 444869
Patch with unit test changes from bug 544277

Ok, try server builds were clear.

Requesting approval for 1.9.2:

This patch is a subset of what was landed on trunk in bug 544277.

Thunderbird needs this to fix various issues with the compose window when using the keyboard to go to the message body editor.

These are focus issues that are regressions from 1.9.1.

[Leandro (leandromartinez98)]

Binary package hint: firefox

When typing e-mails on Gmail on Firefox 3.6.3, if the text field is reached
using the 'tab' key, accent input using a dead-key keyboard don't work.

That is, I cannot type á, é, í, etc.

However, if instead of going to the field by pressing 'tab' y go to it
with the mouse and cilcking, it works.

This is a firefox bug, not a ubuntu bug, because MacOS users are
having the same problem, as reported here:

http://www.google.com/support/forum/p/gmail/thread?tid=6df88c711e266a76&hl=en

I'm posting it here so people knows about it and maybe can communicate to
firefox developers, I'm not sure they are aware of that.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Fri May 21 16:00:18 2010
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox

[Clegnitto (clegnitto)]

Comment on attachment 444869
Patch with unit test changes from bug 544277

a=LegNeato for 1.9.2.6. Please land this on mozilla-1.9.2 default.

[Bugzilla-standard8 (bugzilla-standard8)]

Checked in: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7c3523614fb1

[Ehsan-mozilla (ehsan-mozilla)]

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

[Ara Pulido (ara)]

I have confirmed this to be happening in Maverick as well. Only when using rich formatting. I have linked the upstream bug report. Thanks for taking the time to report this bug.

[Masayuki (masayuki)]

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

[Micah Gersten (micahg)]

Should have been fixed with this upload:
firefox (3.6.7+build2+nobinonly-0ubuntu1) maverick; urgency=low

  * New upstream release v3.6.7build2 (FIREFOX_3_6_7_BUILD2)

  * Make it possible to disable patches on a per-release basis. This
    makes it easier to share packaging branches across releases, and makes
    it possible to disable the patches which make the Hardy daily builds fail
    - update debian/rules
    - add debian/disable-patches.sh
    - add debian/patches/series-disable-patches.8.04
  * Make the debian/usr.bin.firefox.apparmor.in target a dependency of
    pre-build rather than makebuilddir. Whilst this doesn't really change
    much, it is technically slightly more correct (makebuilddir is just for
    creating the build directory, whilst pre-build is for doing all the
    preparation work)
    - update debian/rules
  * Merge the debian/firefox.sh target in to the match-all target, this
    just de-clutters things a little
    - update debian/rules
  * Remove debian/stamp-autotools-files-moz in the clean target
    - update debian/rules
  * Drop the empty firefox-dev and firefox-*-dev transitional packages. We
    didn't install anything in to firefox-dev, and we can reintroduce it in
    the future if anything in the archive depends on the browser specific
    interfaces
    - update debian/control
    - remove debian/firefox-dev.install
    - remove debian/firefox-dev.links
  * Fix some Lintian warnings
    - add debian/README.source
    - update debian/control
  * Make debian/migrator/ffox-beta-profile-migration-dialog a dependency of
    post-patches rather than pre-build. This avoids the need for having to
    build the profile migrator when unpacking the source tarball
    - update debian/rules
 -- Chris Coulson <email address hidden> Thu, 15 Jul 2010 20:27:51 +0100