904971 - [Buri][TOR] contacts are dissapearing, when try to create

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P1)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184
 Firefox os  v1.1
 Mozilla build ID:20130806071254
 
 DEFECT DESCRIPTION:
 try to create contact name. The device is slow to react. You cannot see what you tape in the screen.
 The name appears suddenyl and dissapears.
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 not good experience at all. This is a standard feature which msut work smoothly and quickly
 
  ASSOCIATE SPECIFICATION:
 Device is just flashed to new sw version. It has enough memeory: application storage 130,8MB. Media storage 222,8 MB
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[buri.blff]

During we input the name, the input lose the focus some time, then the input lose the content we input before.

the Mozilla build ID:20130806071254 has higher reproduce rate.

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

on a partner build dated 20130808, i cannot launch keyboard when trying to create contacts (taping on input fields do not launch keyboad)

and i flashed a 20130813 moz build on buri device, i cannot reproduce.

can you also confirm on a build without any of your changes? thanks

Comment 4

[buri.blff]

this can only be reproduced with some rate.
But  the Mozilla build ID:20130806071254 has a higher reproduce rate.

yes, we don't change the code of keyboard.
In contact, the keyboard is controlled by system, not the contact app.

Comment 5

[buri.blff]

we modify follow code:

gecko/b2g/chrome/content/forms.js/setFocuseElement

we find some times :
line241:  this._editor.removeEditorObserver(this); will crash;

so we add a  try(){}catch(){} this line;

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Alive - this looks like a regression from v1.0.1 can you investigate/help get eyes on this?

Comment 7

[buri.blff]

