1447549 - Asssertion failure on start up with browser.startup.blankWindow=true on Windows debug builds

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Xidorn Quan [:xidorn] UTC+10]

When checking whether bug 1446264 breaks browser.startup.blankWindow per request from florian in bug 1446264 comment 26, I found it consistently crashes w/ or w/o patches there with the following stack:

Assertion failure: !aOther.IsNull() (Cannot compute with aOther null value), at \obj-firefox\dist\include\mozilla/TimeStamp.h:495
#01: mozilla::SystemTimeConverter<unsigned long>::IsTimeNewerThanTimestamp (\widget\systemtimeconverter.h:210)
#02: mozilla::SystemTimeConverter<unsigned long>::GetTimeStampFromSystemTime<mozilla::CurrentWindowsTimeGetter> (\widget\systemtimeconverter.h:101)
#03: nsWindow::GetMessageTimeStamp (\widget\windows\nswindow.cpp:6497)
#04: nsWindow::CurrentMessageWidgetEventTime (\widget\windows\nswindow.cpp:4183)
#05: nsWindow::InitEvent (\widget\windows\nswindow.cpp:4175)
#06: nsWindow::ProcessMessage (\widget\windows\nswindow.cpp:5983)
#07: nsWindow::WindowProcInternal (\widget\windows\nswindow.cpp:5043)
#08: CallWindowProcCrashProtected (\xpcom\base\nscrashonexception.cpp:32)
#09: nsWindow::WindowProc (\widget\windows\nswindow.cpp:4996)
#10: CallWindowProcW[C:\WINDOWS\System32\user32.dll +0xb85d]
#11: CallWindowProcW[C:\WINDOWS\System32\user32.dll +0xb54c]
#12: GetTopWindow[C:\WINDOWS\System32\user32.dll +0x219c3]
#13: KiUserCallbackDispatcher[C:\WINDOWS\SYSTEM32\ntdll.dll +0xa3b54]
#14: NtUserShowWindow[C:\WINDOWS\System32\win32u.dll +0x1b64]
#15: nsWindow::SetSizeMode (\widget\windows\nswindow.cpp:2124)
#16: nsXULWindow::LoadMiscPersistentAttributesFromXUL (\xpfe\appshell\nsxulwindow.cpp:1397)
#17: nsXULWindow::SizeShell (\xpfe\appshell\nsxulwindow.cpp:2364)
#18: nsXULWindow::OnChromeLoaded (\xpfe\appshell\nsxulwindow.cpp:1127)
#19: nsWebShellWindow::OnStateChange (\xpfe\appshell\nswebshellwindow.cpp:661)
#20: nsDocLoader::DoFireOnStateChange (\uriloader\base\nsdocloader.cpp:1315)
#21: nsDocLoader::doStopDocumentLoad (\uriloader\base\nsdocloader.cpp:869)
#22: nsDocLoader::DocLoaderIsEmpty (\uriloader\base\nsdocloader.cpp:749)
#23: nsDocLoader::OnStopRequest (\uriloader\base\nsdocloader.cpp:633)
#24: mozilla::net::nsLoadGroup::RemoveRequest (\netwerk\base\nsloadgroup.cpp:629)
#25: mozilla::net::nsLoadGroup::Cancel (\netwerk\base\nsloadgroup.cpp:261)
#26: nsDocLoader::Stop (\uriloader\base\nsdocloader.cpp:246)
#27: nsDocShell::Stop (\docshell\base\nsdocshell.cpp:5211)
#28: nsGlobalWindowOuter::StopOuter (\dom\base\nsglobalwindowouter.cpp:5029)
#29: nsGlobalWindowInner::Stop (\dom\base\nsglobalwindowinner.cpp:3724)
#30: mozilla::dom::WindowBinding::stop (\obj-firefox\dom\bindings\windowbinding.cpp:1833)
#31: mozilla::dom::WindowBinding::genericMethod (\obj-firefox\dom\bindings\windowbinding.cpp:16070)
#32: js::CallJSNative (\js\src\vm\jscontext-inl.h:290)
#33: js::InternalCallOrConstruct (\js\src\vm\interpreter.cpp:467)
#34: js::Call (\js\src\vm\interpreter.cpp:535)
#35: js::ForwardingProxyHandler::call (\js\src\proxy\wrapper.cpp:176)
#36: js::CrossCompartmentWrapper::call (\js\src\proxy\crosscompartmentwrapper.cpp:358)
#37: js::proxy_Call (\js\src\proxy\proxy.cpp:769)
#38: js::CallJSNative (\js\src\vm\jscontext-inl.h:290)
#39: js::InternalCallOrConstruct (\js\src\vm\interpreter.cpp:449)
#40: Interpret (\js\src\vm\interpreter.cpp:3085)
#41: js::RunScript (\js\src\vm\interpreter.cpp:417)
#42: js::ExecuteKernel (\js\src\vm\interpreter.cpp:703)
#43: ExecuteInExtensibleLexicalEnvironment (\js\src\builtin\eval.cpp:460)
#44: js::ExecuteInJSMEnvironment (\js\src\builtin\eval.cpp:546)
#45: js::ExecuteInJSMEnvironment (\js\src\builtin\eval.cpp:504)
#46: mozJSComponentLoader::ObjectForLocation (\js\xpconnect\loader\mozjscomponentloader.cpp:925)
#47: mozJSComponentLoader::LoadModule (\js\xpconnect\loader\mozjscomponentloader.cpp:444)
#48: nsComponentManagerImpl::KnownModule::Load (\xpcom\components\nscomponentmanager.cpp:751)
#49: nsFactoryEntry::GetFactory (\xpcom\components\nscomponentmanager.cpp:1782)
#50: nsComponentManagerImpl::CreateInstanceByContractID (\xpcom\components\nscomponentmanager.cpp:1080)
#51: nsComponentManagerImpl::GetServiceByContractID (\xpcom\components\nscomponentmanager.cpp:1443)
#52: nsGetServiceByContractIDWithError::operator() (\xpcom\components\nscomponentmanagerutils.cpp:293)
#53: nsCOMPtr_base::assign_from_gs_contractid_with_error (\xpcom\base\nscomptr.cpp:106)
#54: nsAppStartupNotifier::Observe (\toolkit\xre\nsappstartupnotifier.cpp:60)
#55: XREMain::XRE_mainRun (\toolkit\xre\nsapprunner.cpp:4597)
#56: XREMain::XRE_main (\toolkit\xre\nsapprunner.cpp:4911)
#57: XRE_main (\toolkit\xre\nsapprunner.cpp:5003)
#58: do_main (\browser\app\nsbrowserapp.cpp:232)
#59: NS_internal_main (\browser\app\nsbrowserapp.cpp:306)
#60: wmain (\toolkit\xre\nswindowswmain.cpp:132)
#61: __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
#62: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x11fe4]
#63: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x6efc1]

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

