Closed
Bug 1119714
Opened 11 years ago
Closed 10 years ago
[FFOS7715 v2.1][dolphin][Flame]Sometimes 720P video cannot be played in video app after backing from dormant state
Categories
(Firefox OS Graveyard :: Gaia::Video, defect)
Tracking
(blocking-b2g:2.1+)
RESOLVED
DUPLICATE
of bug 1112410
blocking-b2g | 2.1+ |
People
(Reporter: lin.hui, Unassigned)
References
Details
(Whiteboard: [SPRD 392713])
Attachments
(2 files)
DEFECT DESCRIPTION:
When playing music, 720P video cannot playing in video app.
Steps to reproduce:
----------------------------------------------------
Step 1: Playing a 720P video in video app.
Step 2: click home button back to homescreen.
Step 3: open music app, and select one music to playing.
Step 4: click home button back to homescreen.
Step 5: Open video app which hide in back ground.
Step 6: Video app display a black screen, click playing button, video cannot be play.
Additional info:
--------------------------------------
Video demation:1280x720
Reproduce rate: 3/5
Reporter | ||
Comment 1•11 years ago
|
||
Issue log file.
Reporter | ||
Comment 2•11 years ago
|
||
In log file, I found the following logs:
> 01-09 03:42:11.533 V/OMXCodec( 3509): [OMX.google.aac.decoder] OMX_EventPortSettingsChanged(port=1,
> data2=0x00000000)
> 01-09 03:42:11.533 V/OMXCodec( 3509): [OMX.google.aac.decoder] PORT_SETTINGS_CHANGED(1)
> 01-09 03:42:11.533 V/OMXCodec( 3509): [OMX.google.aac.decoder] sending OMX_CommandPortDisable(1)
> 01-09 03:42:11.533 V/OMXCodec( 3509): [OMX.google.aac.decoder] FILL_BUFFER_DONE(buffer: 0xb07e86a0,
> size: 0, flags: 0x00000000, timestamp: 0 us (0.00 secs))
> 01-09 03:42:11.533 V/OMXCodec( 3509): [OMX.google.aac.decoder] Port is disabled, freeing buffer
> 0xb07e86a0
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] FILL_BUFFER_DONE(buffer: 0xb07e8790,
> size: 0, flags: 0x00000000, timestamp: 0 us (0.00 secs))
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Port is disabled, freeing buffer
> 0xb07e8790
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] FILL_BUFFER_DONE(buffer: 0xb07e87e0,
> size: 0, flags: 0x00000000, timestamp: 0 us (0.00 secs))
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Port is disabled, freeing buffer
> 0xb07e87e0
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] FILL_BUFFER_DONE(buffer: 0xb07e8880,
> size: 0, flags: 0x00000000, timestamp: 0 us (0.00 secs))
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Port is disabled, freeing buffer
> 0xb07e8880
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] PORT_DISABLED(1)
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] sending OMX_CommandPortEnable(1)
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] allocating 4 buffers of size 24576 on > output port
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] allocated buffer 0xb07e8790 on output > port
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] allocated buffer 0xb07e87e0 on output > port
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] allocated buffer 0xb07e8880 on output > port
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] allocated buffer 0xb07e8c40 on output > port
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] PORT_ENABLED(1)
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Calling fillBuffer on buffer 0xb07e8790
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Calling fillBuffer on buffer 0xb07e87e0
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Calling fillBuffer on buffer 0xb07e8880
> 01-09 03:42:11.543 V/OMXCodec( 3509): [OMX.google.aac.decoder] Calling fillBuffer on buffer 0xb07e8c40
Dear Vchen:
According to the above log, please help to check this issue.
Thanks a lot.
Flags: needinfo?(vchen)
Reporter | ||
Comment 3•11 years ago
|
||
In OMXCodec.h:
> enum {
> kPortIndexInput = 0,
> kPortIndexOutput = 1
> };
According to the issue log, buffers port of kPortIndexOutput seems disabled, I don't know what happend about this, so I want to your support!
Thanks!
Hi Lin Hui -
Two questions for you:
1. Can you reproduce this on Flame?(please try both single core and dual core)
2. Could you also upload the 720P video you used into some free space(e.g. Baidu..) such that we can download and try to reproduce this issue at our end?
Thanks
Flags: needinfo?(vliu)
Flags: needinfo?(vchen)
Flags: needinfo?(lin.hui)
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #4)
> 1. Can you reproduce this on Flame?(please try both single core and dual
> core)
I find another way to reproduce this issue both in flame & dolphin, this case, flame is dual core.
STR:
1.Let the Screen lock disabled.
2.Playing 720P video in video app.
3.Press power button to let the screen goes dark
4.Repress power button to light up the screen
5.click playing button to play video.
6.video cannot be playing.
The probability of flame is lower than dolphin.
> 2. Could you also upload the 720P video you used into some free space(e.g.
> Baidu..) such that we can download and try to reproduce this issue at our
> end?
video source are in blow site:
http://pan.baidu.com/s/1eQGiLFG
Thank you.
Flags: needinfo?(lin.hui)
Reporter | ||
Comment 6•10 years ago
|
||
Using new test step, flame are also cannot playing video.
ps:low probability on flame, high probability on dolphin.
Flags: needinfo?(vchen)
Comment 7•10 years ago
|
||
Hi Steven,
As talked, would you please have a look? Thanks
Flags: needinfo?(slee)
Comment 8•10 years ago
|
||
Hi Blake,
Can you verify what the problem is? Thanks.
Flags: needinfo?(slee) → needinfo?(bwu)
Reporter | ||
Comment 9•10 years ago
|
||
Hi All:
After video app re-back to the foreground, it's will started with a seek, if seek completed, firing a seek-completed event, then video can go on playing, but if during a long seek, the audio seek isn't completed.
video can play logs are as follows:
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0
>> vqFin=0 vqSz=1
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=0
>> aqFin=0 aqSz=0
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): CheckIfSeekComplete() audioSeekComplete=0
>> videoSeekComplete=1
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): OmxDecoder::Play
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0
>> vqFin=0 vqSz=1
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=0
>> aqFin=0 aqSz=0
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): CheckIfSeekComplete() audioSeekComplete=0
>> videoSeekComplete=1
>> 01-12 03:22:12.430 I/lin.hui ==>( 668): OmxDecoder::Play
>> 01-12 03:22:12.440 I/lin.hui ==>( 668): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0
>> vqFin=0 vqSz=1
>> 01-12 03:22:12.440 I/lin.hui ==>( 668): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=0
>> aqFin=0 aqSz=1
>> 01-12 03:22:12.440 I/lin.hui ==>( 668): CheckIfSeekComplete() audioSeekComplete=1
>> videoSeekComplete=1
>> 01-12 03:22:12.440 I/lin.hui ==>( 668): In SeekCompleted-->RenderVideoFrame
but if seek not completed, the log like this:
>> 01-12 03:22:21.450 I/lin.hui ==>( 668): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0
>> vqFin=0 vqSz=0
>> 01-12 03:22:21.450 I/lin.hui ==>( 668): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=1
>> aqFin=0 aqSz=0
>> 01-12 03:22:21.450 I/lin.hui ==>( 668): CheckIfSeekComplete() audioSeekComplete=0
>> videoSeekComplete=0
>> 01-12 03:22:21.450 I/lin.hui ==>( 668): OmxDecoder::Play
>> 01-12 03:22:21.460 I/lin.hui ==>( 668): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0
>> vqFin=0 vqSz=0
>> 01-12 03:22:21.460 I/lin.hui ==>( 668): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=1
>> aqFin=0 aqSz=0
>> 01-12 03:22:21.460 I/lin.hui ==>( 668): CheckIfSeekComplete() audioSeekComplete=0
>> videoSeekComplete=0
>> 01-12 03:22:21.460 I/lin.hui ==>( 668): OmxDecoder::Play
>> 01-12 03:22:21.480 I/lin.hui ==>( 668): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0
>> vqFin=0 vqSz=1
>> 01-12 03:22:21.480 I/lin.hui ==>( 668): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=1
>> aqFin=0 aqSz=0
>> 01-12 03:22:21.480 I/lin.hui ==>( 668): CheckIfSeekComplete() audioSeekComplete=0
>> videoSeekComplete=1
If "aqSz" or "vqSz" > 0, the think it's seek completed, according the log, audio seek is not completed, cause the video cannot be played?
BTW, in MediaDecoderStateMachine.cpp:
>> void MediaDecoderStateMachine::DecodeSeek()
>> {
>> // During the seek, don't have a lock on the decoder state,
>> // otherwise long seek operations can block the main thread.
Is the long seek operations block the main thread?
Comment 10•10 years ago
|
||
I can repro this problem on my V2.1 Flame and start to investigate this bug.
Assignee: nobody → bwu
Flags: needinfo?(bwu)
Updated•10 years ago
|
Flags: needinfo?(vliu)
Reporter | ||
Comment 11•10 years ago
|
||
Dear Black:
When video app re-back to foreground, they should call EnsureAudioDecodeTaskQueued, and succeed to dispatch the DecodeAudio task, but most of time they do not dispatch the decodeaudio task successfully, cause the audio data do not decoded, followed the audioSeekComplete = 0, then can not fire the SeekCompleted task.
succeed:
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): Changed state from DECODING_METADATA to DECODING!
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 4
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 5
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): DecodeSeek: seekTime:110326000
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): mCurrentTimeBeforeSeek = 0
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): needToDecodeAudio = 0
>> 01-12 23:43:27.363 I/lin.hui ==>( 1826): MediaDecoder::SeekingStarted
>> 01-12 23:43:27.373 I/lin.hui ==>( 1826): OmxDecoder::Play
>> 01-12 23:43:27.373 I/lin.hui ==>( 1826): OmxDecoder::Play
>> 01-12 23:43:27.433 I/lin.hui ==>( 1826): needToDecodeAudio = 1
>> 01-12 23:43:27.433 I/lin.hui ==>( 1826): MediaDecoderStateMachine::EnsureAudioDecodeTaskQueued
>> 01-12 23:43:27.433 I/lin.hui ==>( 1826): dispatch DecodeAudio task starting
>> 01-12 23:43:27.433 I/lin.hui ==>( 1826): dispatch DecodeAudio task succeed
>> 01-12 23:43:27.433 I/lin.hui ==>( 1826): In DecodeAudio: mReader->RequestAudioData() mState:5
failed:
>> 01-12 23:32:23.273 I/lin.hui ==>( 1826): Changed state from DECODING_METADATA to DECODING!
>> 01-12 23:32:23.273 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 4
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 5
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): DecodeSeek: seekTime:90344000
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): mCurrentTimeBeforeSeek = 0
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): needToDecodeAudio = 0
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): MediaDecoder::SeekingStarted
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): OmxDecoder::Play
>> 01-12 23:32:23.283 I/lin.hui ==>( 1826): OmxDecoder::Play
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): needToDecodeAudio = 1
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): MediaDecoderStateMachine::EnsureAudioDecodeTaskQueued
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0 vqFin=0 vqSz=0
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=1 aqFin=0 aqSz=0
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): MediaDecoderStateMachine::EnsureAudioDecodeTaskQueued
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): CheckIfSeekComplete() audioSeekComplete=0 videoSeekComplete=0
>> 01-12 23:32:23.343 I/lin.hui ==>( 1826): OmxDecoder::Play
I guess there may have something block the audio decoded.
Comment 12•10 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #10)
> I can repro this problem on my V2.1 Flame and start to investigate this bug.
Hi Blake Wu:
This bug can reproduce easily in the steps of comment 5 on sprd7715ea and flame. We think it's a critical problem.
Please help to speed up the processing, thanks very much!
Severity: major → critical
Flags: needinfo?(vchen)
Comment 13•10 years ago
|
||
(In reply to lin.hui@spreadtrum.com from comment #11)
> Dear Black:
> When video app re-back to foreground, they should call
> EnsureAudioDecodeTaskQueued, and succeed to dispatch the DecodeAudio task,
> but most of time they do not dispatch the decodeaudio task successfully,
> cause the audio data do not decoded, followed the audioSeekComplete = 0,
> then can not fire the SeekCompleted task.
>
> succeed:
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): Changed state from DECODING_METADATA to DECODING!
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 4
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 5
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): DecodeSeek: seekTime:110326000
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): mCurrentTimeBeforeSeek = 0
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): needToDecodeAudio = 0
> >> 01-12 23:43:27.363 I/lin.hui ==>( 1826): MediaDecoder::SeekingStarted
> >> 01-12 23:43:27.373 I/lin.hui ==>( 1826): OmxDecoder::Play
> >> 01-12 23:43:27.373 I/lin.hui ==>( 1826): OmxDecoder::Play
> >> 01-12 23:43:27.433 I/lin.hui ==>( 1826): needToDecodeAudio = 1
> >> 01-12 23:43:27.433 I/lin.hui ==>( 1826): MediaDecoderStateMachine::EnsureAudioDecodeTaskQueued
> >> 01-12 23:43:27.433 I/lin.hui ==>( 1826): dispatch DecodeAudio task starting
> >> 01-12 23:43:27.433 I/lin.hui ==>( 1826): dispatch DecodeAudio task succeed
> >> 01-12 23:43:27.433 I/lin.hui ==>( 1826): In DecodeAudio: mReader->RequestAudioData() mState:5
>
>
> failed:
> >> 01-12 23:32:23.273 I/lin.hui ==>( 1826): Changed state from DECODING_METADATA to DECODING!
> >> 01-12 23:32:23.273 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 4
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): RunStateMachine starting, mState = 5
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): DecodeSeek: seekTime:90344000
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): mCurrentTimeBeforeSeek = 0
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): needToDecodeAudio = 0
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): MediaDecoder::SeekingStarted
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): OmxDecoder::Play
> >> 01-12 23:32:23.283 I/lin.hui ==>( 1826): OmxDecoder::Play
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): needToDecodeAudio = 1
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): MediaDecoderStateMachine::EnsureAudioDecodeTaskQueued
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): IsVideoSeekComplete():video--> curTarVal=1 mVidDis=0 vqFin=0 vqSz=0
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): IsAudioSeekComplete():audio--> curTarVal=1 mAudDis=1 aqFin=0 aqSz=0
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): MediaDecoderStateMachine::EnsureAudioDecodeTaskQueued
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): CheckIfSeekComplete() audioSeekComplete=0 videoSeekComplete=0
> >> 01-12 23:32:23.343 I/lin.hui ==>( 1826): OmxDecoder::Play
>
> I guess there may have something block the audio decoded.
Thanks for your help to narrow down this problem. I am checking it.
Comment 14•10 years ago
|
||
(In reply to jinchao.wang from comment #12)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #10)
> > I can repro this problem on my V2.1 Flame and start to investigate this bug.
>
> Hi Blake Wu:
> This bug can reproduce easily in the steps of comment 5 on sprd7715ea
> and flame. We think it's a critical problem.
> Please help to speed up the processing, thanks very much!
Sure! I am checking this problem now.
Comment 15•10 years ago
|
||
After some investigations, it looks like mVideoRequestPending and mAudioRequestPending are not reset after dormant state or backing to DecodeMetaData, so AudioDecodeTask and VideoDecodeTask will not be dispatched @[1][2].
I continue to check when to reset them in time.
[1]http://mxr.mozilla.org/mozilla-b2g34_v2_1/source/content/media/MediaDecoderStateMachine.cpp#1728
[2]http://mxr.mozilla.org/mozilla-b2g34_v2_1/source/content/media/MediaDecoderStateMachine.cpp#1773
Updated•10 years ago
|
Summary: [FFOS7715 v2.1][dolphin][video] When playing music, sometimes 720P video cannot playing in video app → [FFOS7715 v2.1][dolphin][Flame]Sometimes 720P video cannot be played in video app after backing from dormant state
Reporter | ||
Comment 16•10 years ago
|
||
Dear Blake:
This issue happened not just 720p video, in my own tests, all the video files can occurred yet.
Comment 17•10 years ago
|
||
(In reply to lin.hui@spreadtrum.com from comment #16)
> Dear Blake:
> This issue happened not just 720p video, in my own tests, all the video
> files can occurred yet.
Yes. You are right. For high resolution videos, it should be more easily reproduced.
Comment 18•10 years ago
|
||
attachment 8547628 [details] [diff] [review] in Bug 1112410 seems to fix this. It got review+, but is not yet checked-in to b2g v2.1.
Can someone confirm it?
Comment 19•10 years ago
|
||
[Blocking Requested - why for this release]: Based on Comment 12 and Comment 10.
blocking-b2g: --- → 2.1?
Updated•10 years ago
|
blocking-b2g: 2.1? → 2.1+
Comment 20•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
> attachment 8547628 [details] [diff] [review] in Bug 1112410 seems to fix
> this. It got review+, but is not yet checked-in to b2g v2.1.
> Can someone confirm it?
I think this patch should fix this bug as well.
Lin,
Could you have a try?
Flags: needinfo?(lin.hui)
Reporter | ||
Comment 21•10 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #20)
> (In reply to Sotaro Ikeda [:sotaro] from comment #18)
> > attachment 8547628 [details] [diff] [review] in Bug 1112410 seems to fix
> > this. It got review+, but is not yet checked-in to b2g v2.1.
> > Can someone confirm it?
> I think this patch should fix this bug as well.
> Lin,
> Could you have a try?
Dear Blake:
After applying that patch in v2.1, it's seems look good for me.
I will try do more test, and ensure that patch can fix this issue.
Thanks you very much!
Flags: needinfo?(lin.hui)
Reporter | ||
Comment 22•10 years ago
|
||
Dear Blake:
After some test,that patch can fix this issue suitable.
we think that patch should landed in v2.1 on mozillaorg.
Thanks!
Reporter | ||
Comment 24•10 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #23)
> Great!
> Thanks for Sotaro's patch :)
Does this patch already landed in 2.1? we think this fix should check-in 2.1.
Hi Sotaro, seems like the patch of Bug#1112410 does solve the problem, could you help to land it on 2.1? Then after that we will help to land on 2.1S as well
Thanks
Flags: needinfo?(sotaro.ikeda.g)
Comment 26•10 years ago
|
||
Un-assign myself since the solution to this bug is already in another bug (bug 1112410).
Assignee: bwu → nobody
Comment 27•10 years ago
|
||
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #25)
> Hi Sotaro, seems like the patch of Bug#1112410 does solve the problem, could
> you help to land it on 2.1? Then after that we will help to land on 2.1S as
> well
>
> Thanks
I just asked for approval-mozilla-b2g34 and approval-mozilla-b2g37 in bug 1112410.
Flags: needinfo?(sotaro.ikeda.g)
Reporter | ||
Comment 28•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #27)
> I just asked for approval-mozilla-b2g34 and approval-mozilla-b2g37 in bug
> 1112410.
The fix patch have already landed on v2.1, Thank you very much.
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•