When using either the on screen keyboard or an external keyboard, on some text boxes with autocomplete, there's sometimes a considerable lag (200-500ms) between the keypress and the the text box reflecting it (be it a letter or the "backspace" key, etc). This doesn’t happen with Chrome, or at least to a much lesser degree. I didn't analyze if it's the content itself which interpres the KB input and renders the text at the box, or whether it's a "Regular" text box which Fennec should manage on its own. Most notable on http://google.com search autocomplete, but also happens with bing. Test clip (shows both Fennec and Chrome): https://people.mozilla.org/~ahalachmi/share/content-perf/fennec-input-lag~2015-10-19.mp4 Tested using: Fennec: Aurora 43.0a2 API11 2015-09-30 Chrome: 39.0.2171.93
jchen, are there other bugs about this anywhere?
Hm I don't think so.
- Do you identify/understand the issue at the video? - Could any of you try to reproduce?
I usually have severe input lag when typing in text fields in a web app that I have. It's not publicly accessible but if you want to me run a build with debug logging or whatever I can do that.
(The text fields in my thing are just regular text fields, no JS involved)
Kats, can you try using the devtools profiler with it?
I don't think the issue I was seeing happens any more. And anyway web apps are going the way of the dodo, and that was part of my STR.
My STR was to visit google.com and type something at the search box, and I just confirmed it still happens with latest Fennec nightly (2016-01-26) - both when typing and when deleting text. I then tested in Chrome, and it doesn't happen at all while typung, but does happen when deleting text. So I don't think the issue went away, and I also don't think it's irrelevant.
Jim, let's see if there is anything we can do here, because the experience sucks. Maybe we're emitting more or different events which causes more work for the autocomplete script?
Interestingly, if I change the UA to "Android (Phone)" through the Phony addon, I get a different version of google.com (the version that Chrome gets), and the text input is a lot smoother in that version.
Sigh. Mike, who do we know at Google these days? Anyone on search?
We have an internal list we can nag about issues -- but we probably should understand what the differences are between the two to have a better shot at getting a fix. On the other hand, Google is pretty good about sending us a different version, if we test that it works as expected -- a quick test in Release while spoofing as Android looks just as good as in Nightly with the webkit stuff enabled. And the input lag differences are *very* noticeable between versions. Karl, would you mind doing another comparison between the two UAs and with the webkit prefs on/off? And if it's good, ask Google to make the switch for us?
(alternate strategy would be to use our ua-override mechanism, but I think having Fennec appear in google.com usage stats is something we want)
Are we talking only about www.google.com? Aka the search engine. We have already a couple of bugs not on this specific input issue, but more on the overall design and features of this page in Firefox Android. I should go again through this list of bugs to check the changes, what's new and what's gone/fixed and maybe group them by type of services. http://www.otsukare.info/2014/10/28/google-webcompatibility-bugs-list Google Search we have already for Firefox Android specifically * Bug 921532 * Bug 975444 Asking another version is a viable solution BUT after extensive testing of all features. We did that in December 2015 with Mike and Hallvord for gmail and we discovered some issues here and there not visible at first. To test, take usually a couple of hours to a couple of days, (logged in and not logged in), etc.
Yep, google.com -- the search engine. It's probably worth going through those search bugs again anyways.
I see at the beginning of the bug that the lag seems to happen in other properties too. Should we have a separate bug for this one if it's really an outreach issue, also we need to find out where it's happening and why it's happening in between the two received versions.
We probably want a new bug to test the Google.com search stuff, if indeed this is a perf issue across other sites - WDYT snorp?
Yeah let's move the google.com stuff to another bug, since that doesn't seem to be a platform issue right?
Jim, is this still something you're looking into?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #20) > Jim, is this still something you're looking into? Not actively, but we may revisit it later. And to be clear, the google.com issue will be in a separate bug. This bug is for input lag outside of google.com.
Untrack for 47 because there's no concrete actionable items at this time.
I can reproduce this on several websites, including Google and IMDB.
(In reply to (pto) Jim Chen [:jchen] [:darchons] from comment #21) > (In reply to Ryan VanderMeulen [:RyanVM] from comment #20) > > Jim, is this still something you're looking into? > > Not actively, but we may revisit it later. And to be clear, the google.com > issue will be in a separate bug. This bug is for input lag outside of > google.com. Should I file a new bug specifically for IMDB? Which is the bug for Google?
Google and IMDB autocomplete are nearly instantaneous for me on my Nexus 5x using Nightly. Which device are you using? What's the behavior in Chrome?
(ni? marco for the question in Comment #25)
Nexus 5. In Firefox Focus it is nearly instantaneous, in Firefox it is quite slow.
Maybe you can show me at the all-hands if you have time? I'm jchen in #mobile.
Sure, ping me whenever you want. I'm usually in the Golden Gate room.
I think the slowness with Google was fixed when I replaced AdBlock Plus with uBlock Origin. The problem with IMDB is actually probably on their end, so I fixed bug 1377499 for that.