Closed Bug 618006 Opened 9 years ago Closed 9 years ago

[Regression] Cannot type in content

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set

Tracking

(fennec2.0b3+)

VERIFIED FIXED
fennec2.0b1
Tracking Status
fennec 2.0b3+ ---

People

(Reporter: wesj, Assigned: ehsan)

References

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

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.
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0b3+
Duplicate of this bug: 617912
For regression-range purposes: I can't reproduce this in a local trunk Android build from http://hg.mozilla.org/mozilla-central/rev/f25461268434
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...
I filed Bug 618013 earlier today for the backspace issue, but I have been seeing weirdness today with text input in general.
Attached patch Patch (v1) (obsolete) — Splinter Review
Can someone try this patch please?
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Duplicate of this bug: 618103
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.
Attachment #496610 - Attachment description: WIP 1 → Patch (v1)
Attachment #496610 - Flags: review?(bzbarsky)
Duplicate of this bug: 618013
Keywords: regression
Attached patch Patch (v2) (obsolete) — Splinter Review
So, this code has been broken for designMode even before bug 612128.  This patches fixes it all.
Attachment #496610 - Attachment is obsolete: true
Attachment #496662 - Flags: review?(bzbarsky)
Attachment #496610 - Flags: review?(bzbarsky)
Blocks: 612128
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.
Attachment #496662 - Flags: review?(bzbarsky) → review-
Attached patch Patch (v3)Splinter Review
(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.
Attachment #496662 - Attachment is obsolete: true
Attachment #496699 - Flags: review?(bzbarsky)
Comment on attachment 496699 [details] [diff] [review]
Patch (v3)

r=me
Attachment #496699 - Flags: review?(bzbarsky) → review+
http://hg.mozilla.org/mozilla-central/rev/a5bbcbc3bd32
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → fennec2.0b1
Duplicate of this bug: 617922
verified FIXED on builds:

Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101210 Namoroka/4.0b8pre Fennec/4.0b3pre
Status: RESOLVED → VERIFIED
Duplicate of this bug: 618252
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached image Screenshot
Please file a new bug.  This cannot be the same bug, because the patch which triggered this has been backed out.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
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
This bug has been fixed.  If you see similar issues, please file new bugs.
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.