Closed Bug 558690 Opened 13 years ago Closed 13 years ago

Textarea input fails unless one clicks elsewhere (addressbar, searchbar, forms, etc) first.

Categories

(Core :: Layout: Form Controls, defect, P1)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.3a5
Tracking Flags:
Tracking Status
blocking2.0 --- beta1+

People

(Reporter: erappleman, Assigned: masayuki)

References

Details

(Keywords: regression)

Attachments

(1 file)

Patch v1.0
766 bytes, patch
karlt
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a4pre) Gecko/20100407 Ubuntu/10.04 (lucid) Firefox/3.7a4pre
Build Identifier: 

Let's say I want to make a post on a message board, I can't start typing in the textarea until I click on a form and type one or more characters into it.

This affects binary builds for 3.7 after and including 3/19.

To the best of my knowledge, below is the appropriate regression range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2cc5ad2cf917&tochange=5108c4c2c043

Reproducible: Always
Version: unspecified → Trunk
Do you have a test URL, as well as a set of steps to reproduce?
Also, are you using IME?
I am not using IME and this can be reproduced on pretty much any site with a message board.

With an affected build, the only thing you need to do in order to reproduce is try to make or an edit a post on a message board. I've been regression testing using ubuntuforums and one of the websites I run.

When I go to create a new topic, if I try to write the body of the post first, I encounter the bug. If I write the topic title first, I don't encounter the bug.
Summary: Textarea input fails unless one types elsewhere (addressbar, searchbar, forms, etc) first → Textarea input fails unless one clicks elsewhere (addressbar, searchbar, forms, etc) first.
BTW, it turns out that I don't need to type anything into a form to enable the textarea, I need only to click it once.
On ubuntuforums.org, when you go to the New Thread page, the textarea for post body is not initially focused, you have to click it to make it focused.  Is that what you're mentioning here?  I tested that website with Chromium as well, and I got the exact same behavior.
That's not the problem.

Even after clicking in the textarea, I can not type in it even if I see the blinking cursor. The textarea does not get a usable focus until I click in a form field.
CCing some QA folks to see if they can come up with a set of steps to reproduce.  I've tried multiple times at reproducing this, without any luck.
Keywords: qawanted
Whiteboard: [needs STR]
Eric, could you come up with a simple testcase which shows that behavior?
Do you have any extensions installed that interact with textareas? Is the problem reproducible in safe mode?
I can reproduce in safe mode and with a fresh profile.
Eric, it would be really helpful if you can provide a set of exact steps to reproduce.  An example of what we can use is something like below:

Using the latest nightly from today:

1. Go to this page: http://....
2. Click the link titled "foo".
3. Wait for the page to finish loading.
4. Scroll down until you see the textarea.
5. Click on the textarea.
6. Start typing.

We need this to be as detailed as possible, because apparently there is more to reproducing this problem than meets the eye.  :-)
1. Create an ubuntuforums account if you don't already have one

2. Go to this page: http://ubuntuforums.org/newthread.php?do=newthread&f=377

3. After the page loads, click on the textarea for the message of the post. A blinking cursor will appear in the textarea. You will not be able to.

4. Additionally, if I was to attain focus by clicking a form field or use another browser to make a post, once I try to edit the post with an affected Firefox build, I cannot add any characters until I click a form field but I have no problems deleting characters with backspace/delete or selecting characters with my mouse or keyboard.
*A blinking cursor will appear in the textarea. You will not be able to type.
Well, I have tried this with trunk builds on OS X 10.6, Ubuntu 9.10, and Win7 x64, and I haven't been able to reproduce this using the STR in comment 12.
That's unfortunate.

Did my regression range pushlog yield any useful information?
There are several changesets inside that range, but I need to be able to reproduce this so that I can bisect and see which changeset has really caused this behavior.

If you're willing to help, you can get on IRC and we can do this in another way, me bisecting the ranges and providing builds for you to test.
Does the same also happens on pages where you do NOT have to create an account first, like http://www.w3schools.com/TAGS/tryit.asp?filename=tryhtml_textarea ?
Last night Eric pinged me on IRC, and offered to help with bisecting to figure out the offending changeset here.  Eric, any updates?
Henrik, the site you linked is not affected. For what it's worth, neither is the comment box for this bugzilla page.

Ehsan, yes I have.

The first bad revision is:
changeset:   39627:c73392866d96
user:        Masayuki Nakano <masayuki@d-toybox.com>
date:        Fri Mar 19 13:21:16 2010 +0900
summary:     Bug 520732 Separate IME related code to another file from gtk2/nsWindow.cp r=katakai+karlt
(In reply to comment #19)
> The first bad revision is:
> changeset:   39627:c73392866d96
> user:        Masayuki Nakano <masayuki@d-toybox.com>
> date:        Fri Mar 19 13:21:16 2010 +0900
> summary:     Bug 520732 Separate IME related code to another file from
> gtk2/nsWindow.cp r=katakai+karlt

Thanks Eric! Lets cc Masayuki.
Blocks: 520732
Keywords: regression
thanks, this bug is going to be fixed by the patch of bug 558978.
Assignee: nobody → masayuki
Status: UNCONFIRMED → ASSIGNED
Depends on: 558978
Ever confirmed: true
(In reply to comment #21)
> thanks, this bug is going to be fixed by the patch of bug 558978.

oops, no. this is another bug.
No longer depends on: 558978
Attached patch Patch v1.0 — — Splinter Review 
I see the cause. nsGtkIMModule::CancelIMEComposition() calls ResetIME() intentionally. That sets mShouldIgnoreNativeCompositionEvent to true. By this flag, nsGtkIMModule discards any composition events after that. I'm not sure why composition events are used for inputting ASCII text on Ubuntu.

# CancelIMEComposition() is called only when the focused editor is destroyed. E.g., when an editor focused in a document, reload the page by any ways.
Attachment #438909 - Flags: review?(karlt)
From what I can tell on my end, the patch does seem to resolve the bug.

I tested against 058b1d064f88.
blocking2.0: --- → ?
> I'm not sure why composition events are used for inputting ASCII text on Ubuntu.

Worth a followup bug to sort that out?
(In reply to comment #25)
> > I'm not sure why composition events are used for inputting ASCII text on Ubuntu.
> 
> Worth a followup bug to sort that out?

It's not a bug. I just wondered. Ubuntu doesn't need to use the events, but sent to us by some reasons. (querying caret position?)
Well, are we sure it's Ubuntu doing it and not part of our code?  Are there any performance implications from those events?
> Well, are we sure it's Ubuntu doing it and not part of our code?

"composition event" which I said in previous comment is a signal from GTK.

> Are there any performance implications from those events?

No, the composition signals are not handled as IME composition in this case. They are handled as keydown/keypress/keyup events for generating DOM events.

And also even if the IME pass is too slow, we cannot use IME :)
Attachment #438909 - Flags: review?(karlt) → review+
http://hg.mozilla.org/mozilla-central/rev/68737c373aba
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Keywords: qawanted
Whiteboard: [needs STR]
blocking2.0: ? → beta1+
Priority: -- → P1
You need to log in before you can comment on or make changes to this bug.