Typing into the address bar will not display all characters input into the URL field, albeit I see the input values change for search engines listed. Deleting all input will eventually erase all hidden characters and scrub what was initially visible See video that best showcases this: http://www.youtube.com/watch?v=tYSCw8OW7bM&hd=1 Tagging [ICS] but I don't know if this happens on other devices. I am using the stock Android Keyboard in Android 4.0 (Ice Cream Sandwich) -- Samsung Galaxy Nexus (Android 4.0.2) Nightly (02/08) Mozilla/5.0 (Android; Mobile; rv:13.0a1) Gecko/13.0a1 Firefox/13.0a1
tracking-fennec: --- → ?
status-firefox11: --- → affected
status-firefox12: --- → affected
status-firefox13: --- → affected
Summary: Text input into the URL bar seemingly does not display all characters typed → Text input into the URL bar does not display all characters typed
Assignee: nobody → cpeterson
Priority: -- → P3
Looking at the video I'd guess it might be related to the way how we switch from Go to Search mode with input restart. After the "." was entered, the Awesomebar should have switched to the URL mode, might be something wrong with that switch. Note in the video the moment when it switches back to the Search mode, the typed text briefly appears in the edit box. I didn't see anything like this on 2.2-3.x - might be actually specific to ICS.
Nightly 13.0a1 (2012-02-26) Aurora 12.0a2 (2012-02-26) Device: Samsung Nexus S - Android 2.3.6 Samsung Galaxy Nexus - Android 4.0.2 I wasn't able to reproduce issue on either device. Aaron can you verify it on latest nightly.
(In reply to Camelia Urian from comment #2) > Aaron can you verify it on latest nightly. I'll comment again if I can reproduce.
I can't seem to repro either...
:aasonmt, when you first reported the problem, was it intermittent? I am not able to repro (though I have not tested the Nightly 2012-02-08 build).
aaron, reopen if you can reproduce.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
This still happens. See video: http://www.youtube.com/watch?v=tYSCw8OW7bM&hd=1
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I think we need the steps leading before what the video shows to get to this state.
This tends to happen when the InputMethodManager switches modes from Go to Search.
Aaron, could you test this using the latest nightly (2012-3-13 or later)? As long as I read comment #9, I think that this may be fixed by bug 715207.
given how hard this is to reproduce, not a blocker.
tracking-fennec: --- → +
blocking-fennec1.0: + → -
Priority: P3 → P2
It would switch from Search to Go after hitting a period. It still doesn't happen all the time. not sure what other conditions are necessary.
(In reply to Makoto Kato from comment #10) > Aaron, could you test this using the latest nightly (2012-3-13 or later)? > As long as I read comment #9, I think that this may be fixed by bug 715207. I was using an inbound build this afternoon which should contain that bugs fixes but I still hit this bug.
This bug may depend on bug 737653.
I just reproduced this again today having not since my last reply here. I was typing the URL: kevs3d.co.uk and with the last . entered the uk was stiffled and was not shown.
During QA triage Kevin mentioned he has also seen this using SwiftKey on his Galaxy Nexus. Removing keyword: 'qawanted' for the moment to take this off our triage since this bug has declared not blocking 1.0
To further clarify this is a very intermittent bug. Would a debug build have IME logging so that we can capture this live or would this require a special build?
The logcat output from a regular build would be helpful, but I can prepare a special build with verbose IME logging if you find a way to reproduce the bug more often. Just let me know.
Keywords: regression, regressionwindow-wanted
Whiteboard: [ICS], [QA^] → [ICS]
I have not seen this in a while.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.