Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Fennec: input lag on some autocomplete text boxes

NEW
Assigned to

Status

()

Firefox for Android
General
2 years ago
20 days ago

People

(Reporter: avih, Assigned: jchen)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [content perf])

(Reporter)

Description

2 years ago
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

Comment 1

2 years ago
jchen, are there other bugs about this anywhere?
Flags: needinfo?(nchen)
(Assignee)

Comment 2

2 years ago
Hm I don't think so.
Flags: needinfo?(nchen)
(Reporter)

Comment 3

2 years ago
- 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?
Flags: needinfo?(bugmail.mozilla)
tracking-fennec: --- → ?
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.
Flags: needinfo?(bugmail.mozilla)
(Reporter)

Comment 8

2 years ago
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?
Assignee: nobody → nchen
tracking-fennec: ? → 47+
(Assignee)

Comment 10

2 years ago
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?
Flags: needinfo?(miket)
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?
Flags: needinfo?(miket) → needinfo?(kdubost)
(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.
Flags: needinfo?(kdubost)
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?
Flags: needinfo?(snorp)
Yeah let's move the google.com stuff to another bug, since that doesn't seem to be a platform issue right?
Flags: needinfo?(snorp)

Updated

2 years ago
Duplicate of this bug: 1243668
Jim, is this still something you're looking into?
Flags: needinfo?(nchen)
(Assignee)

Comment 21

a year ago
(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.
Flags: needinfo?(nchen)
(Assignee)

Comment 22

a year ago
Untrack for 47 because there's no concrete actionable items at this time.
tracking-fennec: 47+ → ---
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?
Flags: needinfo?(nchen)
(Assignee)

Comment 25

23 days ago
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?
Flags: needinfo?(nchen)
(ni? marco for the question in Comment #25)
Flags: needinfo?(mcastelluccio)
Nexus 5. In Firefox Focus it is nearly instantaneous, in Firefox it is quite slow.
Flags: needinfo?(mcastelluccio)
(Assignee)

Comment 28

22 days ago
Maybe you can show me at the all-hands if you have time? I'm jchen in #mobile.
Flags: needinfo?(mcastelluccio)
Sure, ping me whenever you want. I'm usually in the Golden Gate room.
Flags: needinfo?(mcastelluccio)
See Also: → bug 1377499
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.
You need to log in before you can comment on or make changes to this bug.