Closed Bug 1266022 Opened 9 years ago Closed 9 years ago

Assertion failure: originAttrsLoadInfo.mUserContextId == originAttrsLoadContext.mUserContextId

Categories

(Core :: DOM: Security, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox48 --- affected
firefox49 --- fixed

People

(Reporter: allstars.chh, Assigned: allstars.chh)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-active][userContextId][OA])

Attachments

(1 file, 2 obsolete files)

STR: set privacy.userContext.enabled to true File -> New Container Tab -> Personal Then Firefox crashes. Similar bugs are Bug 1265062, Bug 1264230 and also Bug 1264231
Whiteboard: [domsecurity-active]
I can't seem to get FX to crash when opening/using containers. I've tried opening over 20 container tabs and loading different content/websites within those containers but never ran into any crashes. Yoshi, did you run into this while running a default build? (was there a crash report?) I did run into the following error when attempting to reproduce the issue on the m-c that I've build using ./mach run --debug and then "run" under lldb: * thread #1: tid = 0x383fec, 0x0000000102e19400 XUL`BackstagePass::QueryInterface(this=0x000000012dbee1c0, aIID=0x0000000105e9c440, aInstancePtr=0x00007fff5fbfc998) at XPCRuntimeService.cpp:15, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE frame #0: 0x0000000102e19400 XUL`BackstagePass::QueryInterface(this=0x000000012dbee1c0, aIID=0x0000000105e9c440, aInstancePtr=0x00007fff5fbfc998) at XPCRuntimeService.cpp:15 12 #include "nsIPrincipal.h" 13 #include "mozilla/dom/BindingUtils.h" 14 -> 15 NS_INTERFACE_MAP_BEGIN(BackstagePass) 16 NS_INTERFACE_MAP_ENTRY(nsIGlobalObject) 17 NS_INTERFACE_MAP_ENTRY(nsIXPCScriptable) 18 NS_INTERFACE_MAP_ENTRY(nsIClassInfo) Builds Used: * https://ftp.mozilla.org/pub/firefox/nightly/2016/04/2016-04-20-03-02-13-mozilla-central/ * https://ftp.mozilla.org/pub/firefox/nightly/2016/04/2016-04-20-00-40-46-mozilla-aurora/ * m-c f05a1242fb29 tip (./mach run --debug) * m-a (./mach run --debug)
(In reply to Kamil Jozwiak [:kjozwiak] from comment #1) Hi Kamil Did you enable debug? it's MOZ_ASSERT that triggering the crash and it only works when we enable debug. ac_add_options --enable-debug I ran into in my local build, I think this happens after Bug 1125916 landed.
So far this bug looks similar to Bug 1265062, gecko tries to load a CSS file and it crashes with mismatching loadInfo. I'll look into those last comments of Bug 1265062 as it looks like we have similar problem for passing wrong loading context to load CSS file like Bug 1256999. NewChannelFromURIWithProxyFlagsInternal spec=about:newtab NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/content/newtab/newTab.xhtml NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/browser/content/browser/newtab/newTab.xhtml NS_CompareLoadInfoAndLoadContext - spec =file:///home/allstars/ssd/gecko-dev/browser/base/content/newtab/newTab.xhtml loadInfo: 0, 0, 1, 0; loadContext: 0 0, 1, 0. [channel=0x7fffc4802b50] ++DOMWINDOW == 18 (0x7fffcf039800) [pid = 10470] [serial = 23] [outer = 0x7fffc72f2c00] NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/locale/newTab.dtd NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/en-US/locale/browser/newTab.dtd NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/locale/browser.dtd NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/en-US/locale/browser/browser.dtd NewChannelFromURIWithProxyFlagsInternal spec=chrome://global/locale/global.dtd NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/chrome/en-US/locale/en-US/global/global.dtd [Main Thread]: D/nsCSSLoader css::Loader::LoadStyleLink [Main Thread]: D/nsCSSLoader Link uri: 'chrome://global/skin/global.css' [Main Thread]: D/nsCSSLoader Link title: '' [Main Thread]: D/nsCSSLoader Link media: 'all' [Main Thread]: D/nsCSSLoader Link alternate rel: 0 [Main Thread]: D/nsCSSLoader css::Loader::CreateSheet [Main Thread]: D/nsCSSLoader From XUL cache: 7fffd03f8b40 [Main Thread]: D/nsCSSLoader State: eSheetComplete [Main Thread]: D/nsCSSLoader Sheet is alternate: 0 [Main Thread]: D/nsCSSLoader css::Loader::InsertSheetInDoc [Main Thread]: D/nsCSSLoader Inserting into document at position 0 [Main Thread]: D/nsCSSLoader Sheet already complete: 0x7fffc4affdc0 [Main Thread]: D/nsCSSLoader css::Loader::PostLoadEvent [Main Thread]: D/nsCSSLoader css::Loader::LoadStyleLink [Main Thread]: D/nsCSSLoader Link uri: 'chrome://browser/content/contentSearchUI.css' [Main Thread]: D/nsCSSLoader Link title: '' [Main Thread]: D/nsCSSLoader Link media: 'all' [Main Thread]: D/nsCSSLoader Link alternate rel: 0 [Main Thread]: D/nsCSSLoader css::Loader::CreateSheet [Main Thread]: D/nsCSSLoader From XUL cache: 0 [Main Thread]: D/nsCSSLoader From completed: 0 [Main Thread]: D/nsCSSLoader State: eSheetNeedsParser [Main Thread]: D/nsCSSLoader Sheet is alternate: 0 [Main Thread]: D/nsCSSLoader css::Loader::InsertSheetInDoc [Main Thread]: D/nsCSSLoader Inserting into document at position 1 [Main Thread]: D/nsCSSLoader css::Loader::LoadSheet [Main Thread]: D/nsCSSLoader Load from: 'chrome://browser/content/contentSearchUI.css' NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/content/contentSearchUI.css NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/browser/content/browser/contentSearchUI.css Breakpoint 1, nsIOService::NewChannelFromURIWithProxyFlagsInternal (this=0x7ffff6bacb40, aURI=0x7fffc8d3c900, aProxyURI=0x0, aProxyFlags=0, aLoadInfo=0x7fffc52d4480, result=0x7fffffffa9b0) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:734 734 printf("found\n"); (gdb) bt #0 0x00007fffe3a3218f in nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsILoadInfo*, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffc8d3c900, aProxyURI=0x0, aProxyFlags=0, aLoadInfo=0x7fffc52d4480, result=0x7fffffffa9b0) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:734 #1 0x00007fffe3a320a8 in nsIOService::NewChannelFromURIWithLoadInfo(nsIURI*, nsILoadInfo*, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffc8d3c900, aLoadInfo=0x7fffc52d4480, result=0x7fffffffa9b0) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:718 #2 0x00007fffe3a46fe5 in NS_NewChannelInternal(nsIChannel**, nsIURI*, nsILoadInfo*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) (outChannel=0x7fffffffaa70, aUri=0x7fffc8d3c900, aLoadInfo=0x7fffc52d4480, aLoadGroup=0x0, aCallbacks=0x0, aLoadFlags=0, aIoService=0x7ffff6bacb40) at /home/allstars/ssd/gecko-dev/netwerk/base/nsNetUtil.inl:226 #3 0x00007fffe3932d34 in nsChromeProtocolHandler::NewChannel2(nsIURI*, nsILoadInfo*, nsIChannel**) (this=0x7fffde8e7940, aURI=0x7fffc8d3bc00, aLoadInfo=0x7fffc52d4480, aResult=0x7fffffffabe0) at /home/allstars/ssd/gecko-dev/chrome/nsChromeProtocolHandler.cpp:149 #4 0x00007fffe3a327be in nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsILoadInfo*, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffc8d3bc00, aProxyURI=0x0, aProxyFlags=0, aLoadInfo=0x7fffc52d4480, result=0x7fffffffaf20) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:804 #5 0x00007fffe3a32d75 in nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffc8d3bc00, aProxyURI=0x0, aProxyFlags=0, aLoadingNode=0x7fffd4efbde0, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, result=0x7fffffffaf20) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:899 #6 0x00007fffe3a31f3a in nsIOService::NewChannelFromURI2(nsIURI*, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffc8d3bc00, aLoadingNode=0x7fffd4efbde0, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, result=0x7fffffffaf20) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:671 #7 0x00007fffe3a46aec in NS_NewChannelInternal(nsIChannel**, nsIURI*, nsINode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) (outChannel=0x7fffffffb070, aUri=0x7fffc8d3bc00, aLoadingNode= 0x7fffd4efbd60, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, aLoadGroup=0x7fffc488de00, aCallbacks=0x0, aLoadFlags=4194304, aIoService=0x7ffff6bacb40) at /home/allstars/ssd/gecko-dev/netwerk/base/nsNetUtil.inl:179 #8 0x00007fffe3a47baf in NS_NewChannelWithTriggeringPrincipal(nsIChannel**, nsIURI*, nsINode*, nsIPrincipal*, unsigned int, unsigned int, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) (outChannel=0x7fffffffb070, aUri=0x7fffc8d3bc00, aLoadingNode=0x7fffd4efbd60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, aLoadGroup=0x7fffc488de00, aCallbacks=0x0, aLoadFlags=4194304, aIoService=0x0) at /home/allstars/ssd/gecko-dev/netwerk/base/nsNetUtil.cpp:105 #9 0x00007fffe74d5c4e in mozilla::css::Loader::LoadSheet(mozilla::css::SheetLoadData*, mozilla::css::StyleSheetState, bool) (this=0x7fffc4afeec0, aLoadData=0x7fffc52d43c0, aSheetState=mozilla::css::eSheetNeedsParser, aIsPreload=false) at /home/allstars/ssd/gecko-dev/layout/style/Loader.cpp:1645 #10 0x00007fffe74d8d2d in mozilla::css::Loader::LoadStyleLink(nsIContent*, nsIURI*, nsAString_internal const&, nsAString_internal const&, bool, mozilla::CORSMode, mozilla::net::ReferrerPolicy, nsAString_internal const&, nsICSSLoaderObserver*, bool*) (this=0x7fffc4afeec0, aElement= 0x7fffd4efbd60, aURL=0x7fffc8d3bc00, aTitle=..., aMedia=..., aHasAlternateRel=false, aCORSMode=mozilla::CORS_NONE, aReferrerPolicy=mozilla::net::RP_No_Referrer_When_Downgrade, aIntegrity=..., aObserver=0x7fffc58ef000, aIsAlternate=0x7fffffffb3e2) at /home/allstars/ssd/gecko-dev/layout/style/Loader.cpp:2138 #11 0x00007fffe546b022 in nsStyleLinkElement::DoUpdateStyleSheet(nsIDocument*, mozilla::dom::ShadowRoot*, nsICSSLoaderObserver*, bool*, bool*, bool) (this=0x7fffd4efbdf8, aOldDocument=0x0, aOldShadowRoot= 0x0, aObserver=0x7fffc58ef000, aWillNotify=0x7fffffffb859, aIsAlternate=0x7fffffffb85a, aForceUpdate=false) at /home/allstars/ssd/gecko-dev/dom/base/nsStyleLinkElement.cpp:448 #12 0x00007fffe5469ff7 in nsStyleLinkElement::UpdateStyleSheet(nsICSSLoaderObserver*, bool*, bool*, bool) (this=0x7fffd4efbdf8, aObserver=0x7fffc58ef000, aWillNotify=0x7fffffffb859, aIsAlternate=0x7fffffffb85a, aForceReload=false) at /home/allstars/ssd/gecko-dev/dom/base/nsStyleLinkElement.cpp:227
(In reply to Yoshi Huang[:allstars.chh] from comment #2) > (In reply to Kamil Jozwiak [:kjozwiak] from comment #1) > Hi Kamil > Did you enable debug? it's MOZ_ASSERT that triggering the crash and it only > works when we enable debug. > ac_add_options --enable-debug > > I ran into in my local build, I think this happens after Bug 1125916 landed. Thanks Yoshi, running the build with "ac_add_options --enable-debug" definitely did the trick under m-c. Looks like it's asserting here: Process 10576 stopped * thread #1: tid = 0x5c5148, 0x0000000102808dca XUL`NS_CompareLoadInfoAndLoadContext(aChannel=<unavailable>) + 1322 at nsNetUtil.cpp:2420, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000102808dca XUL`NS_CompareLoadInfoAndLoadContext(aChannel=<unavailable>) + 1322 at nsNetUtil.cpp:2420 2417 "The value of InIsolatedMozBrowser in the loadContext and in " 2418 "the loadInfo are not the same!"); 2419 -> 2420 MOZ_ASSERT(originAttrsLoadInfo.mUserContextId == 2421 originAttrsLoadContext.mUserContextId, 2422 "The value of mUserContextId in the loadContext and in the " 2423 "loadInfo are not the same!"); Looks like this is only affecting m-c at the moment. I couldn't reproduce the assertion using the latest m-a changeset (changeset: d9fdbad8f079) with debugging enabled.
We need to get this fixed before merge. Or uplift if we don't.
Dave or Yoshi, which user context id is right? The loadinfo one or the loadcontext one?
Flags: needinfo?(huseby)
Flags: needinfo?(allstars.chh)
If it is needed, we can remove the check in aurora or before getting to aurora. It will be an easy patch and also acceptable to uplift - just comment out to calls to the NS_CompareLoadInfoAndLoadContext function.
(In reply to Tanvi Vyas [:tanvi] from comment #6) > Dave or Yoshi, which user context id is right? The loadinfo one or the > loadcontext one? LoadInfo is wrong, and LoadContext is correct. > NewChannelFromURIWithProxyFlagsInternal spec=about:newtab > NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/content/newtab/newTab.xhtml > NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/browser/content/browser/newtab/newTab.xhtml > NS_CompareLoadInfoAndLoadContext - spec =file:///home/allstars/ssd/gecko-dev/browser/base/content/newtab/newTab.xhtml loadInfo: 0, 0, 1, 0; loadContext: 0 0, 1, 0. [channel=0x7f776b10d9b0] > newTab.xhtml loads with correct loadInfo 0, 0, 1, 0 which 1 is the userContextId > NewChannelFromURIWithProxyFlagsInternal spec=about:blank > ++DOMWINDOW == 22 (0x7f774d893c00) [pid = 12705] [serial = 22] [outer = 0x7f774d894c00] > NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/locale/newTab.dtd > NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/en-US/locale/browser/newTab.dtd > NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/locale/browser.dtd > NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/en-US/locale/browser/browser.dtd > NewChannelFromURIWithProxyFlagsInternal spec=chrome://global/locale/global.dtd > NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/chrome/en-US/locale/en-US/global/global.dtd > [Main Thread]: D/nsCSSLoader css::Loader::LoadStyleLink > [Main Thread]: D/nsCSSLoader Link uri: 'chrome://global/skin/global.css' > [Main Thread]: D/nsCSSLoader Link title: '' > [Main Thread]: D/nsCSSLoader Link media: 'all' > [Main Thread]: D/nsCSSLoader Link alternate rel: 0 > [Main Thread]: D/nsCSSLoader css::Loader::CreateSheet > [Main Thread]: D/nsCSSLoader From XUL cache: 7f776700e780 > [Main Thread]: D/nsCSSLoader State: eSheetComplete > [Main Thread]: D/nsCSSLoader Sheet is alternate: 0 > [Main Thread]: D/nsCSSLoader css::Loader::InsertSheetInDoc > [Main Thread]: D/nsCSSLoader Inserting into document at position 0 > [Main Thread]: D/nsCSSLoader Sheet already complete: 0x7f774d75e3c0 > [Main Thread]: D/nsCSSLoader css::Loader::PostLoadEvent > [Main Thread]: D/nsCSSLoader css::Loader::LoadStyleLink > [Main Thread]: D/nsCSSLoader Link uri: 'chrome://browser/content/contentSearchUI.css' > [Main Thread]: D/nsCSSLoader Link title: '' > [Main Thread]: D/nsCSSLoader Link media: 'all' > [Main Thread]: D/nsCSSLoader Link alternate rel: 0 > [Main Thread]: D/nsCSSLoader css::Loader::CreateSheet > [Main Thread]: D/nsCSSLoader From XUL cache: 0 > [Main Thread]: D/nsCSSLoader From completed: 0 > [Main Thread]: D/nsCSSLoader State: eSheetNeedsParser > [Main Thread]: D/nsCSSLoader Sheet is alternate: 0 > [Main Thread]: D/nsCSSLoader css::Loader::InsertSheetInDoc > [Main Thread]: D/nsCSSLoader Inserting into document at position 1 > [Main Thread]: D/nsCSSLoader css::Loader::LoadSheet > [Main Thread]: D/nsCSSLoader Load from: 'chrome://browser/content/contentSearchUI.css' > NewChannelFromURIWithProxyFlagsInternal spec=chrome://browser/content/contentSearchUI.css > NewChannelFromURIWithProxyFlagsInternal spec=file:///home/allstars/ssd/gecko-dev/obj-x86_64-pc-linux-gnu/dist/bin/browser/chrome/browser/content/browser/contentSearchUI.css > NS_CompareLoadInfoAndLoadContext - spec =file:///home/allstars/ssd/gecko-dev/browser/base/content/contentSearchUI.css loadInfo: 0, 0, 0, 0; loadContext: 0 0, 1, 0. [channel=0x7f776b10e810] But when loading CSS file, the loadInfo is wrong. it doesn't have correct userContextId. > Assertion failure: originAttrsLoadInfo.mUserContextId == originAttrsLoadContext.mUserContextId (The value of mUserContextId in the loadContext and in the loadInfo are not the same!), at /home/allstars/ssd/gecko-dev/netwerk/base/nsNetUtil.cpp:2429
Flags: needinfo?(huseby)
Flags: needinfo?(allstars.chh)
So far I found when creating LoadInfo with the CSS file, in the constructor it already has OriginAttributes mismatch between LoadContext and mLoadingPrincipal Bug 1264230 also has the same problem. LoadContext got here has userContextId=1, https://dxr.mozilla.org/mozilla-central/source/netwerk/base/LoadInfo.cpp?from=LoadInfo.cpp#150 but mLoadingPrincipal doesn't have userContextId. https://dxr.mozilla.org/mozilla-central/source/netwerk/base/LoadInfo.cpp?from=LoadInfo.cpp#162 It's strange here as loadContext is from aLoadingContext->OwnerDoc()->GetLoadContext(), and mLoadingPrincipal is from aLoadingContext->NodePrincipal() They both from aLoadingContext, but one has userContextId set, the other is not. Should nsINode have userContextId set? Or is inheriting OriginAttributes from mLoadingPrincipal correct? The other question (maybe unrelated to this) is https://dxr.mozilla.org/mozilla-central/source/netwerk/base/LoadInfo.cpp?from=LoadInfo.cpp#210 Did we get the correct docshell here? as it looks to me we didn't get the correct docshell, so we need to call loadInfo->SetOriginAttributes in nsDocShell.cpp to fix this. Anyway, below is the stack trace when LoadInfo is created I'll check more next week. Breakpoint 2, mozilla::LoadInfo::LoadInfo (this=0x7fffd2b0eac0, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aLoadingContext=0x7fffc6ca6d30, aSecurityFlags=1028, aContentPolicyType=39) at /home/allstars/ssd/gecko-dev/netwerk/base/LoadInfo.cpp:178 178 } (gdb) bt #0 0x00007fffe39dbcfb in mozilla::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, unsigned int) (this=0x7fffd2b0eac0, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aLoadingContext=0x7fffc6ca6d30, aSecurityFlags=1028, aContentPolicyType=39) at /home/allstars/ssd/gecko-dev/netwerk/base/LoadInfo.cpp:178 #1 0x00007fffe3a31086 in nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI*, nsIURI*, unsigned int, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffce6f8300, aProxyURI=0x0, aProxyFlags=0, aLoadingNode=0x7fffc6ca6db0, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, result=0x7fffffffac50) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:905 #2 0x00007fffe3a301ac in nsIOService::NewChannelFromURI2(nsIURI*, nsIDOMNode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsIChannel**) (this=0x7ffff6bacb40, aURI=0x7fffce6f8300, aLoadingNode=0x7fffc6ca6db0, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, result=0x7fffffffac50) at /home/allstars/ssd/gecko-dev/netwerk/base/nsIOService.cpp:673 #3 0x00007fffe3a44ec2 in NS_NewChannelInternal(nsIChannel**, nsIURI*, nsINode*, nsIPrincipal*, nsIPrincipal*, unsigned int, unsigned int, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) (outChannel=0x7fffffffada0, aUri=0x7fffce6f8300, aLoadingNode=0x7fffc6ca6d30, aLoadingPrincipal=0x7fffdf6dae60, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, aLoadGroup=0x7fffd2b2bad0, aCallbacks=0x0, aLoadFlags=4194304, aIoService=0x7ffff6bacb40) at /home/allstars/ssd/gecko-dev/netwerk/base/nsNetUtil.inl:179 #4 0x00007fffe3a45f85 in NS_NewChannelWithTriggeringPrincipal(nsIChannel**, nsIURI*, nsINode*, nsIPrincipal*, unsigned int, unsigned int, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*) (outChannel=0x7fffffffada0, aUri=0x7fffce6f8300, aLoadingNode=0x7fffc6ca6d30, aTriggeringPrincipal=0x7fffdf6dae60, aSecurityFlags=1028, aContentPolicyType=39, aLoadGroup=0x7fffd2b2bad0, aCallbacks=0x0, aLoadFlags=4194304, aIoService=0x0) at /home/allstars/ssd/gecko-dev/netwerk/base/nsNetUtil.cpp:105 #5 0x00007fffe74d50be in mozilla::css::Loader::LoadSheet(mozilla::css::SheetLoadData*, mozilla::css::StyleSheetState, bool) (this=0x7fffc31f0240, aLoadData=0x7fffd2b0ea00, aSheetState=mozilla::css::eSheetNeedsParser, aIsPreload=false) at /home/allstars/ssd/gecko-dev/layout/style/Loader.cpp:1645 #6 0x00007fffe74d819d in mozilla::css::Loader::LoadStyleLink(nsIContent*, nsIURI*, nsAString_internal const&, nsAString_internal const&, bool, mozilla::CORSMode, mozilla::net::ReferrerPolicy, nsAString_internal const&, nsICSSLoaderObserver*, bool*) (this=0x7fffc31f0240, aElement= 0x7fffc6ca6d30, aURL=0x7fffce6f8300, aTitle=..., aMedia=..., aHasAlternateRel=false, aCORSMode=mozilla::CORS_NONE, aReferrerPolicy=mozilla::net::RP_No_Referrer_When_Downgrade, aIntegrity=..., aObserver=0x7fffc6aca000, aIsAlternate=0x7fffffffb112) at /home/allstars/ssd/gecko-dev/layout/style/Loader.cpp:2138 #7 0x00007fffe546a430 in nsStyleLinkElement::DoUpdateStyleSheet(nsIDocument*, mozilla::dom::ShadowRoot*, nsICSSLoaderObserver*, bool*, bool*, bool) (this=0x7fffc6ca6dc8, aOldDocument=0x0, aOldShadowRoot= 0x0, aObserver=0x7fffc6aca000, aWillNotify=0x7fffffffb589, aIsAlternate=0x7fffffffb58a, aForceUpdate=false) at /home/allstars/ssd/gecko-dev/dom/base/nsStyleLinkElement.cpp:448
Continue to my previous Comment 9, So far the LoadInfo/LoadContext mismatched will happen when loading chrome sub-resources, for example, chrome://browser/content/contentSearchUI.css chrome://browser/content/newtab/newTab.css chrome://browser/skin/newtab/newTab.css .... These resources will be loaded by SystemPrincipal, which doesn't have origin attributes, therefore we have a mismatch here So if I inherit the origin attributes from the aLoadingNode->OwnerDoc->GetDocShell, that seems to work, and also it seems fixes other bugs as well, like Bug 1265062, Bug 1264230, and Bug 1264231. (with removing the workaround in dom/html/HTMLMediaElement.cpp and image/imgLoader.cpp from Bug 1125916) But there are still some other problems I need to check as well. 1. When loading an image or SVG in a container tab, its loadingPrincipal doesn't have userContextId, but aLoadingNode->OwnerDoc->GetDocShell have the userContextId. 2. opening about:blank in the container tab, it's the other way around, mLoadingPrincipal has the userContextId set, whereas the aLoadingNode->OwnerDoc->GetDocShell->GetOriginAttributes() is empty, i.e. LoadContext doesn't have origin attributes set. 3. when loading blobs with null principal in the container tab, the mLoadingPrincipal doesn't have origin attributes (base on my Bug 1263496), but LoadContext has the value. Meanwhile, Jonas, can you give me some suggestions here, as you reviewed most part of Bug 1125916 Thanks
Flags: needinfo?(jonas)
These two should be false alarm. (In reply to Yoshi Huang[:allstars.chh] from comment #10) > 2. opening about:blank in the container tab, it's the other way around, > mLoadingPrincipal has the userContextId set, whereas the > aLoadingNode->OwnerDoc->GetDocShell->GetOriginAttributes() is empty, i.e. > LoadContext doesn't have origin attributes set. > It's the CreateDummyChannel from Cookie code > 3. when loading blobs with null principal in the container tab, the > mLoadingPrincipal doesn't have origin attributes (base on my Bug 1263496), > but LoadContext has the value. > It's not Null Principal, it's a blob url. (blob:null/uuid)
Attached patch WIP Patch (obsolete) — Splinter Review
This is the WIP, try to get origin attributes from docshell.
Flags: needinfo?(jonas)
Attachment #8745296 - Flags: feedback?(jonas)
Comment on attachment 8745296 [details] [diff] [review] WIP Patch Review of attachment 8745296 [details] [diff] [review]: ----------------------------------------------------------------- As far as I can tell, this defeats the whole purpose of having the assertion in the first place. This patch reads the information from the loadcontext into the loadinfo, and then we assert that the two are the same. Seems quite obvious that they will be. So we should not land this patch. There's two reasons that we have these assertions: 1. We want to verify that the information in loadinfo is correct. So that code the relies on loadinfo to do security checks doesn't end up doing the wrong thing. 2. Eventually we should stop using information from loadcontext and instead rely on loadinfo everywhere. LoadContext has several problems: * It's received through the docshell, which further overloads the responsibilities that docshell has. * If you want to override the security parameters that a request uses, you have to create a whole new LoadContext, which is non-trivial given how big the LoadContext API is. * Since LoadGroup is retrieved through the LoadGroup, you also have to create a custom loadGroup in addition to the custom LoadContext. * It's very unclear that setting the correct LoadGroup is critical to getting the correct security behavior. I.e. it's very easy to start a network request with the wrong security parameters by using the wrong (or no) loadgroup. * In cases where we want to use a separate LoadGroup (like <a ping> and sendBeacon), we have to jump through extra hoops to not have that result in using the wrong security parameters. Hence we should make sure that we specify the correct information in the LoadInfo *without* relying on LoadContext, so that we can eventually remove LoadContext. Since LoadContext is what is currently used to specify security parameters, it is for the most part correct. The assertions are there to find places where LoadInfo contains different information so that we can check why that is and fix the code so that we have the correct information in LoadInfo. By having LoadInfo read from LoadContext we re-introduce many of the problems mentioned above.
Attachment #8745296 - Flags: feedback?(jonas) → feedback-
Whiteboard: [domsecurity-active] → [domsecurity-active][userContextId]
Attached patch Patch. (obsolete) — Splinter Review
As discussed with Jonas on IRC He suggested that when loading chrome:// sub-resources, it should still use System Principal, hence we should skip the check when loading chrome resources.
Attachment #8745296 - Attachment is obsolete: true
Attachment #8747021 - Flags: review?(jonas)
Looks like this made it into the latest version of aurora: changeset: 318606:2b84f74d99e4 tag: tip fxtree: aurora user: Jordan Lund <jlund@mozilla.com> date: Tue May 03 15:44:18 2016 -0700 summary: Bug 1269911 - beta and release CI builds should clobber per-checkin, DONTBUILD a=testing r=rail Running into the same crash while opening any of the containers via File -> New Container Tab Process 40725 stopped * thread #1: tid = 0xcde44, 0x0000000101e7662a XUL`NS_CompareLoadInfoAndLoadContext(aChannel=<unavailable>) + 1322 at nsNetUtil.cpp:2420, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000101e7662a XUL`NS_CompareLoadInfoAndLoadContext(aChannel=<unavailable>) + 1322 at nsNetUtil.cpp:2420 2417 "The value of InIsolatedMozBrowser in the loadContext and in " 2418 "the loadInfo are not the same!"); 2419 -> 2420 MOZ_ASSERT(originAttrsLoadInfo.mUserContextId == 2421 originAttrsLoadContext.mUserContextId, 2422 "The value of mUserContextId in the loadContext and in the " 2423 "loadInfo are not the same!");
Priority: -- → P1
Whiteboard: [domsecurity-active][userContextId] → [domsecurity-active][userContextId][OA]
Comment on attachment 8747021 [details] [diff] [review] Patch. Review of attachment 8747021 [details] [diff] [review]: ----------------------------------------------------------------- I think we should add a more descriptive checkin comment. Something like "When tab with a userContextId!=0 contains a chrome page (such as about:newtab) the userContextId in the LoadInfo won't match the userContextId in the LoadContext. The LoadInfo will contain the systemPrincipal and so use userContextId=0, the LoadContext has the userContextId of the tab (!=0). This is fine as long as we page only loads chrome-URLs and other non-http URLs since those don't use cookies anyway. So avoid asserting in this situation. Long term we want the chrome page to use the default userContextId for cookies, since that's what it chrome code normally use. This will work properly once we get the cookie jar information from the LoadInfo rather than from the LoadContext."
Attachment #8747021 - Flags: review?(jonas) → review+
Attached patch Patch. v2Splinter Review
added commit message
Attachment #8747021 - Attachment is obsolete: true
Attachment #8749132 - Flags: review+
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Blocks: 1266067
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: