Closed Bug 639406 Opened 13 years ago Closed 13 years ago

Text entered into an input field or text area near the bottom of the page won't Invalidate until that element is blurred

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(fennec2.0+)

Status:
RESOLVED DUPLICATE of bug 593243
Tracking Flags:
Tracking Status
fennec 2.0+ ---

People

(Reporter: blassey, Assigned: azakai)

References

Details

(Keywords: inputmethod, Whiteboard: [vkb]) 

STR:
1) go to bugzilla.mozilla.org
2) focus in on the comment box at the bottom
3) start typing

Usually the first word shows up in the box, but anything after that doesn't get painted until you click somewhere else on the page. This makes text entry extremely hard.
tracking-fennec: ? → 2.0+
Does it happen only on device? I can't reproduce it on desktop
I'm seeing this on  my i9000 consistently but not on my nexus one
I can't reproduce on Galaxy S or on desktop.
I can reproduce on a N1 and on a Samsung Galaxy Tab
I am still seeing this with the current nightly. I'm using swype, perhaps that's a factor
with the regular Samsung keyboard things work better. once an IME composition is commitTed the text shows up. however,  the  intermediate text doesn't show up u though and neither do deletions until there is a commit
Hmm, I can reproduce something that sounds very similar as follows:

1. Load bugzilla.mozilla.org
2. Click on "log in" at the *bottom* of the page
3. Try to enter text in the username or password fields.
4. If you succeed, click outside on the page, then re-enter that field and try to enter text again (this step is not always needed, and when needed, is needed exactly once).

Nothing gets entered until you click elsewhere on the page. (Using the form assistant to move to another element doesn't help.)

This does not happen with the *TOP* login form, oddly enough.

I don't see the behavior mentioned in comment 0, though, of the first word appearing but nothing else (I get nothing at all, until I blur).

Seeing this on Galaxy S (and not on desktop).
so, with the original STR, but with completions enabled for my nexus ones' keyboard I see the same behavior as I saw with the samsung keyboard on the i9000 (text doesn't show up until its committed).
Summary: Text entered into an input field or text area doesn't display until that element is blurred → Text entered into an input field or text area via IME compositions doesn't display until that element is blurred
Keywords: inputmethod
OS: Linux → Android
Hardware: x86_64 → All
Whiteboard: [vkb]
Do you see the cursor blink when this problem occurs?
OS: Android → Linux
Hardware: All → x86_64
(In reply to comment #9)
> Do you see the cursor blink when this problem occurs?

I can reproduce both your STR and Brad's one and none of them have a blinking cursor. Redraw seems frozen.
I have no clue where this happen, it seems like the event are well sent from the java side to the appshell but no redraw happens.
Assignee: 21 → nobody
Taking.
Assignee: nobody → azakai
I am investigating why the cursor does not blink - I assume it is for the same reason text cannot be entered.

So far it looks like we hit this:

http://hg.mozilla.org/mozilla-central/file/475ae5b49540/view/src/nsViewManager.cpp#l576

which causes us to stop before we Invalidate the Widget. The cursor timer runs, and it Paints, but Invalidate is not called because of this condition. (I assume the same is true for text - it is drawn, but no Invalidate happens so it can't be seen.)
stechz suspected this is due to bug 593243, and I can confirm it is fixed with the patch from there.
Depends on: 593243
Summary: Text entered into an input field or text area via IME compositions doesn't display until that element is blurred → Text entered into an input field or text area near the bottom of the page won't Invalidate until that element is blurred
So, this isn't an IME problem at all. The issue is that Invalidates don't happen properly on elements near the bottom of the page.

Still can't reproduce this on desktop, but probably I haven't gotten the window shape just right.
For purposes of fixing this bug, we don't need the entire patch in bug 593243, just the part relevant to the line mentioned in comment 14,

diff --git a/view/src/nsViewManager.cpp b/view/src/nsViewManager.cpp
@@ -570,8 +570,8 @@ nsViewManager::UpdateWidgetArea(nsView *
   }
 
   // If the bounds don't overlap at all, there's nothing to do
-  nsRegion intersection;
-  intersection.And(aWidgetView->GetDimensions(), aDamagedRegion);
+  nsRegion intersection = aDamagedRegion;
   if (intersection.IsEmpty()) {
     return;
   }
The patch in comment 17 wouldn't fix the test in bug 593243.

I really couldn't guess off-hand why bug 593243 wouldn't fix this, as Stuart reports.  I don't know how <input>s are invalidated+redrawn, but the possibilities for 593243 not fixing this are
 (1) invalidations from <input>s aren't making it out of the nsHTMLScrollFrame.  Seems unlikely if comment 17 fixes things.
 (2) invalidations from <input>s make it out of nsHTMLScrollFrame but are still being clipped in the view system.  I don't know how that could happen; lost in "translation" somewhere?
 (3) text input invalidates through a different path that 593243 doesn't fix.

It's easy to write a test for (3), but that wouldn't necessarily tell why this bug isn't fixed.

If all else fails and we get down the eleventh hour without a real fix, maybe we could implement a hybrid of comment 17 and bug 593243 in which clipping of *ScrollFrame invalidations is expanded to the displayport, and view invalidations aren't clipped at all if a flag is set.
When I try to reproduce this on desktop, I see

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLInputElement.selectionEnd]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/forms.js :: _formHelperGetCaretRect :: line 546"  data: no]
************************************************************

after clicking on the "Password" input box in bugzilla.mozilla.org.  Related?
Do you see that with both the top and bottom password input boxes on bugzilla.mozilla.org?
Top and bottom.  I can't input text into either until I try to focus the box again.
Does text that you typed, but did not appear, appear when you click outside the input element?
No.  After clicking on the input and apparently failing to focus it, after each letter I type on the keyboard, the same

--DOMWINDOW == 2 (0x114a8a8) [serial = 2] [outer = 0xdac830] [url = about:blank]
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLInputElement.selectionEnd]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/forms.js :: _formHelperGetCaretRect :: line 546"  data: no]
************************************************************

always appears (once per letter).  After entering any number of letters, if I then click anywhere else on the page, nothing happens.

This may be a separate bug, just thought I'd mention it here in case anyone who knows form assistant thinks it might be related.  Doesn't happen for the "e-mail address" fieldl; that seems to work fine.
That sounds like a separate bug.
STR
 (1) Disable form assistant (formhelp.enabled=false)
 (2) Load http://people.mozilla.com/~cjones/input-test.html on galaxy tab in portrait orientation
 (3) Scroll about halfway down page, focus input
 (4) Scroll input to just above VKB

When I enter letters, I don't see it appear immediately.  Keeping the input field focus, I can scroll it far enough above the VKB to where I start seeing text appear when I enter it.

(This is without the patch from bug 593243.)
I can't reproduce with 593243 applied.  Double-checking reliability of STR.
100% reproducible for me without 593243, 100% not reproducible with it.
fwiw, I'm experiencing this on an N1 with the standard keyboard on the photo comment textarea on flickr.
Marking duplicate based on comment 29.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.