Closed Bug 901395 Opened 7 years ago Closed 6 years ago

[Buri][Contacts]"Select all" and "Deselect all" bottons are blinking when scrolling in the friends list

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)

defect

Tracking

(blocking-b2g:leo+)

RESOLVED WORKSFORME
blocking-b2g leo+

People

(Reporter: sync-1, Assigned: BenWa)

References

Details

Attachments

(4 files)

SW174
 AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171
 Firefox os  v1.1
 Mozilla build ID:20130722070207
 
 DEFECT DESCRIPTION:
 (1)Go to contacts, try to import one facebook account
 (2)After login, the friends list is diaplayed OK. Select "Select All", then try to scrolling down in the list. 
 (3)The buttone "Deselect all" and "Select all" are blinking, don't know which one is highlighted.  And when stop scrolling, after the avatars are dispalyed, the "Select all" is highlighted wrongly. ---- NOK
 
 Please check attached video.
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 After user choose "Select all", "Deselect all" should be always highlighted.There should be no blinking or , highlight select all agin.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 100%(tried with two facebook account, one has 1033 friends, another has about 350 friends. Both are NOK)
 
  For FT PR, Please list reference mobile's behavior:
Clone from brother
Attached video Video for the problem
Attached file the vedio for this pr
blocking-b2g: --- → leo?
Can you provide logcat output?
adb log with 'Gaia debug traces' enable??
Attached file log85.log
this might be a Gecko issue as it cannot be reproduced on other devices. Who on the platform side could have a look on this?
Flags: needinfo?(jcheng)
Thank you for the log.  This looks like another symptom related to bug 900029.

Was this produced with a vendor build?  QA, can you reproduce using these steps?

E/copybit (  138): copyBits failed (Invalid argument)
E/copybit (  138): 0: src={w=320, h=352, f=13, rect={0,0,320,64}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={58,135,205,41}}
E/copybit (  138):     flags=00020000
E/copybit (  138): 1: src={w=320, h=352, f=13, rect={23,68,271,267}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={73,179,174,171}}
E/copybit (  138):     flags=00020000
E/copybit (  138): 2: src={w=320, h=352, f=13, rect={24,336,270,1}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={74,350,173,1}}
E/copybit (  138):     flags=00020000
E/copybit (  138): 3: src={w=320, h=352, f=13, rect={23,337,271,3}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={73,351,174,2}}
E/copybit (  138):     flags=00020000

E/msm7627a.hwcomposer(  138): drawLayerUsingCopybit: copybit stretch failed
E/copybit (  138): copyBits failed (Invalid argument)
E/copybit (  138): 0: src={w=320, h=384, f=13, rect={0,0,320,1}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={58,135,205,1}}
E/copybit (  138):     flags=00020000
E/copybit (  138): 1: src={w=320, h=384, f=13, rect={0,1,299,1}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={58,136,192,1}}
E/copybit (  138):     flags=00020000
E/copybit (  138): 2: src={w=320, h=384, f=13, rect={299,1,9,353}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={250,136,6,226}}
E/copybit (  138):     flags=00020000
E/copybit (  138): 3: src={w=320, h=384, f=13, rect={309,1,10,1}}
E/copybit (  138):     dst={w=320, h=480, f=14, rect={256,136,7,1}}
E/copybit (  138):     flags=00020000
Depends on: 900029
Flags: needinfo?(sync-1)
Keywords: qawanted
Amelie, can you confirm this on your side? Thanks
Flags: needinfo?(jcheng) → needinfo?(mei.kong)
QA Contact: dkumar
QA Contact: dkumar
QA Contact: sparsons
QA Contact: sparsons
(In reply to Ben Kelly [:bkelly] from comment #8)
> Thank you for the log.  This looks like another symptom related to bug
> 900029.
> 
> Was this produced with a vendor build?  QA, can you reproduce using these
> steps?
> 
> E/copybit (  138): copyBits failed (Invalid argument)
> E/copybit (  138): 0: src={w=320, h=352, f=13, rect={0,0,320,64}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={58,135,205,41}}
> E/copybit (  138):     flags=00020000
> E/copybit (  138): 1: src={w=320, h=352, f=13, rect={23,68,271,267}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={73,179,174,171}}
> E/copybit (  138):     flags=00020000
> E/copybit (  138): 2: src={w=320, h=352, f=13, rect={24,336,270,1}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={74,350,173,1}}
> E/copybit (  138):     flags=00020000
> E/copybit (  138): 3: src={w=320, h=352, f=13, rect={23,337,271,3}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={73,351,174,2}}
> E/copybit (  138):     flags=00020000
> 
> E/msm7627a.hwcomposer(  138): drawLayerUsingCopybit: copybit stretch failed
> E/copybit (  138): copyBits failed (Invalid argument)
> E/copybit (  138): 0: src={w=320, h=384, f=13, rect={0,0,320,1}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={58,135,205,1}}
> E/copybit (  138):     flags=00020000
> E/copybit (  138): 1: src={w=320, h=384, f=13, rect={0,1,299,1}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={58,136,192,1}}
> E/copybit (  138):     flags=00020000
> E/copybit (  138): 2: src={w=320, h=384, f=13, rect={299,1,9,353}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={250,136,6,226}}
> E/copybit (  138):     flags=00020000
> E/copybit (  138): 3: src={w=320, h=384, f=13, rect={309,1,10,1}}
> E/copybit (  138):     dst={w=320, h=480, f=14, rect={256,136,7,1}}
> E/copybit (  138):     flags=00020000

according to the steps in pr 900029 and it's commits, we can't reproduce the copybit error log
Flags: needinfo?(sync-1)
Flags: needinfo?(mei.kong)
Sorry, I was trying to ask if Mozilla QA could reproduce the errors using the steps from this bug (901395).

My question for the reporter was regarding if this was using a vendor build or directly from the Mozilla repo.  The other bug suggested that these copybit errors should not show up in a vendor build.
Was able to reproduce this bug on Buri flashed to the following build:
US_20130725_root
Build ID: 20130806071254
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a2a9b89ef5ee
Gaia: 4c1a20570e20f64782ba170c14604395c48f7381
Platform Version: 18.1
RIL Version: 01.01.00.019.180
Attached file logcat to comment 12
attaching logcat for more info
Keywords: qawanted
Please check if this is a GFX issue
blocking-b2g: leo? → leo+
Flags: needinfo?(roc)
No Buri device here. Milan, do you guys have one?
Flags: needinfo?(roc) → needinfo?(milan)
I think hamachi and buri are "equivalent", and we do have hamachi.  I see this as a leo+, so we will try it on an official 1.1 hamachi build.
I can reproduce this with 20130803 and 20130807 nightly hamachi 1.1 builds.
Flags: needinfo?(milan)
We can follow up on this tomorrow - Peter, can you get somebody in Taipei to look at it in the meantime?
Flags: needinfo?(pchang)
BenWa is looking at this.
Flags: needinfo?(pchang)
Assignee: nobody → bgirard
I understand there are (at least) two variants of the Buri hardware; 4012A and 4012B.  In case its relevant, I saw various copybit errors and screen flashing behavior on my 4012A.
I've been making some progress on this. I can reproduce this by hitting links in the Settings app which is less time consuming.

copybit errors are typically preceded by pmem errors:
E/memalloc(  974): /dev/pmem: No more pmem available
W/memalloc(  974): Falling back to ashmem
Just in case it helps, I can no longer reproduce the copybit errors on my buri after updating to the vendor firmware from mid-July.  If I build from our b2g repo and do a full ./flash.sh, however, they come back.  Using just ./flash.sh gecko allows me to work around the issue.  So it appears the vendor has some patch in their kernel or libraries which addresses this.
(In reply to Preeti Raghunath(:Preeti) from comment #14)
> Please check if this is a GFX issue

Based on the comment above, I'd say it wasn't a GFX issue, but we'll spend a bit more time on it, just in case the kernel update is masking a problem on our side.
Hmm... comment 25 says QA was able to reproduce with US_20130725_root which was the vendor image I used.  So possibly the issue is still there and I just missed triggering it.  I apologize if my comment 22 confused the issue.

I will say, however, copybit errors are at least much reduced in general operation with US_20130725_root compared to builds from our b2g repo.
Sorry, that should be comment 12 says QA was able to reproduce with US_20130725_root.
(In reply to Milan Sreckovic [:milan] from comment #23)
> (In reply to Preeti Raghunath(:Preeti) from comment #14)
> > Please check if this is a GFX issue
> 
> Based on the comment above, I'd say it wasn't a GFX issue, but we'll spend a
> bit more time on it, just in case the kernel update is masking a problem on
> our side.

Yes if you don't mind I'll like to continue to investigate this.

I found that the error '/dev/pmem: No more pmem available / Falling back to ashmem' occur during a gralloc allocation as expected. While it error might of disappear we should handle this failure correctly.

I've noticed that in 'GrallocBufferActor::Create' we don't notice that our GraphicsSurface is not in pmem and take the same code paths. Going to dig into this some more.
I patched out the fallback in libgralloc/alloc_controller.cpp. This makes the gralloc allocation fail in gecko causing gecko to hit its own fallback path which triggers proper rendering.

I'm not sure if what the best way to deal with this is yet.
on a 20130815 partner build, this is still reproduced but i wonder why this is only showing up in Buri?
is there any progress?
Benwa,

Did you get a chance to move forward with this bug?
Flags: needinfo?(bgirard)
I haven't progressed on this particular bug but we're progressing on this class of image lifetime bugs tracked by bug 902643.
Flags: needinfo?(bgirard)
If there is progress, please update status, thanks.
Is this bug still reproducable? and does it still happen if the hwcomposer disabled?
No longer blocks: GFXB2G1.2
(In reply to Jeff Muizelaar [:jrmuizel] from comment #33)
> it still happen if the hwcomposer
> disabled?

It does not reproduce with HWC disabled. The flashing is us switching between the HWC and OGL.
can we close this bug, then?
Dear BenWa:

Are you sure this pr is caused by the HWC?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
(In reply to buri.blff from comment #36)
> Dear BenWa:
> 
> Are you sure this pr is caused by the HWC?


Yes
Dear mozilla:
   v1.0.1 is ok on our device; but v1.1 is ko on the same device;

   So, this is an regression pr, we need to resolve this pr;
WFM is a better resolution since this report was for a valid problem that got fixed by a combination of other bugs elsewhere.

This is fixed for 1.2, I don't have an environment to test for 1.1. Do we need to uplift fixes for 1.1 for this?
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.