[1.Description]: [Flame][v2.2&3.0][Browser]Device will reboot if we tap show windows button at once in Browser while the website is loading. Attachment: logcat_flame_2101.txt and Device_Crash.3gp Occurrence time: 21:01 [2.Testing Steps]: 1. Open Browser. 2. Tap the URL bar. 3. When the Key-board pops up, tap the Website a few times under TOP SITES. 4. While the Website is loading, tap Show Windows button at once. [3.Expected Result]: 4. Device should enter show windows page. [4.Actual Result]: 4. The device will reboot. [5.Reproduction build]: Flame 2.2 build: (Affected) Build ID 20150315162500 Gaia Revision a6b2d3f8478ec250beb49950fecbb8a16465ff6f Gaia Date 2015-03-15 14:33:22 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/18619f8f6c5c Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150315.195030 Firmware Date Sun Mar 15 19:50:42 EDT 2015 Bootloader L1TC000118D0 Flame 3.0 build: (Affected) Build ID 20150315160203 Gaia Revision d4177902b04b8fedcb7df9a30ae6e9677e03d2d4 Gaia Date 2015-03-13 15:58:35 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/af68c9c0e903 Gecko Version 39.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150315.192711 Firmware Date Sun Mar 15 19:27:22 EDT 2015 Bootloader L1TC000118D0 [6.Reproduction Frequency]: Always Recurrence,5/5 [7.TCID]: Free Test

A regression bug? --- -- - --- -- - --- -- - --- -- - --- -- - Hi, Paladin, May I have your help? Can we have a branch check? (v2.1) One more request, please attach crash ID here if it is a app/system crash. Many thanks.

This seems like a bug in the browser api. Kanru can you take a look? [Child 1606] WARNING: Transparent content with displayports can be expensive.: file ../../../layout/base/nsDisplayList.cpp, line 1713 [Parent 1190] WARNING: INPQ received useless SetConfirmedTargetApzc: file ../../../gfx/layers/apz/src/InputQueue.cpp, line 357 [Child 1752] WARNING: nsWindow::GetNativeData not implemented for this type: file ../../widget/PuppetWidget.cpp, line 961 [Parent 1190] WARNING: NS_ENSURE_TRUE(openerFrameElement) failed: file ../../../dom/browser-element/BrowserElementParent.cpp, line 213 [Parent 1190] WARNING: Error constructing actor PRenderFrameParent: file PBrowserParent.cpp, line 1458 [Parent 1190] ###!!! ASSERTION: IPDL error [PBrowserParent]: "Error deserializing 'PRenderFrameParent'". Killing child side as a result.: 'Error', file ../../../ipc/glue/ProtocolUtils.cpp, line 212 Program received signal SIGTERM, Terminated. kill () at bionic/libc/arch-arm/bionic/kill.S:45 45 ldmfd sp!, {r4-r7, ip, lr} (gdb) bt #0 kill () at bionic/libc/arch-arm/bionic/kill.S:45 #1 0xb4346754 in base::KillProcess (process_id=process_id@entry=0, exit_code=exit_code@entry=1, wait=wait@entry=false) at ../../../ipc/chromium/src/base/process_util_posix.cc:70 #2 0xb435a75e in mozilla::ipc::FatalError (aProtocolName=0xb5e7adb1 "PBrowserParent", aMsg=aMsg@entry=0xad683a80 "X\"j\266", aHandle=0, aIsParent=aIsParent@entry=true) at ../../../ipc/glue/ProtocolUtils.cpp:215 #3 0xb443dba6 in mozilla::dom::PBrowserParent::FatalError (this=<optimized out>, aMsg=0xad683a80 "X\"j\266") at PBrowserParent.cpp:3376 #4 0xb4452f44 in mozilla::dom::PBrowserParent::OnMessageReceived (this=0xad683a80, __msg=..., __reply=@0xbe8aa67c: 0x0) at PBrowserParent.cpp:3202 #5 0xb44a566a in mozilla::dom::PContentParent::OnMessageReceived (this=0xaf217200, __msg=..., __reply=@0xbe8aa67c: 0x0) at PContentParent.cpp:4918 #6 0xb435ea96 in mozilla::ipc::MessageChannel::DispatchSyncMessage (this=this@entry=0xaf217230, aMsg=...) at ../../../ipc/glue/MessageChannel.cpp:1182 #7 0xb435f47a in mozilla::ipc::MessageChannel::DispatchMessage (this=this@entry=0xaf217230, aMsg=...) at ../../../ipc/glue/MessageChannel.cpp:1139 #8 0xb4363f4c in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=0xaf217230) at ../../../ipc/glue/MessageChannel.cpp:1127 #9 0xb4156d48 in DispatchToMethod<FdWatcher, void (FdWatcher::*)()> (method=(void (FdWatcher::*)(FdWatcher * const)) 0xb4363eb9 <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, arg=...) at ../../../ipc/chromium/src/base/tuple.h:383 #10 RunnableMethod<FdWatcher, void (FdWatcher::*)(), Tuple0>::Run (this=<optimized out>) at ../../../ipc/chromium/src/base/task.h:310 #11 0xb435b0de in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:445 #12 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:462 #13 0xb434b62c in MessageLoop::RunTask (this=0xb6a321c0, task=0xaa16f148) at ../../../ipc/chromium/src/base/message_loop.cc:361 #14 0xb434e762 in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at ../../../ipc/chromium/src/base/message_loop.cc:369 #15 0xb4350538 in DoWork (this=<optimized out>) at ../../../ipc/chromium/src/base/message_loop.cc:456 #16 MessageLoop::DoWork (this=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:435 #17 0xb43586f6 in mozilla::ipc::DoWorkRunnable::Run (this=<optimized out>) at ../../../ipc/glue/MessagePump.cpp:233 #18 0xb4192b4c in nsThread::ProcessNextEvent (this=0xb6a533c0, aMayWait=<optimized out>, aResult=0xbe8aa837) at ../../../xpcom/threads/nsThread.cpp:855 #19 0xb41a87c8 in NS_ProcessNextEvent (aThread=0xb6a533c0, aMayWait=aMayWait@entry=false) at /Volumes/mac/moz/ib2g/xpcom/glue/nsThreadUtils.cpp:265 #20 0xb4360ae4 in mozilla::ipc::MessagePump::Run (this=0xb6a07690, aDelegate=0xb6a321c0) at ../../../ipc/glue/MessagePump.cpp:99 #21 0xb434c618 in MessageLoop::RunInternal (this=this@entry=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:233 #22 0xb434c632 in RunHandler (this=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:226 #23 MessageLoop::Run (this=0xb6a321c0) at ../../../ipc/chromium/src/base/message_loop.cc:200 #24 0xb502b932 in nsBaseAppShell::Run (this=0xb6a48340) at ../../widget/nsBaseAppShell.cpp:164 #25 0xb5472292 in nsAppStartup::Run (this=0xb1e12550) at ../../../../toolkit/components/startup/nsAppStartup.cpp:281 #26 0xb54a2568 in XREMain::XRE_mainRun (this=this@entry=0xbe8aa9c0) at ../../../toolkit/xre/nsAppRunner.cpp:4202 #27 0xb54a273c in XREMain::XRE_main (this=this@entry=0xbe8aa9c0, argc=argc@entry=1, argv=argv@entry=0xb6a27288, aAppData=aAppData@entry=0xb6fa6858 <_ZL8sAppData>) at ../../../toolkit/xre/nsAppRunner.cpp:4278 #28 0xb54a28b6 in XRE_main (argc=1, argv=0xb6a27288, aAppData=0xb6fa6858 <_ZL8sAppData>, aFlags=<optimized out>) at ../../../toolkit/xre/nsAppRunner.cpp:4498 #29 0xb6f8b12e in do_main (argc=argc@entry=1, argv=argv@entry=0xb6a27288) at ../../../b2g/app/nsBrowserApp.cpp:167 #30 0xb6f8b26a in b2g_main (argc=argc@entry=1, argv=argv@entry=0xbe8abc94) at ../../../b2g/app/nsBrowserApp.cpp:299

