Closed
Bug 1148718
Opened 9 years ago
Closed 9 years ago
[Nexus5][Video]The video preview is grey in comfirm page while selecting a video as attachment in message.
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: huayu.li, Assigned: jerry)
Details
(Whiteboard: [2.2-nexus-5-l])
Attachments
(3 files, 1 obsolete file)
287.86 KB,
text/plain
|
Details | |
5.46 MB,
video/3gpp
|
Details | |
1.35 KB,
patch
|
sotaro
:
review+
nical
:
review+
bajaj
:
approval-mozilla-b2g37+
|
Details | Diff | Splinter Review |
[1.Description]: [Nexus 5 v2.2&3.0][Video]Add a video as attachments in message, in the comfirm page, the first view of video cannot be displayed, the view is grey, sometimes, waiting some time or lock/unlock screen, the first view displayed, but if we lock and unlock screen agian, the view disappeared agian. Found at:15:47 see attachments:logcat1.txt, video 1.3gp [2.Testing Steps]: Precondition:You have taken a video from camera less than 295kb. 1.Launch message. 2.Tap New button. 3.Tap attachment button. 4.Tap video. 5.Select the video you taken from camera. [3.Expected Result]: 5.The fist view of view should be displayed in comfirm page. [4.Actual Result]: 5.In the video preview page, the video is grey, if we lock and unlock screen, the preview can be displayed in time. [5.Reproduction build]: Device: Flame 2.2[Unaffected] Build ID 20150327162502 Gaia Revision 473cd63f53c855299b719285d9b95e3f2910782f Gaia Date 2015-03-27 20:14:43 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b358619def45 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150327.194944 Firmware Date Fri Mar 27 19:49:53 EDT 2015 Bootloader L1TC000118D0 Device:Nexus5 3.0[Affected] Build ID 20150327160203 Gaia Revision 9cc496cecc37d7a29f9279827cdf6e4891211f67 Gaia Date 2015-03-27 13:55:18 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/44e454b5e93b Gecko Version 39.0a1 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150327.192727 Firmware Date Fri Mar 27 19:27:40 EDT 2015 Bootloader HHZ12d Devicce:Nexus5 2.2[Affected] Build ID 20150327162502 Gaia Revision 473cd63f53c855299b719285d9b95e3f2910782f Gaia Date 2015-03-27 20:14:43 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b358619def45 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150327.195950 Firmware Date Fri Mar 27 20:00:03 EDT 2015 Bootloader HHZ12d [6.Reproduction Frequency]: Always Recurrence,5/5 [7.TCID]: Free Test [8.Note]: This issue doesn't exist on flame 2.2
Reporter | ||
Comment 1•9 years ago
|
||
Reporter | ||
Comment 2•9 years ago
|
||
[3.Expected Result]: 5.The fist view of video should be displayed in comfirm page.
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → affected
Updated•9 years ago
|
Flags: needinfo?(hcheng)
Comment 3•9 years ago
|
||
I prefer not a blocker. Jerry, do you know who can take a look? It might not be a gaia problem but a gecko one. I am not sure.
Flags: needinfo?(hcheng) → needinfo?(hshih)
Assignee | ||
Comment 4•9 years ago
|
||
I think it's gecko issue. When I press the homescreen button to get the card-view snapshot, I can see the video content.
Assignee: nobody → hshih
Status: NEW → ASSIGNED
Component: Gaia::Video → Graphics
Flags: needinfo?(hshih)
Product: Firefox OS → Core
Assignee | ||
Comment 5•9 years ago
|
||
I try to dump the image content at ImageContainer::SetCurrentImage()[1] and the image data is correct. So we might have problem on b2g side. Investigating. [1] https://dxr.mozilla.org/mozilla-central/source/gfx/layers/ImageContainer.cpp?from=SetCurrentImage&case=true#202
Assignee | ||
Comment 6•9 years ago
|
||
In this use case(see comment 0), we call UseTextureHost() before Attach(). Thus, we got failed in both PrepareTextureSource() and ImageLayerComposite::RenderLayer(). This patch just do PrepareTextureSource() again for the existed TextureHost. Sotaro and Nical, what do you think about this patch? Should we handle other type of XXXComposite? I only can image that async video causes this problem.
Attachment #8587377 -
Flags: review?(sotaro.ikeda.g)
Attachment #8587377 -
Flags: review?(nical.bugzilla)
Assignee | ||
Comment 8•9 years ago
|
||
try link for this patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b602a02d04a0
Comment 9•9 years ago
|
||
Comment on attachment 8587377 [details] [diff] [review] init TextureSource for current TextureHost when attach. v1 Review of attachment 8587377 [details] [diff] [review]: ----------------------------------------------------------------- The logic looks good to me, but I would prefer not to add a new virtual method just for this, see my comment below. Good catch, though. ::: gfx/layers/composite/CompositableHost.h @@ +156,5 @@ > SetLayer(aLayer); > mAttached = true; > mKeepAttached = aFlags & KEEP_ATTACHED; > + > + UseCurrentTextureHost(); Please replace this by: if (mFrontBuffer) { UseTextureHost(mFrontBuffer) } I'd rather not add a new method.
Attachment #8587377 -
Flags: review?(nical.bugzilla) → review-
Comment 10•9 years ago
|
||
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #6) > Sotaro and Nical, what do you think about this patch? Should we handle other > type of XXXComposite? I only can image that async video causes this problem. I think that we don't need to handle this for the other Compositable classes. ImageHost gets the most complex scenarios when it comes to attaching/detaching to layers, due to async-video. Since canvas workers will go through ImageHost as well, and painted layers never use the ImageBridge we should be good with only ImageHost handling this case.
Assignee | ||
Comment 11•9 years ago
|
||
Call use UseTextureHost() if we already have textureHost.
Attachment #8587490 -
Flags: review?(sotaro.ikeda.g)
Attachment #8587490 -
Flags: review?(nical.bugzilla)
Assignee | ||
Updated•9 years ago
|
Attachment #8587377 -
Attachment is obsolete: true
Attachment #8587377 -
Flags: review?(sotaro.ikeda.g)
Updated•9 years ago
|
Attachment #8587490 -
Flags: review?(nical.bugzilla) → review+
Updated•9 years ago
|
Attachment #8587490 -
Flags: review?(sotaro.ikeda.g) → review+
Assignee | ||
Comment 12•9 years ago
|
||
Please land attachment 8587490 [details] [diff] [review] to m-c. try link: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8848864d01fb this patch is similar to the previous one: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b602a02d04a0
Keywords: checkin-needed
Assignee | ||
Comment 13•9 years ago
|
||
I saw some tests failed. Checking for the new patch....
Keywords: checkin-needed
Assignee | ||
Comment 14•9 years ago
|
||
Please land attachment 8587490 [details] [diff] [review] to m-c. Try result seems good. try link: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8848864d01fb
Keywords: checkin-needed
Comment 15•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/e4471cda8083
Keywords: checkin-needed
Assignee | ||
Comment 16•9 years ago
|
||
Comment on attachment 8587490 [details] [diff] [review] init TextureSource for current TextureHost when attach. v2 [Approval Request Comment] Bug caused by (feature/regressing bug #): none User impact if declined: We have timing issue at nexus5-l. The first frame of image will not show in comment 0 use case. Testing completed: Pass try on m-c. Test on 2.2 manually. I can see the first frame on both version. Risk to taking this patch (and alternatives if risky): Low. This patch just calls the texture source init function when it's attached to layer. String or UUID changes made by this patch: none
Attachment #8587490 -
Flags: approval-mozilla-b2g37?
Comment 17•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e4471cda8083
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Updated•9 years ago
|
blocking-b2g: 2.2? → 2.2+
Updated•9 years ago
|
Attachment #8587490 -
Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Comment 18•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/9931ab333e5a
status-firefox38:
--- → wontfix
status-firefox39:
--- → wontfix
Updated•9 years ago
|
Flags: needinfo?(hcheng)
Reporter | ||
Comment 19•9 years ago
|
||
This issue had been successfully verified on nexus5 2.2&3.0, there is no device of status-firefox40. Reproducing rate: 0/5 Device: Nexus 5 2.2[Verified] Build ID 20150407162504 Gaia Revision ea735c21bfb0d78333213ff0376fce1eac89ead6 Gaia Date 2015-04-07 20:58:15 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/3f86ddb7f719 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150407.195148 Firmware Date Tue Apr 7 19:52:02 EDT 2015 Bootloader HHZ12d Device: Nexus5 3.0[Verified] Build ID 20150407160201 Gaia Revision 84cbd4391fb7175d5380fa72c04d68873ce77e6d Gaia Date 2015-04-07 17:33:14 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/078128c2600a Gecko Version 40.0a1 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150407.192944 Firmware Date Tue Apr 7 19:30:00 EDT 2015 Bootloader HHZ12d
Reporter | ||
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•