Closed Bug 1279103 Opened 8 years ago Closed 8 years ago

Intermittent browser_windowStateContainer.js | The docShell has the correct userContextId - 1 == 0 -

Categories

(Firefox :: Session Restore, defect, P3)

49 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: KWierso, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, Whiteboard: [userContextId][OA])

Flags: needinfo?(allstars.chh)
Assignee: nobody → allstars.chh
Flags: needinfo?(allstars.chh)
from the log, this could be the reason that caused timeout. 17:58:06 INFO - [Child 1320] ###!!! ASSERTION: no SHEntry for a non-transient viewer?: 'NS_IsAboutBlank(mCurrentURI)', file /home/worker/workspace/build/src/docshell/base/nsDocShell.cpp, line 11467 17:59:10 INFO - #01: nsDocShell::OnLoadingSite [docshell/base/nsDocShell.cpp:11625] 17:59:10 INFO - #02: nsDocShell::CreateContentViewer [docshell/base/nsDocShell.cpp:9100] 17:59:10 INFO - #03: nsDSURIContentListener::DoContent [docshell/base/nsDSURIContentListener.cpp:129] 17:59:10 INFO - #04: nsDocumentOpenInfo::TryContentListener [uriloader/base/nsURILoader.cpp:724] 17:59:10 INFO - #05: nsDocumentOpenInfo::DispatchContent [uriloader/base/nsURILoader.cpp:398] 17:59:10 INFO - #06: nsDocumentOpenInfo::OnStartRequest [uriloader/base/nsURILoader.cpp:261] 17:59:10 INFO - #07: mozilla::net::HttpChannelChild::DoOnStartRequest [netwerk/protocol/http/HttpChannelChild.cpp:526] 17:59:10 INFO - #08: mozilla::net::HttpChannelChild::OnStartRequest [netwerk/protocol/http/HttpChannelChild.cpp:443] 17:59:10 INFO - #09: mozilla::net::StartRequestEvent::Run [netwerk/protocol/http/HttpChannelChild.cpp:340] 17:59:10 INFO - #10: mozilla::net::ChannelEventQueue::RunOrEnqueue [mfbt/UniquePtr.h:288] 17:59:10 INFO - #11: mozilla::net::HttpChannelChild::RecvOnStartRequest [netwerk/protocol/http/HttpChannelChild.cpp:392] 17:59:10 INFO - #12: mozilla::net::PHttpChannelChild::OnMessageReceived [obj-firefox/ipc/ipdl/PHttpChannelChild.cpp:649] 17:59:10 INFO - #13: mozilla::ipc::MessageChannel::DispatchAsyncMessage [ipc/glue/MessageChannel.h:552] 17:59:10 INFO - #14: mozilla::ipc::MessageChannel::DispatchMessage [ipc/glue/MessageChannel.cpp:1598] 17:59:10 INFO - #15: mozilla::ipc::MessageChannel::OnMaybeDequeueOne [ipc/glue/MessageChannel.cpp:1552] 17:59:10 INFO - #16: nsRunnableMethodImpl<bool (mozilla::ipc::MessageChannel::*)(), false, true>::Run [xpcom/glue/nsThreadUtils.h:759] 17:59:10 INFO - #17: mozilla::ipc::MessageChannel::DequeueTask::Run [ipc/glue/MessageChannel.h:498] 17:59:10 INFO - #18: nsThread::ProcessNextEvent [xpcom/threads/nsThread.cpp:1073] 17:59:10 INFO - #19: NS_ProcessNextEvent [xpcom/glue/nsThreadUtils.cpp:290] 17:59:10 INFO - #20: mozilla::ipc::MessagePump::Run [ipc/glue/MessagePump.cpp:132] 17:59:10 INFO - #21: MessageLoop::RunInternal [ipc/chromium/src/base/message_loop.cc:236] 17:59:10 INFO - #22: MessageLoop::Run [ipc/chromium/src/base/message_loop.cc:493] 17:59:10 INFO - #23: nsBaseAppShell::Run [widget/nsBaseAppShell.cpp:158] 17:59:10 INFO - #24: XRE_RunAppShell [toolkit/xre/nsEmbedFunctions.cpp:832] 17:59:10 INFO - #25: mozilla::ipc::MessagePumpForChildProcess::Run [ipc/glue/MessagePump.cpp:285] 17:59:10 INFO - #26: MessageLoop::RunInternal [ipc/chromium/src/base/message_loop.cc:236] 17:59:10 INFO - #27: MessageLoop::Run [ipc/chromium/src/base/message_loop.cc:493] 17:59:10 INFO - #28: XRE_InitChildProcess [toolkit/xre/nsEmbedFunctions.cpp:666] 17:59:10 INFO - #29: content_process_main [ipc/contentproc/plugin-container.cpp:227] 17:59:10 INFO - #30: libc.so.6 + 0x2176d 17:59:10 INFO - #31: _start
Priority: -- → P3
Whiteboard: [userContextId][OA]
Hi Baku From the log (Comment 2), I am still not sure the assertion is the root cause here, but those failures only occured in debug build, and the assert is also only enabled in debug build (NS_Assert inside #ifdef DEBUG), so I suspect they are related. It looks like that container tab doesn't have correct SessionHistory after SessionRestore(more specifically, after nsISessionStore.setWindowState). Also in my local test, if I make all tabs are normal tabs(i.e., userContextId: 0), I won't see the assertion. I guess there's something wrong with SessionHistory in container tab, can you provide some suggestions here? Thanks
Flags: needinfo?(amarchesini)
Yoshi, sorry for the delay. Can you reproduce this bug locally? Is it easy to reproduce? I don't know the reason why we have this issue, but I'll try to reproduce it locally.
Flags: needinfo?(amarchesini)
Flags: needinfo?(allstars.chh)
(In reply to Andrea Marchesini [:baku] from comment #6) > Yoshi, sorry for the delay. > > Can you reproduce this bug locally? Is it easy to reproduce? Hi Baku I can see the assertion (NS_Assert) from comment 2 locally everytime I run this test, although the tests still pass successfully. Anyway, thanks for your help, I'll keep looking into this, if I have further information will ask for your suggestion then. :)
Flags: needinfo?(allstars.chh)
Assignee: allstars.chh → nobody
Status: ASSIGNED → NEW
There have been no orange reports in over 2 months. Is this still an issue? Can it be reproduced, or can we close worksforme?
Actually it has not happened over 3 months. I am going to close it. Anyone feel free to reopen if you can reproduce it.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.