618006 - [Regression] Cannot type in content

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Wesley Johnston (:wesj)]

Using todays nightly (20101209), characters typed in content text fields do not appear in content. This has been reproduced by me on a Droid X and stechz on a Galaxy Tab (both have soft kb).

STR:
1.) Open google.com
2.) Focus the text field
3.) Type
Result: Suggestions show up, but nothing appears in the textbox

I'm also seeing other weirdness. I can not use the delete key on my keyboard to erase text, and typing numbers sometimes moves the cursor (in particular in the sync key entry blank). Stechz saw problems when focusing the filter box for select elements. Not sure if they are related or separate bugs.

Noming to block beta 3.

Comment 2

[Matt Brubeck (:mbrubeck)]

For regression-range purposes: I can't reproduce this in a local trunk Android build from http://hg.mozilla.org/mozilla-central/rev/f25461268434

Comment 3

[Matt Brubeck (:mbrubeck)]

m-c regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f25461268434&tochange=0f28e112a6b6

Comment 4

[(no longer active)]

So, the major thing which changes in bug 612128 is that input and textarea elements do not have the NODE_IS_EDITABLE flag any more.  Does Fennec rely on this flag?  If yes, it should switch to using NS_EVENT_STATE_MOZ_READWRITE...

Comment 5

[Marcia Knous [:marcia]]

I filed Bug 618013 earlier today for the backspace issue, but I have been seeing weirdness today with text input in general.

Comment 6

[(no longer active)]

Attachment: Patch (v1)

Can someone try this patch please?

Comment 8

[(no longer active)]

Comment on attachment 496610 [details] [diff] [review]
Patch (v1)

So, I didn't manage to reproduce the problem in a test, but I have confirmation that this indeed fixes the problem, so let's just take the patch for now.

Comment 10

[(no longer active)]

Attachment: Patch (v2)

So, this code has been broken for designMode even before bug 612128.  This patches fixes it all.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 496662 [details] [diff] [review]
Patch (v2)

>   if (aContent) {

OK, so we're starting with _something_.

>+    if (!root && content) {
>+      // See if the document is editable

So here root being null means aContent didn't have the READWRITE flag, right?  And if that's the case, then we know content == aContent and in particular content is not null.  So that |&& content| check makes no sense.

But also, if everything on the parent chain of aContent has the READWRITE flag, then we'll land here with root nonnull but content null, and in that case we _also_ want to examine the document, right?

>+      nsIDocument* doc = content->GetOwnerDoc();

You want GetCurrentDoc, I'd think.

Comment 12

[(no longer active)]

Attachment: Patch (v3)

(In reply to comment #11)
> Comment on attachment 496662 [details] [diff] [review]
> Patch (v2)
> 
> >   if (aContent) {
> 
> OK, so we're starting with _something_.

Right.

> >+    if (!root && content) {
> >+      // See if the document is editable
> 
> So here root being null means aContent didn't have the READWRITE flag, right? 
> And if that's the case, then we know content == aContent and in particular
> content is not null.  So that |&& content| check makes no sense.

Right.  I removed the check and converted it into an assertion in order to be future proof.

> But also, if everything on the parent chain of aContent has the READWRITE flag,
> then we'll land here with root nonnull but content null, and in that case we
> _also_ want to examine the document, right?

No.  That should happen where the document element is contentEditable.  In that case, the document element would be the editable root, and checking the document would give us the wrong result (because it might not be in design mode, for example).  So we should just return |root|.

> >+      nsIDocument* doc = content->GetOwnerDoc();
> 
> You want GetCurrentDoc, I'd think.

Fixed.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 496699 [details] [diff] [review]
Patch (v3)

r=me

Comment 14

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/a5bbcbc3bd32

Comment 16

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101210 Namoroka/4.0b8pre Fennec/4.0b3pre

Comment 18

[Ayan Shah[:ashah]]

I saw this again on 

Mozilla/5.0(Android; Linux armv7l; rv2.0b8pre)Gecko/20101214 Firefox/4.0b8pre Fennec/4.0b3

But it is reproducible 5/10 times. See screenshot attached.

Comment 19

[Ayan Shah[:ashah]]

Attachment: Screenshot

Comment 20

[(no longer active)]

Please file a new bug.  This cannot be the same bug, because the patch which triggered this has been backed out.

Comment 21

[Cristian Nicolae (:xti)]

This issue is still reproducing on Sony Ericsson Xperia X10 - Android
2.1-update1
Please see the following video:
http://www.youtube.com/user/qaioana#p/a/u/0/lckokurNxfg

Build id : Mozilla/5.0 (Maemo;Linux armv7l;rv:2.0b13pre)Gecko/201100310
Firefox/4.0b13pre Fennec /4.0b6pre
Device: Sony Ericsson Xperia X10
OS: Android 2.1 update 1

Comment 22

[(no longer active)]

This bug has been fixed.  If you see similar issues, please file new bugs.

Comment 23

[Andreea Pod]

VERIFIED FIXED on:
Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110315
Firefox/4.0b13pre Fennec /4.0b6pre
Device: HTC Desire