Closed
Bug 1266022
Opened 9 years ago
Closed 9 years ago
Assertion failure: originAttrsLoadInfo.mUserContextId == originAttrsLoadContext.mUserContextId
Categories
(Core :: DOM: Security, defect, P1)
Core
DOM: Security
Tracking
()
RESOLVED
FIXED
mozilla49
People
(Reporter: allstars.chh, Assigned: allstars.chh)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-active][userContextId][OA])
Attachments
(1 file, 2 obsolete files)
4.52 KB,
patch
|
allstars.chh
:
review+
|
Details | Diff | Splinter Review |
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
Updated•9 years ago
|
Whiteboard: [domsecurity-active]
Comment 1•9 years ago
|
||
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)
Assignee | ||
Comment 2•9 years ago
|
||
(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.
Assignee | ||
Comment 3•9 years ago
|
||
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
Comment 4•9 years ago
|
||
(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.
Comment 5•9 years ago
|
||
We need to get this fixed before merge. Or uplift if we don't.
Comment 6•9 years ago
|
||
Dave or Yoshi, which user context id is right? The loadinfo one or the loadcontext one?
Flags: needinfo?(huseby)
Flags: needinfo?(allstars.chh)
Comment 7•9 years ago
|
||
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.
Assignee | ||
Comment 8•9 years ago
|
||
(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)
Assignee | ||
Comment 9•9 years ago
|
||
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
Assignee | ||
Comment 10•9 years ago
|
||
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)
Assignee | ||
Comment 11•9 years ago
|
||
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)
Assignee | ||
Comment 12•9 years ago
|
||
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-
Updated•9 years ago
|
Whiteboard: [domsecurity-active] → [domsecurity-active][userContextId]
Assignee | ||
Comment 14•9 years ago
|
||
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)
Comment 15•9 years ago
|
||
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!");
Updated•9 years ago
|
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+
Assignee | ||
Comment 17•9 years ago
|
||
added commit message
Attachment #8747021 -
Attachment is obsolete: true
Attachment #8749132 -
Flags: review+
Updated•9 years ago
|
Status: NEW → ASSIGNED
Comment 18•9 years ago
|
||
Comment 19•9 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Blocks: 1270998
You need to log in
before you can comment on or make changes to this bug.
Description
•