Hi William, We can't reproduce this issue on Flame 2.1 Reproducing Rate: 0/10 The device does not crash. If it is a crash happening in app/system, I will update it. Flame 2.1 build: (Unaffected) Build ID 20150316161200 Gaia Revision e53469fe3a5e563a9146d0fb028e544a423b7e96 Gaia Date 2015-03-16 15:30:43 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/32d1cae787e0 Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150316.192737 Firmware Date Mon Mar 16 19:27:48 EDT 2015 Bootloader L1TC000118D0

(In reply to Paladin from comment #4) > Hi William, > We can't reproduce this issue on Flame 2.1 > Reproducing Rate: 0/10 > > The device does not crash. If it is a crash happening in app/system, I will > update it. > > Flame 2.1 build: (Unaffected) > Build ID 20150316161200 > Gaia Revision e53469fe3a5e563a9146d0fb028e544a423b7e96 > Gaia Date 2015-03-16 15:30:43 > Gecko Revision > https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/32d1cae787e0 > Gecko Version 34.0 > Device Name flame > Firmware(Release) 4.4.2 > Firmware(Incremental) eng.cltbld.20150316.192737 > Firmware Date Mon Mar 16 19:27:48 EDT 2015 > Bootloader L1TC000118D0 Thanks for your help. A regression bug. Nominate it.

I found it almost impossible to tap the "show windows" buttons while the page is loading. It immediately switches to "..." Is there easier STR? Or I'm doing it wrong?

I could reproduce this on latest m-c so it looks like a recent regression. Regression window wanted.

I was unable to get the regression window as the repro rate reduces significantly. While the recent builds reproduce the issue easily, I reproduced once after attempting more than 10 times on an earlier build. This is the earliest build I could reproduce: Environmental Variables: Device: Flame 2.2 BuildID: 20141120231111 Gaia: d695e7cdcd162e779e15594054931c84dec34a95 Gecko: 7b56755a63ba Version: 36.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

(In reply to Kan-Ru Chen [:kanru] from comment #7) > I could reproduce this on latest m-c so it looks like a recent regression. > Regression window wanted. You might want to try with a debug gecko. I had no issues reproducing it.

OK, so this is reproducible from a quite old build. It just become easier to trigger recently.

Hi Kan-Ru, do you mind taking this bug? thank.

Looks like a regression from bug 108565, Sotaro, could you take a look? http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp?rev=ca6d6b665bc1&mark=1530-1539#1530 1530 TextureFactoryIdentifier textureFactoryIdentifier; 1531 uint64_t layersId = 0; 1532 PRenderFrameChild* renderFrame = newChild->SendPRenderFrameConstructor(); 1533 newChild->SendGetRenderFrameInfo(renderFrame, 1534 &textureFactoryIdentifier, 1535 &layersId); 1536 if (layersId == 0) { // if renderFrame is invalid. 1537 PRenderFrameChild::Send__delete__(renderFrame); 1538 renderFrame = nullptr; 1539 } We stop at line 1533 because if renderFrame is invalid it couldn't be deserialized by B2G process. The IPC layer will kill itself because of the malformed message. How could the renderFrame be invalid? See below: http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.cpp?rev=ca6d6b665bc1&mark=2299-2319#2299 2299 PRenderFrameParent* 2300 TabParent::AllocPRenderFrameParent() 2301 { 2302 MOZ_ASSERT(ManagedPRenderFrameParent().IsEmpty()); 2303 nsRefPtr<nsFrameLoader> frameLoader = GetFrameLoader(); 2304 TextureFactoryIdentifier textureFactoryIdentifier; 2305 uint64_t layersId = 0; 2306 bool success = false; 2307 if(frameLoader) { 2308 PRenderFrameParent* renderFrame = 2309 new RenderFrameParent(frameLoader, 2310 &textureFactoryIdentifier, 2311 &layersId, 2312 &success); 2313 MOZ_ASSERT(success); 2314 AddTabParentToTable(layersId, this); 2315 return renderFrame; 2316 } else { 2317 return nullptr; 2318 } 2319 } I'm not sure what's happening here yet, but in this bug the GetFrameLoader returns nullptr. Maybe we are trying to initialize PRenderFrame before the iframe is attached to the document?

Okey, I take a look.

> > I'm not sure what's happening here yet, but in this bug the GetFrameLoader > returns nullptr. Maybe we are trying to initialize PRenderFrame before the > iframe is attached to the document? TabParent::mFrameElement was nullptr when the problem happened. In this use case, it should be set by SetOwnerElement() in BrowserElementParent::OpenWindowOOP() https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.cpp#239 But the OpenWindowOOP() was failed at the following. > NS_ENSURE_TRUE(openerFrameElement, > BrowserElementParent::OPEN_WINDOW_IGNORED); https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.cpp#212 The OpenWindowOOP() returns BrowserElementParent::OPEN_WINDOW_IGNORED. But TabParent::RecvBrowserFrameOpenWindow() handle it as success. Then the following check in TabChild::ProvideWindowCommon() did not work. > if (!*aWindowIsNew) { > PBrowserChild::Send__delete__(newChild); > return NS_ERROR_ABORT; > } https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp#1525 Then "newChild->SendPRenderFrameConstructor();" is called incorrectly.

The patch fixed the problem for me.

This bug seems regression of Bug 826325.

(In reply to Sotaro Ikeda [:sotaro] from comment #14) > > > > I'm not sure what's happening here yet, but in this bug the GetFrameLoader > > returns nullptr. Maybe we are trying to initialize PRenderFrame before the > > iframe is attached to the document? > > TabParent::mFrameElement was nullptr when the problem happened. This is weird. > In this use case, it should be set by SetOwnerElement() in > BrowserElementParent::OpenWindowOOP() > > https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/ > BrowserElementParent.cpp#239 > > But the OpenWindowOOP() was failed at the following. > > > NS_ENSURE_TRUE(openerFrameElement, > > BrowserElementParent::OPEN_WINDOW_IGNORED); > > https://dxr.mozilla.org/mozilla-central/source/dom/browser-element/ > BrowserElementParent.cpp#212 Again, this shouldn't happen. > *aOutWindowOpened = (opened != BrowserElementParent::OPEN_WINDOW_CANCELLED); I believe this code is doing what's intended. Thanks, Sotaro. I'm not sure how the STR triggers the nullptr mFrameElement, I'll look into it.

The patch add some logs around the crash.

I used attachment 8581596 [details] [diff] [review] to check the sequence until the crash.

logcat log of the crash by applying attachment 8581596 [details] [diff] [review].

FC for v2.2 is coming. Are we going to postpone this bug?

Comment on attachment 8581186 [details] [diff] [review] patch - Fix OutWindowOpened flag Review of attachment 8581186 [details] [diff] [review]: ----------------------------------------------------------------- So after read the patch in bug 826325 again, I think you are correct, Sotaro. We should return the same value as in https://dxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsContentTreeOwner.cpp#867

Thanks. As a short time fix, attachment 8581186 [details] [diff] [review] is good, I think.

Carsten, since this bug is a 2.2 blocker, could you please uplift it? Thanks.

Comment on attachment 8581186 [details] [diff] [review] patch - Fix OutWindowOpened flag NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 826325 User impact if declined: device could reboot when using browser app Testing completed: locally tested. Risk to taking this patch (and alternatives if risky): low String or UUID changes made by this patch:none.

This issue had been successfully verified on Flame 2.2&3.0 Reproducing rate: 0/5 Flame 2.2 [Verified] Build ID 20150406002503 Gaia Revision a6351e1197d54f8624523c2db9ba1418f2aa046f Gaia Date 2015-04-03 22:06:41 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c3335a5d3063 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150406.040047 Firmware Date Mon Apr 6 04:00:58 EDT 2015 Bootloader L1TC000118D0 Flame 3.0[Verified] Build ID 20150406160205 Gaia Revision 834385f4c834238a4306bf87cc4be41615d91ff0 Gaia Date 2015-04-06 19:41:47 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/a530b5c3b713 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150406.194015 Firmware Date Mon Apr 6 19:40:27 EDT 2015 Bootloader L1TC000118D0

Leaving verify me for status-firefox40, there is no this device.

(In reply to Alissa from comment #30) > Leaving verify me for status-firefox40, there is no this device. That is not necessary. As long as b2g branches are verified this is considered verified.