(In reply to Joe Cheng [:jcheng] from comment #3)
> on a partner build dated 20130808, i cannot launch keyboard when trying to
> create contacts (taping on input fields do not launch keyboad)
> 
> and i flashed a 20130813 moz build on buri device, i cannot reproduce.
> 
> can you also confirm on a build without any of your changes? thanks

we find that the keyboard can't be lauched when trying to create contacts on version:
Mozilla build ID;20130702230206

We find the b2g/chorme/content/forms.js setFocusedElemnet:   this._editor.remvoeEditorObserver(this); crashed.

we add an try{}catch(){}, then can't reproduce this on last version.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to buri.blff from comment #7)
> (In reply to Joe Cheng [:jcheng] from comment #3)
> we find that the keyboard can't be lauched when trying to create contacts on
> version:
> Mozilla build ID;20130702230206
> 
> We find the b2g/chorme/content/forms.js setFocusedElemnet:  
> this._editor.remvoeEditorObserver(this); crashed.
> 
> we add an try{}catch(){}, then can't reproduce this on last version.

There's a patch for this now:

changeset:   138707:e0e452cfde99
user:        Kan-Ru Chen (陳侃如) <[e-mail]>
date:        Tue Jul 16 18:00:58 2013 +0800
summary:     Bug 874754 - Suppress nsIEditor.removeEditorObserver exception. r=fabrice




After reading the comments, I still don't know what's the problem going to be fixed in this bug:
* System doesn't show keyboard ?
  Keyboard focus occurs ?
  Keyboard focus doesn't occur ?
* Key input is slow? Performance? 

Comment 0 seems performance issue, comment 7 said keyboard couldn't be launched.
What if the patch above is applied? fix these two issues or one of them of none?

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

Tested on 20130806071254 Mozilla Inari Eng Build: 
Go to contact -> Add contact -> Enter name

The performance looks good to me..and the keyboard never disappear when I tried to type quickly.

I could provide video if needed.

Comment 10

[Preeti Raghunath(:Preeti)]

Hi Mike,

Can you please check if performance is an issue here?

Comment 11

[buri.blff]

(In reply to Alive Kuo [:alive] from comment #9)
> Tested on 20130806071254 Mozilla Inari Eng Build: 
> Go to contact -> Add contact -> Enter name
> 
> The performance looks good to me..and the keyboard never disappear when I
> tried to type quickly.
> 
> I could provide video if needed.

this can be reproduced with some rate. so the video looks goog is no useful.

i can give the reproduced video.

Comment 12

[buri.blff]

we can't reproduced on version Mozilla build ID;20130812041203 now;
we will monitor this pr for three versions;

Comment 13

[Cheng-An, XIONG]

Attachment: VID_20130809_contactsnotCreated_Compress.7z.001

video part 1/2

Comment 14

[Cheng-An, XIONG]

Attachment: VID_20130809_contactsnotCreated_Compress.7z.002

video 2/2

Comment 15

[Cheng-An, XIONG]

reproduced video provided

Comment 16

[Joe Cheng [:jcheng] (please needinfo)]

Hi Cheng-an, i think it is fixed. i cannot reproduce on our 08/15 build. can you confirm ?Thanks

Comment 17

[Joe Cheng [:jcheng] (please needinfo)]

alive, base on the latest video. do you think the patch from kchen would help? thanks

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

No idea since we cant reproduce.

Comment 19

[Alex Keybl [:akeybl]]

comment 12 and comment 18 suggest this is leo-

Comment 20

[Jack Liu]

Renominate because it was reproduced on Mozilla build ID:20130812041203, please find in attached video. There are three problem: 
1. input field can't get focus.
2. content in input field overlaps.
3. content in input field disappears.

Comment 21

[Jack Liu]

Attachment: PR20130824_170426.mp4

reproduced on Mozilla build ID:20130812041203
input errors--input field lost focus, content overlap, disappear

Comment 22

[buri.blff]

Dear (In reply to Alive Kuo [:alive] from comment #18)
> No idea since we cant reproduce.

Dear Alex:
   you can create contact one by one, when you create fifth or sixth contact,

   you can reproduce this pr; it can be reproduce with high rate on Mozilla build ID:20130817041203

Comment 23

[Preeti Raghunath(:Preeti)]

Alive, please retest on 8/17 build.

Mike, Please check if this a perf issue.

Is this specific to buri?

Comment 24

[buri.blff]

(In reply to Preeti Raghunath(:Preeti) from comment #23)
> Alive, please retest on 8/17 build.
> 
> Mike, Please check if this a perf issue.
> 
> Is this specific to buri?

we can on Mozilla build ID:20130817041203 with 100% rate;

Comment 25

[bhavana bajaj [:bajaj]]

Can you please help try with the latest Mozilla Build to see if you are able to reproduce the issue consistently ?

Comment 26

[Preeti Raghunath(:Preeti)]

David,

I've assigned the bug to you since it is a contact issue.

Comment 27

[buri.blff]

(In reply to bhavana bajaj [:bajaj] from comment #25)
> Can you please help try with the latest Mozilla Build to see if you are able
> to reproduce the issue consistently ?

Mozilla build ID:20130817041203 is our newest version.

Comment 28

[Joe Cheng [:jcheng] (please needinfo)]

Hi Jack, since Mozilla cannot quite reproduce this bug, per our call, your team will assist with the analysis? wonder if you have anything yet? thanks

Comment 29

[Jack Liu]

Hi Joe, we are working on it, but no progress. It reproduced on software base on Moz BuildID 20130826041201. It also reproduced on CDR version we pulled from QC.

Please try to reproduce on your side.

No complicated steps:
1. flash software on device and power on, don't import any contact.
2. create new contact one by one, just input name field then save. Input simple name like 'Aaa', 'Bbb', 'Ccc' etc.
3. the characters inputed in name field disappear, input field lost focus.

Comment 30

[Joe Cheng [:jcheng] (please needinfo)]

i cannot reproduce myself. can QA help to confirm this again? Thanks

Comment 31

[Al Tsai [:atsai]]

I kept seeing the error message logs shown.

Here's the behaviour I saw. I tested what mentioned in Comment 20. 
> 1. input field can't get focus.
> 2. content in input field overlaps.
> 3. content in input field disappears.

Finding:
a) There's no cursor shown on input field
b) I didn't see input field overlaps during testing
c) Content in input field shown very late.

I found the text in input field didn't refresh after I entered. The text field refresh after I changed to another text fields or scroll the page up/down.


E/msm7627a.hwcomposer(  143): drawLayerUsingCopybit: wrong params for display screen_w=480 src_crop_width=480 screen_w=480                                 src_crop_width=480 

--
Test Environment: Mozilla RIL
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/9da3739ce7d7
Gaia   e0d2ebba786a7ea4ea88c11da5ffa7309ebee544
BuildID 20130902041201
Version 18.0

Comment 32

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

This should be a rendering related issue instead of a Gaia issue.
When this issue could be reproduced (I saw the same result as Comment 31), the input data could be saved as the new contacts, which means what Gaia keyboard did to the forms can work.

Comment 33

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

On Unagi, I could not reproduce this issue with the same rev. as Comment 31,
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/9da3739ce7d7
Gaia   e0d2ebba786a7ea4ea88c11da5ffa7309ebee544

Comment 34

[Montoya Clemmons (MClemmons)]

In response to Comment 30, unable to reproduce results following STR in Comment 0. Attempted five times each on both COM and RIL.  In all tests, the device reacted normally. User able to see what is typed on the screen. Name appears and remains on screen prior to being saved and stored on device.

Environmental Variables
Build ID: 20130903041201
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/9da3739ce7d7
Gaia: 8dc90703f4151d6f2a0decede0ee702f425a3a38
Platform Version: 18.1
RIL Version: 01.01.00.019.211

Comment 35

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Restoring Al Tsai as QA Contact, since he took the bug earlier and had some great feedback.

Comment 36

[Jason Smith [:jsmith]]

Triage - comment 31 might imply this is a gfx issue. Other comments imply that this is intermittently reproducible.

Milan - Can we get input from someone on gfx to comment on whether this is a confirmed gfx issue and if this is a critical issue to block on?

Comment 37

[buri.blff]

(In reply to mclemmons from comment #34)
> In response to Comment 30, unable to reproduce results following STR in
> Comment 0. Attempted five times each on both COM and RIL.  In all tests, the
> device reacted normally. User able to see what is typed on the screen. Name
> appears and remains on screen prior to being saved and stored on device.
> 
> Environmental Variables
> Build ID: 20130903041201
> Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/9da3739ce7d7
> Gaia: 8dc90703f4151d6f2a0decede0ee702f425a3a38
> Platform Version: 18.1
> RIL Version: 01.01.00.019.211

you can try it  twenty times not only 5 times;

Comment 38

[Al Tsai [:atsai]]

I believe it only happens on buri only. I tested w/ the same rev. on helix, unagi, leo, and buri. Buri is the only phone with the problem. I agree with Jason that we should investigate if there's something wrong with gfx.

Comment 39

[Joe Cheng [:jcheng] (please needinfo)]

Hi Jack, this seems to be very much to be Buri specific. Wonder if your team has further update on this? thanks

Comment 40

[Natalya Kot [:nkot]]

Attachment: logcat

I was working on different bug which required me to create multiple contacts and I've seen this issue a lot, very high repro rate if not 100%. Agree with comments above, reproduces only on Buri, doesn't reproduce on Leo and Unagi.
Attaching logcat if it can be helpful.

Build ID: 20130903041201
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/9da3739ce7d7
Gaia: 8dc90703f4151d6f2a0decede0ee702f425a3a38
Platform Version: 18.1

Comment 41

[Milan Sreckovic [:milan] (needinfo for best results)]

If it is graphics, it's "lower" than what we usually see, but perhaps Sotaro has an idea.

Comment 42

[Sotaro Ikeda [:sotaro]]

From attachment 799857 [details], buri device is out of pmem state. Then the ui seems not drawn correctly.

-----------------------------------------------------
09-04 16:56:32.279: E/memalloc(140): /dev/pmem: No more pmem available
09-04 16:56:32.279: E/msm7627a.gralloc(140): gralloc failed err=Out of memory
09-04 16:56:32.279: W/GraphicBufferAllocator(140): alloc(300, 396, 1, 00000133, ...) failed -12 (Out of memory)
09-04 16:56:32.299: E/memalloc(140): /dev/pmem: No more pmem available

Comment 43

[Sotaro Ikeda [:sotaro]]

FYI, pmem is used for layer's rendering buffer in gonk. Until recently MozBuild hamachi/leo falled back to shared memory when the phone becomes out of pmem state. This fall back caused another problem at HwComposer rendering(Bug #900029z) The fallback is disabled also on MozBuild hamachi/leo Bug 905784.

Comment 44

[Sotaro Ikeda [:sotaro]]

When gralloc buffer allocation failed, it should fallback to shmem buffer allocation. It might be possible shmem buffer is not rendered when HwComposer is used for rendering. Renderings of HwComposer and OpenGL are dynamically switch between them depend on the layers' condition. 

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/ISurfaceAllocator.cpp#78

Comment 45

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #44)
> When gralloc buffer allocation failed, it should fallback to shmem buffer
> allocation. It might be possible shmem buffer is not rendered when
> HwComposer is used for rendering. Renderings of HwComposer and OpenGL are
> dynamically switch between them depend on the layers' condition. 

It is easy to confirm which rendering(HwComposer/OpenGL) is used for rendering. By enabling "Show frames per second" in Setting app, if fps is shown in the display, it is OpenGL rendering.

Comment 46

[Preeti Raghunath(:Preeti)]

Minus since POVB

Comment 47

[buri.blff]

Maybe this pr is caused by the patch:
      https://github.com/mozilla-b2g/gaia/pull/10389/files;

1 Mozilla build ID:20130702230206 is ok;
2 Mozilla build ID:20130709070206 is ko;
3 replace the file: ID:20130709070206:gaia/apps/system/js/window_manager.js  with window_manager.js in ID:20130702230206, ok;

Comment 48

[buri.blff]

Dear Lee:
   Maybe you can help to resolve this pr, thanks.

Comment 49

[buri.blff]

Dear Lee:
   Can you help to analyse this pr??
   This seriously affect the user experience, and we need to resolve this pr as quickly as possible.
   Hope your help, thanks.

Comment 50

[buri.blff]

is there any progress??

Comment 51

[Al Tsai [:atsai]]

Per comment 45, and the analysis on my side. I believe the issue should be the same as Sotaro mentioned. I tested w/ recent buri build and try to reflash gaia w/ the target pull request backed out. There's nothing different.

More information. The contacts work ok on master branch.

Comment 52

[Joe Cheng [:jcheng] (please needinfo)]

Jack/Amelie, from our call, your team has further information. it will be helpful to provide it. thanks

Comment 53

[buri.blff]

we modify the code in gaia/apps/system/js/window_manager.js as follow:

  function toggleHomescreen(visible) {
    var homescreenFrame = ensureHomescreen();

    if (homescreenFrame) {
      //add for this pr
      if ('setVisible' in homescreenFrame.firstChild)
        homescreenFrame.firstChild.setVisible(visible);
      else
      //end add for this pr
        runningApps[homescreen].setVisible(visible);
    }
  }

now, this pr is ok;
we will ask our val to check the patch;
please help to analysis the patch, is that ok??

Comment 54

[Jason Smith [:jsmith]]

(In reply to buri.blff from comment #53)
> we modify the code in gaia/apps/system/js/window_manager.js as follow:
> 
>   function toggleHomescreen(visible) {
>     var homescreenFrame = ensureHomescreen();
> 
>     if (homescreenFrame) {
>       //add for this pr
>       if ('setVisible' in homescreenFrame.firstChild)
>         homescreenFrame.firstChild.setVisible(visible);
>       else
>       //end add for this pr
>         runningApps[homescreen].setVisible(visible);
>     }
>   }
> 
> now, this pr is ok;
> we will ask our val to check the patch;
> please help to analysis the patch, is that ok??

Can you open a pull request then and ask someone for review?

Comment 55

[buri.blff]

Do you mean i need to commit this patch to github and ask somebody to review??

Comment 56

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to buri.blff from comment #53)
> we modify the code in gaia/apps/system/js/window_manager.js as follow:
> 
>   function toggleHomescreen(visible) {
>     var homescreenFrame = ensureHomescreen();
> 
>     if (homescreenFrame) {
>       //add for this pr
>       if ('setVisible' in homescreenFrame.firstChild)
>         homescreenFrame.firstChild.setVisible(visible);
>       else
>       //end add for this pr
>         runningApps[homescreen].setVisible(visible);
>     }
>   }
> 
> now, this pr is ok;
> we will ask our val to check the patch;
> please help to analysis the patch, is that ok??

I totally don't know why this is related...from log I don't see this introduces an error.

Comment 57

[buri.blff]

we don't have the authority access github;
there is some limitation to access outer net for us； 
so ,we can only give code in commit;

Comment 58

[Preeti Raghunath(:Preeti)]

Alive,

How risky is the patch in question?

Comment 59

[(inactive after 6/18) Alive Kuo [:alive]]

No risk, but I don't know why this fix is valid.

Comment 60

[Jack Liu]

Dears,

Although problem solved by code modification in comment#53, but seems there is subtle relationship between this modification and UI behavior still unknown. There is hidden risk, can you find it out?

Comment 61

[Andrew Overholt [:overholt]]

We discussed this during triage today.  It _seems_ that there is a pmem issue (comment #43, comment #44, comment #45) and the idea in comment #53 does something to work around the issue.

Our conclusion is that further investigation is required by our partner since this is buri-specific.  Hence this being leo- again.

Joe, can you work with our partner to help track this down on their end?  Putting them in touch with Sotaro is probably a suitable course of action (assuming he agrees and has time).

Thanks, everyone.

Comment 62

[Joe Cheng [:jcheng] (please needinfo)]

sure i can link partner to sotaro if needed. thanks

Comment 63

[Lawrence Mandel [:lmandel] (use needinfo)]

Joe, you had the last action here in comment 62. Is there any further work that has to be done here? Can we resolve this bug?

Comment 64

[Joe Cheng [:jcheng] (please needinfo)]

let's close this bug as wont fix since there has been no action being requested anymore
please let me know if we need to pursue this bug further
thanks