Closed Bug 1006957 Opened 11 years ago Closed 11 years ago

Handle buffer ownership correctly between SurfaceStream and CanvasClient.

Categories

(Core :: Graphics: Layers, defect, P1)

Product:
Core
Component:
Graphics: Layers
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32
Project Flags:
blocking-b2g 1.4+
Tracking Flags:
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: sotaro, Assigned: sotaro)

References

Details

Attachments

(3 files, 18 obsolete files)

patch v12 - Handle buffer ownership between SurfaceStream and CanvasClient
80.43 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
WebRTC crash fix
920 bytes, patch
sotaro
: review+
Details | Diff | Splinter Review
patch v14 for b2g v1.4 - Handle buffer ownership between SurfaceStream and CanvasClient
81.06 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
+++ This bug was initially created as a clone of Bug #950079 +++ This bug is created based on Bug 950079 Comment 17. Buffer ownership handling between SurfaceStream and CanvasClient has a problem. It could cause the problem to Fence delivery from Compositor to SurfaceStream.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → ---
Assignee: nobody → sotaro.ikeda.g
blocking-b2g: --- → 1.4?
CanvasClientSurfaceStream does not explicitly handle buffer return to SurfaceStream. Post new buffer to Compositor side by the following call implicitly expect synchronous buffer return to the SurfaceStream. But the following call requests async transaction. > GetForwarder()->UseTexture(this, mBuffer);
Bug 988956 might be necessary to fix the problem.
I am going to use AsyncTransactionTracker::WaitComplete() to wait transaction complete. http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncTransactionTracker.h
Depends on: 984434
Status: NEW → ASSIGNED
Can we please get: 1) STRs 2) DUT 3) User impact of not taking fix 4) Regression or not from previous releases
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Preeti Raghunath(:Preeti) from comment #5) > Can we please get: > > 1) STRs Same to Bug 1006164. > 2) DUT What is DUT? > 3) User impact of not taking fix. Rarely saw black flicker during WebGL like WMW app. > 4) Regression or not from previous releases This is a regression caused by new b2g hardware specfic characteristic.
Flags: needinfo?(sotaro.ikeda.g)
Blocking for 1.4. Can we please discuss low risk fix here and low risk landing?
blocking-b2g: 1.4? → 1.4+
(In reply to Preeti Raghunath(:Preeti) from comment #7) > Blocking for 1.4. > > Can we please discuss low risk fix here and low risk landing? Bug 950079 is low risk solution for WMW. About this bug, I am thinking only one way of the fix. I think there are no other choice for low risk fix.
Confirmed the patch black flickering is fixed.
Attachment #8424186 - Flags: feedback?(nical.bugzilla)
Comment on attachment 8424186 [details] [diff] [review] patch - Handle buffer ownership between SurfaceStream and CanvasClient. Review of attachment 8424186 [details] [diff] [review]: ----------------------------------------------------------------- I am struggling a bit with the logic around process ID, I suppose there is always one parent process so we don't really need to track its ID, so I suppose we are looking at the the child process ID here. But we create the LayerTransactionParent querying the current process ID, which makes it look like we are tracking the parent ID, so I am a bit confused. I think it would help a lot if you renamed all the [m|a]ProcessId and aOtherProcessID variables into [m|a][Child|Parent]ProcessId to make it clear which side's ID we are tracking. I'll catch up with you on irc or skype today to get a better understanding of the overall thing. ::: gfx/layers/client/TextureClient.h @@ +297,5 @@ > return mReleaseFenceHandle; > } > > /** > + * Set AsyncTransactionTracker of RemoveTextureFromCompositableAsync() transaction. nit: trailing space ::: gfx/layers/ipc/CompositableTransactionParent.cpp @@ +187,5 @@ > + GetProcessId(), > + OpReplyRemoveTexture(true, // isMain > + op.holderId(), > + op.transactionId())); > + nit: trailing spaces
(In reply to Nicolas Silva [:nical] from comment #11) > Comment on attachment 8424186 [details] [diff] [review] > patch - Handle buffer ownership between SurfaceStream and CanvasClient. > > Review of attachment 8424186 [details] [diff] [review]: > ----------------------------------------------------------------- > > I am struggling a bit with the logic around process ID, I suppose there is > always one parent process so we don't really need to track its ID, so I > suppose we are looking at the the child process ID here. But we create the > LayerTransactionParent querying the current process ID, which makes it look > like we are tracking the parent ID, so I am a bit confused. I think it would > help a lot if you renamed all the [m|a]ProcessId and aOtherProcessID > variables into [m|a][Child|Parent]ProcessId to make it clear which side's ID > we are tracking. It is tracking LayerTransactionchild's process id. I am going to update the code to make it clear. > > I'll catch up with you on irc or skype today to get a better understanding > of the overall thing. > > ::: gfx/layers/client/TextureClient.h > @@ +297,5 @@ > > return mReleaseFenceHandle; > > } > > > > /** > > + * Set AsyncTransactionTracker of RemoveTextureFromCompositableAsync() transaction. > > nit: trailing space > > ::: gfx/layers/ipc/CompositableTransactionParent.cpp > @@ +187,5 @@ > > + GetProcessId(), > > + OpReplyRemoveTexture(true, // isMain > > + op.holderId(), > > + op.transactionId())); > > + > > nit: trailing spaces Will update in a next patch.
(In reply to Nicolas Silva [:nical] from comment #11) > Comment on attachment 8424186 [details] [diff] [review] > patch - Handle buffer ownership between SurfaceStream and CanvasClient. > > Review of attachment 8424186 [details] [diff] [review]: > ----------------------------------------------------------------- > > I am struggling a bit with the logic around process ID, I suppose there is > always one parent process so we don't really need to track its ID, so I > suppose we are looking at the the child process ID here. But we create the > LayerTransactionParent querying the current process ID, which makes it look > like we are tracking the parent ID, so I am a bit confused. I think it would > help a lot if you renamed all the [m|a]ProcessId and aOtherProcessID > variables into [m|a][Child|Parent]ProcessId to make it clear which side's ID > we are tracking. The patch tracks child side's process id. When LayerTransactionParent(CompositableParentManager) receives an async transaction message, it sends back an async transaciton response message via ImageBridge parent. The messge is handled to ImageBridgeChild. ImageBridgeChild notify the transaction complete to AsyncTransactionTrackersHolder. By this way, AsyncTransactionTracker provide a sync wait capability by using async transaction. By changing the sync wait place from gecko ipc transaction to AsyncTransactionTracker, we could put off sync wait.
Apply the comments.
Attachment #8424186 - Attachment is obsolete: true
Attachment #8424186 - Flags: feedback?(nical.bugzilla)
Attachment #8425469 - Flags: feedback?(nical.bugzilla)
nical, can I get the feedback to the patch soon?
Flags: needinfo?(nical.bugzilla)
Comment on attachment 8425469 [details] [diff] [review] patch v2 - Handle buffer ownership between SurfaceStream and CanvasClient Review of attachment 8425469 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for renaming the ProcessIds, I think it makes things clearer
Attachment #8425469 - Flags: feedback?(nical.bugzilla) → feedback+
Thank for the quick feed back! I am going to update the patch for a review until tomorrow.
Flags: needinfo?(nical.bugzilla)
Some nits update.
Attachment #8425469 - Attachment is obsolete: true
This bug fix seems to have a good effect to the performance.
Fix build failure in some platforms.
Attachment #8426727 - Attachment is obsolete: true
Fix build failure.
Attachment #8426760 - Attachment is obsolete: true
Attachment #8426766 - Flags: review?(nical.bugzilla)
Fix windows build failure.
Attachment #8426766 - Attachment is obsolete: true
Attachment #8426766 - Flags: review?(nical.bugzilla)
Attachment #8426779 - Flags: review?(nical.bugzilla)
Fix build failure on ICS.
Attachment #8426779 - Attachment is obsolete: true
Attachment #8426779 - Flags: review?(nical.bugzilla)
Attachment #8426897 - Flags: review?(nical.bugzilla)
Attachment #8426897 - Flags: review?(nical.bugzilla) → review+
Revert ConnectImageBridgeInParentProcess()'s argument name. Carry "r=nical".
Attachment #8426897 - Attachment is obsolete: true
Attachment #8427024 - Flags: review+
A patch for b2g v1.4. Carry "r=nical".
Attachment #8427041 - Flags: review+
On master, the problem is fixed. But on v1.4, the problem is exist on hw composer composition:-( On OpenGL composition case, the problem is fixed even in b2g v1.4. On current master, hw composer is not used in almost all situations by some reasons. On b2g v1.4, Hw composer is used in WMW app. If we disable the hw composer, the problem is gone with the patch.
Release Fences are always sent on main thread, but RemoveTextureAsync transaction response is sent via ImageBridge. Therefore, release fence is arrived to child side after the transaction response's receival in child side.
Need to send related Fence object via ImageBridge too.
I locally fixed the black flash problem in Comment 31. But it change how to deliver Fence from compositor to child side. More code change becomes necessary. I am updating the patch.
Patch for b2g v1.4. Fix flickering problem on HWComposer composition.
Attachment #8427041 - Attachment is obsolete: true
Sorry, this patch is correct patch for b2g v1.4.
Attachment #8427311 - Attachment is obsolete: true
Un-bitrot.
Attachment #8427469 - Attachment is obsolete: true
Attachment #8427321 - Attachment description: patch v9 for b2g v1.4 - Handle buffer ownership between SurfaceStream and CanvasClient → patch v10 for b2g v1.4 - Handle buffer ownership between SurfaceStream and CanvasClient
Comment on attachment 8427506 [details] [diff] [review] patch v10 - Handle buffer ownership between SurfaceStream and CanvasClient Nical, can you review again? I changed how to deliver fence.
Attachment #8427506 - Flags: review?(nical.bugzilla)
Fix build failure on other platforms.
Attachment #8427506 - Attachment is obsolete: true
Attachment #8427506 - Flags: review?(nical.bugzilla)
Attachment #8427668 - Flags: review?(nical.bugzilla)
Attachment #8427668 - Flags: review?(nical.bugzilla) → review+
Update the patch for b2g v1.4. Carry "r=nical".
Attachment #8427321 - Attachment is obsolete: true
Attachment #8427739 - Flags: review+
Wait check-in until Bug 924622's check-in result becomes clear. This bug's patch conflicts with Bug 924622's patch.
Blocks: 767484
By the Bug 924622 fix, shutdown sequence is changed, it seems to be affected to the crash.
Need to move layers::AsyncTransactionTrackersHolder::Finalize() call to more later than nsCycleCollector_shutdown() in mozilla::ShutdownXPCOM().
Change shutdown. Carry "r=nical".
Attachment #8427668 - Attachment is obsolete: true
Attachment #8428256 - Flags: review+
Update the patch for b2g v1.4.
Attachment #8427739 - Attachment is obsolete: true
Attachment #8428271 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/436860482387
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
This is causing a B2G OS crash when I try to make a webrtc call using H.264 OMX. It works on the checkin before this landed (my patches for OMX H.264 cleanup landed a few hours after this, and had been tested before this landed). I reverified using the pre-checkin patches and this rev and the previous rev; previous rev works, this one crashes the phone. You need this: pref("media.peerconnection.video.h264_enabled", true); or equivalent user pref to enable it. We'll need to back this out or land a fix very soon.
Thanks for the notification. I am going to check it soon.
Attachment #8428271 - Attachment is obsolete: true
I locally confirmed the fix. I am going to upload the patch soon.
Attached patch WebRTC crash fix — — Splinter Review
WebRTC crash fix. Carry "r=nical".
Attachment #8428805 - Flags: review+
set REOPENED depend on Comment 56.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8428805 - Attachment description: patch_1006957_fix → WebRTC crash fix
:jesup, can you confirm the fix by attachment 8428805 [details] [diff] [review]?
Flags: needinfo?(rjesup)
Confirmed: inbound now works. Thanks!
Flags: needinfo?(rjesup)
Thanks for the confirmation!
https://hg.mozilla.org/mozilla-central/rev/fdf86352fdb6
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Hmm, b2g v1.4 does not have Bug 924622 fix. It might affect to the crash.
FWIW, I'm trying to talk nical into writing backport patches for 30 and 31 :)
The crash happens because there is a cases that ImageBridgeParent is not destroyed until nsCycleCollector_shutdown(). I am going to add a workaround to prevent the crash for b2g-v1.4.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #70) > FWIW, I'm trying to talk nical into writing backport patches for 30 and 31 :) Thanks!
(In reply to Sotaro Ikeda [:sotaro] from comment #71) > The crash happens because there is a cases that ImageBridgeParent is not > destroyed until nsCycleCollector_shutdown(). I am going to add a workaround > to prevent the crash for b2g-v1.4. I am just going to add a pointer check to AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers().
Add pointer check to AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers().
Attachment #8428859 - Attachment is obsolete: true
The following is the crash log that got from Comment 68. On gecko 30, ImageBridgeParent is destroyed by using Task. ImageBridge is not deleted within ShutdownXPCOM(). By Bug 924622, ImageBridgeParent becomes to be deleted within ShutdownXPCOM(). 08:14:42 INFO - Crash dump filename: /var/folders/Qp/Qp6yrDnSFsmnaUw0Wilc2k+++-k/-Tmp-/tmpa_1xFr.mozrunner/minidumps/F152F458-763B-47A7-A999-3340310D2F72.dmp 08:14:42 INFO - Operating system: Mac OS X 08:14:42 INFO - 10.6.8 10K549 08:14:42 INFO - CPU: amd64 08:14:42 INFO - family 6 model 23 stepping 10 08:14:42 INFO - 2 CPUs 08:14:42 INFO - Crash reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS 08:14:42 INFO - Crash address: 0x8 08:14:42 INFO - Thread 10 (crashed) 08:14:42 INFO - 0 XUL!mozilla::BlockingResourceBase::CheckAcquire(mozilla::CallStack const&) [BlockingResourceBase.cpp:6e420584d8bf : 94 + 0x0] 08:14:42 INFO - rbx = 0x0000000000000000 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x000000011e080a60 08:14:42 INFO - r15 = 0x000000011c0c6088 rip = 0x00000001019123f3 08:14:42 INFO - rsp = 0x000000011e0809c0 rbp = 0x000000011e080a50 08:14:42 INFO - Found by: given as instruction pointer in context 08:14:42 INFO - 1 XUL!mozilla::OffTheBooksMutex::Lock() [BlockingResourceBase.cpp:6e420584d8bf : 224 + 0x7] 08:14:42 INFO - rbx = 0x0000000000000000 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x0000000000000000 08:14:42 INFO - r15 = 0x000000011c0c6088 rip = 0x00000001019129ae 08:14:42 INFO - rsp = 0x000000011e080a60 rbp = 0x000000011e080a70 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 2 XUL!mozilla::layers::AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers() [Mutex.h:6e420584d8bf : 173 + 0x7] 08:14:42 INFO - rbx = 0x000000011c0c6088 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x0000000000000000 08:14:42 INFO - r15 = 0x000000011c0c6088 rip = 0x00000001022d6e27 08:14:42 INFO - rsp = 0x000000011e080a80 rbp = 0x000000011e080aa0 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 3 XUL!mozilla::layers::AsyncTransactionTrackersHolder::~AsyncTransactionTrackersHolder() [AsyncTransactionTracker.cpp:6e420584d8bf : 185 + 0x7] 08:14:42 INFO - rbx = 0x000000011c0c6088 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x000000011c0c6050 08:14:42 INFO - r15 = 0x000000011c0c5d60 rip = 0x00000001022d6926 08:14:42 INFO - rsp = 0x000000011e080ab0 rbp = 0x000000011e080ac0 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 4 XUL!mozilla::layers::ImageBridgeParent::~ImageBridgeParent() [CompositableTransactionParent.h:6e420584d8bf : 29 + 0xb] 08:14:42 INFO - rbx = 0x000000011c0c5d60 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x000000011c0c6050 08:14:42 INFO - r15 = 0x000000011c0c5d60 rip = 0x00000001022e84a4 08:14:42 INFO - rsp = 0x000000011e080ad0 rbp = 0x000000011e080b10 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 5 XUL!_ZThn752_N7mozilla6layers17ImageBridgeParentD0Ev [ImageBridgeParent.cpp:6e420584d8bf : 63 + 0x7] 08:14:42 INFO - rbx = 0x000000011c0c5d60 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x00007fff5fbfe497 08:14:42 INFO - r15 = 0x00007fff5fbfe498 rip = 0x00000001022e8368 08:14:42 INFO - rsp = 0x000000011e080b20 rbp = 0x000000011e080b30 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 6 XUL!mozilla::layers::DeleteImageBridgeSync [StaticPtr.h:6e420584d8bf : 158 + 0xb] 08:14:42 INFO - rbx = 0x0000000000009403 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x00007fff5fbfe497 08:14:42 INFO - r15 = 0x00007fff5fbfe498 rip = 0x00000001022e5410 08:14:42 INFO - rsp = 0x000000011e080b40 rbp = 0x000000011e080b60 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 7 XUL!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) [message_loop.cc:6e420584d8bf : 344 + 0x8] 08:14:42 INFO - rbx = 0x000000011e080cf8 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x0000000158a00c10 08:14:42 INFO - r15 = 0x000000011e080bb0 rip = 0x0000000101ca3079 08:14:42 INFO - rsp = 0x000000011e080b70 rbp = 0x000000011e080ba0 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 8 XUL!MessageLoop::DoWork() [message_loop.cc:6e420584d8bf : 430 + 0xa] 08:14:42 INFO - rbx = 0x000000011e080cf8 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x000000011e080bb8 08:14:42 INFO - r15 = 0x000000011e080bb0 rip = 0x0000000101ca338a 08:14:42 INFO - rsp = 0x000000011e080bb0 rbp = 0x000000011e080be0 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 9 XUL!base::MessagePumpDefault::Run(base::MessagePump::Delegate*) [message_pump_default.cc:6e420584d8bf : 34 + 0x8] 08:14:42 INFO - rbx = 0x000000011e080c18 r12 = 0x000000011c97a198 08:14:42 INFO - r13 = 0x000000011c97a180 r14 = 0x000000011e080cf8 08:14:42 INFO - r15 = 0x000000011e080c20 rip = 0x0000000101ca5e51 08:14:42 INFO - rsp = 0x000000011e080bf0 rbp = 0x000000011e080c70 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 10 XUL!MessageLoop::Run() [message_loop.cc:6e420584d8bf : 226 + 0x8] 08:14:42 INFO - rbx = 0x000000011e080cf8 r12 = 0x000000011e080df8 08:14:42 INFO - r13 = 0x0000000000009403 r14 = 0x000000011e080cf8 08:14:42 INFO - r15 = 0x000000011c07d5e8 rip = 0x0000000101ca29a6 08:14:42 INFO - rsp = 0x000000011e080c80 rbp = 0x000000011e080cc0 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 11 XUL!base::Thread::ThreadMain() [thread.cc:6e420584d8bf : 162 + 0x7] 08:14:42 INFO - rbx = 0x000000011c07d5c0 r12 = 0x000000011e080df8 08:14:42 INFO - r13 = 0x0000000000009403 r14 = 0x000000011e080cf8 08:14:42 INFO - r15 = 0x000000011c07d5e8 rip = 0x0000000101ca8ca0 08:14:42 INFO - rsp = 0x000000011e080cd0 rbp = 0x000000011e080f00 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 12 XUL!ThreadFunc [platform_thread_posix.cc:6e420584d8bf : 39 + 0x5] 08:14:42 INFO - rbx = 0x000000011e081000 r12 = 0x0000000000000000 08:14:42 INFO - r13 = 0x0000000000009403 r14 = 0x0000000101c93150 08:14:42 INFO - r15 = 0x000000011c07d5c0 rip = 0x0000000101c9315a 08:14:42 INFO - rsp = 0x000000011e080f10 rbp = 0x000000011e080f10 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 13 libSystem.B.dylib + 0x39fd5 08:14:42 INFO - rbx = 0x000000011e081000 r12 = 0x0000000000000000 08:14:42 INFO - r13 = 0x0000000000009403 r14 = 0x0000000101c93150 08:14:42 INFO - r15 = 0x000000011c07d5c0 rip = 0x00007fff86a74fd6 08:14:42 INFO - rsp = 0x000000011e080f20 rbp = 0x000000011e080f50 08:14:42 INFO - Found by: call frame info 08:14:42 INFO - 14 libSystem.B.dylib + 0x39e88 08:14:42 INFO - rip = 0x00007fff86a74e89 rsp = 0x000000011e080f60 08:14:42 INFO - rbp = 0x000000011e080f78 08:14:42 INFO - Found by: stack scanning 08:14:42 INFO - 15 XUL + 0x39314f 08:14:42 INFO - rip = 0x0000000101c93150 rsp = 0x000000011e081050 08:14:42 INFO - Found by: stack scanning
(In reply to Sotaro Ikeda [:sotaro] from comment #76) > https://tbpl.mozilla.org/?tree=Try&rev=dadffb68157d tryserver result is not good. Need to add more pointer check.
Add more pointer checks.
Attachment #8430199 - Attachment is obsolete: true
Attachment #8430338 - Flags: review+
Depends on: 924622
FYI, you can safely ignore the mochitest-e10s and Android debug results (they were never intended to run on Gecko 30 anyway). As a general rule of thumb, you can safely ignore any test results for things you don't see running on a normal b2g30 run on TBPL.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #80) > FYI, you can safely ignore the mochitest-e10s and Android debug results > (they were never intended to run on Gecko 30 anyway). As a general rule of > thumb, you can safely ignore any test results for things you don't see > running on a normal b2g30 run on TBPL. Thanks. From it, attachment 8430338 [details] [diff] [review] seems good enough to check-in without bug 924622.
Keywords: checkin-needed
No longer depends on: 924622
Bug 1006164 is now resolved for us. Thanks Sotaro.
Depends on: 1019877
Depends on: 1020003
Depends on: 1022167
Depends on: 1029719
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: