Closed Bug 712972 Opened 9 years ago Closed 9 years ago
Can't type mzl
.la into awesome bar
I can't type mzl.la into the awesome bar. After I type "mzl.", when I click the next "l" the awesome bar drops the "mzl." portion (so I just see "l"). I see the same behaviour if I type "http:" when I next click "/" the "http:" portion is dropped from the awesome bar leaving just "/".
It works fine for me on the latest Nightly build. -- Mozilla/5.0 (Android;Linux armv7l;rv:12.0a1)Gecko/20111222 Firefox/12.0a1 Fennec/12.0a1 Devices: Samsung Galaxy S OS: Android 2.2
I just updated to 20111222 and still no joy. build: 20111222 Device: Samsung Galaxy S II OS: Android 2.3.4 keyboard: Swype
Oh, I see this on both Nightly and Aurora 20111222.
(In reply to Lawrence Mandel [:lmandel] from comment #3) > Oh, I see this on both Nightly and Aurora 20111222. I've tried both with Android Keyboard and Swipe and it's still working fine for my device. We need to see what's happening here. Could you upload a video about your performing steps please? It might be helpful
Here's a video (sorry about the quality) that shows the issue. http://www.youtube.com/watch?v=XNavZVJOnN8
Lawrence, what keyboard are you using?
Assignee: nobody → alexp
Priority: -- → P3
(In reply to Brad Lassey [:blassey] from comment #6) > Lawrence, what keyboard are you using? Comment #2 says Swype. I have the exact same phone, OS, keyboard and don't see this.
Yes. Using Swype, which came installed on the phone. I also tried clearing the data for Aurora and restarting but have the same results.
I see this behavior on a Galaxy Tab 10.1 with pre-installed Swype v.188.8.131.52889 and Nexus One with Swype v.3.25.91D.31083, but no such problem on Droid 3 with Swype v.184.108.40.206214.30244. Doesn't happen with other IMEs either.
Whiteboard: [mtd] → [mtd][VKB]
This is caused by the way how Swype handles auto-completion. It is treating "mzl." string as a text to be replaced with a suggestion, and when the "l" is entered it decides to replace the text with an empty string (as there are no better suggestions). I'm going to disable suggestions for the URL, which will fix this issue.
Disable suggestions for the AwesomeBar edit field. I tried to modify this parameter dynamically, so that when the AwesomeBar is in the Search mode, the suggestions were still made, but it doesn't seem to work when changed on the fly, so for now it's just a static unconditional disabling.
Madhava, this patch will disable all IME suggestions in the url and search bar. Is this ok with UX?
This works fine in the stock browser on my Galaxy S II: the input isn't eaten and I get autocompletion suggestions on elements of domain names. That said, I can't really think of when I've found domain-name-component autocompletion particularly useful.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #15) > That said, I can't really think of when I've found domain-name-component > autocompletion particularly useful. But for searching it might be useful, which would be impacted by this as well, right?
(In reply to pretzer from comment #16) > > That said, I can't really think of when I've found domain-name-component > > autocompletion particularly useful. > > But for searching it might be useful, which would be impacted by this as > well, right? Right - that's why we want UX confirmation.
FYI: disabling "Word suggestion" in Swype settings bypasses the problem for me.
(In reply to aja+bugzilla from comment #18) > FYI: disabling "Word suggestion" in Swype settings bypasses the problem for > me. You mentioned on IRC it started misbehaving for you just 2-3 days ago. Can you actually confirm it? This bug has been around for quite a while, and I don't think anything has changed since it was found. I am asking just in a hope to find a cause, which might affect the behavior.
As agreed with Madhava on IRC, we should push this fix, but follow up in the bug 719527 to re-enable the input suggestions for Search mode. One more consideration to take into account. Many IMEs do not suggest words in the AwesomeBar anyway. That includes the standard Android keyboard, Motorola Multi-touch keyboard, Swiftkey X, and some others, so the actual number of users affected by this change is not that huge.
Updated the fix.
Attachment #589940 - Flags: review?(blassey.bugs) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 12
Comment on attachment 589940 [details] [diff] [review] Fix (updated) [Approval Request Comment] Regression caused by (bug #): User impact if declined: Impossible to type URLs in Awesomebar with Swype Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): Low
Attachment #589940 - Flags: approval-mozilla-aurora?
Comment on attachment 589940 [details] [diff] [review] Fix (updated) [Triage Comment] Mobile only - approved for Aurora.
Attachment #589940 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I cannot reproduce this issue on Nightly 13.0a1 (2012-02-01) Aurora 11.0a2 (2012-02-01) Device: Samsung Galaxy S II OS: Android 2.3.4 keyboard: Swype Verifying.
You need to log in before you can comment on or make changes to this bug.