We want to measure this: * how long from when a keyboard key is pressed to when you see a response ** Specifically how soon you see the tapped key's tooltip, measuring when the tapped key appears in the input field is different. I am thinking of a test which brings up the onscreen keyboard, starts the capture, then presses a key. When bug 888102 is fixed, we should be able to measure the time difference between the input event being generated and the visual response.

William, Any idea what about this bug is causing its Product and Component fields to not update correctly? To get this into an FxOs Performance sprint I've been trying to change this bug's Product to Boot2Gecko and Component to Gaia::Keyboard but Bugzilla doesn't seem to be updating the Component list after I switch the Product.

From what I just learned from the bugzilla developers, Product needs to be changed first. Once that's changed and saved you can change Component. I'll try this now.

I expect this bug to be a bit tricky / fiddly.

William, I'm also interested in the following tests: - how long do we wait for the keyboard to show up an be usable when we focus on input field. - how long do we wait from a tap on a keyboard key until the input field is updated.

William, may I know if there is any update on this work? Anything we can help to get this performance data collected as a log? Thank you.

(In reply to Rudy Lu [:rudyl] from comment #5) > William, may I know if there is any update on this work? > Anything we can help to get this performance data collected as a log? > > Thank you. Hi Rudy, work on this has never really started, other eideticker related tasks took priority. I'd of course be happy to help anyone interested in working on this, but there is currently no timeline for this test being completed. I'm not sure what you mean by collecting performance data as a log.

(In reply to William Lachance (:wlach) from comment #6) > (In reply to Rudy Lu [:rudyl] from comment #5) > > William, may I know if there is any update on this work? > > Anything we can help to get this performance data collected as a log? > > > > Thank you. > > Hi Rudy, work on this has never really started, other eideticker related > tasks took priority. I'd of course be happy to help anyone interested in > working on this, but there is currently no timeline for this test being > completed. Thanks for the reply. I think these tests are very important in order to improve keyboard performance, because we need to measure the response precisely for each build, so that we can go on to tweak something in the keyboard app. > > I'm not sure what you mean by collecting performance data as a log. I mean put these test results on datazilla or somewhere to make sure we don't regress and have some improvement along the way. -- William, I heard that you work on some eideticker tests before for keyboard, do you have anything that's related to this bug to share? Thank you.

(In reply to Rudy Lu [:rudyl] from comment #7) > (In reply to William Lachance (:wlach) from comment #6) > > (In reply to Rudy Lu [:rudyl] from comment #5) > William, > > I heard that you work on some eideticker tests before for keyboard, do you > have anything that's related to this bug to share? > Thank you. Ah yes, I forgot! Yes, I believe William Hsu has done some work in this area. I'll leave it to him to say more.

Hi, Will and Rudy, Good day. After performance work week and B2G reorganization, I had been told that stop working on performance related works since stakeholders decided to push performance related work back to each component owner. Any performance task should be handled by OS QA. All that we did is measure the keyboard launch time on E.ME input field as bugs mentioned. - Bug 946298 - Measure performance of keyboard after OOP patches land - Bug 970188 - [Buri][Keyboard][Performance] The re-launch time of keyboard is around ~1.2 seconds - Bug 970193 - [Keyboard] The first switching time of third party keyboard spends ~1.6 seconds But, these script might be out-of-date since it is applied for FxOS v1.3~v1.4 version. mmm...we can consider if we need to retake these work. Perhaps, Tim can help communicate this stuff. Thanks! :)

(In reply to William Hsu [:whsu] from comment #9) > Hi, Will and Rudy, > > Good day. > After performance work week and B2G reorganization, I had been told that > stop working on performance related works since stakeholders decided to push > performance related work back to each component owner. > Any performance task should be handled by OS QA. Sorry! Some internal stuffs was mentioned, so I added a Confidential tag here. If you think there is no need to add this, please remove it. Thanks.

Hey William, in general I would prefer if we could keep this public. There's some internal Mozilla organizational details in here, but I don't think revealing those is that big a deal. Is there anything I'm missing?

(In reply to William Lachance (:wlach) from comment #11) > Hey William, in general I would prefer if we could keep this public. There's > some internal Mozilla organizational details in here, but I don't think > revealing those is that big a deal. Is there anything I'm missing? Okay! Thanks for the reminder. Remove it. :)

Eideticker has been discontinued, see bug 1361056