This is a local debug build on Windows, fwiw.

Comment 2

[Florian Quèze [:florian]]

Attachment: patch

So the problem here is that ::GetMessageTime returns 0 (I don't see any explanation for this in the MSDN documentation) for the WM_ACTIVATE message when browser.startup.blankWindow is true. This patch simply works around it.

Comment 3

[Jim Mathies [:jimm]]

Comment on attachment 8961008 [details] [diff] [review]
patch

Review of attachment 8961008 [details] [diff] [review]:
-----------------------------------------------------------------

BTW, this early window looks really bad on Win7.

Comment 4

[Florian Quèze [:florian]]

(In reply to Jim Mathies [:jimm] from comment #3)
> Review of attachment 8961008 [details] [diff] [review]:

Thanks for the review!

> BTW, this early window looks really bad on Win7.

What looks bad about it on Win7?

Comment 5

[Jim Mathies [:jimm]]

(In reply to Florian Quèze [:florian] from comment #4)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > Review of attachment 8961008 [details] [diff] [review]:
> 
> Thanks for the review!
> 
> > BTW, this early window looks really bad on Win7.
> 
> What looks bad about it on Win7?

The window displays without glass set up, so the whole window is black for about a second, then it reflows, glass margins get set and chrome paints.

Comment 6

[Florian Quèze [:florian]]

(In reply to Jim Mathies [:jimm] from comment #5)
> (In reply to Florian Quèze [:florian] from comment #4)
> > (In reply to Jim Mathies [:jimm] from comment #3)
> > > Review of attachment 8961008 [details] [diff] [review]:
> > 
> > Thanks for the review!
> > 
> > > BTW, this early window looks really bad on Win7.
> > 
> > What looks bad about it on Win7?
> 
> The window displays without glass set up, so the whole window is black for
> about a second, then it reflows, glass margins get set and chrome paints.

I can't reproduce this.

With the default Windows 7 theme I see the whole window being blank (white or light gray, can't say for sure) for a little while before the browser UI appears.

With the Windows 7 basic or Windows Classic themes, I only get the borders painted, the rest of the window is transparent until the browser UI appears. This doesn't look great, but is probably still better than no feedback that the browser is starting.


So there's a missing step to reproduce the blank window issue. I wonder if it could be that this displays random GPU memory, so with a freshly booted system it's blank, but if you used your machine for a while there's something else.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ada0ac5968f3
avoid crashing windows debug builds at startup when ::GetMessageTime returns 0, r=jimm.

Comment 8

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/ada0ac5968f3