Opening an about: page from a web content page produces warnings and IPDL errors
Categories
(Core :: DOM: Service Workers, defect)
Tracking
()
People
(Reporter: tjr, Assigned: edenchuang)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
You can't open any about: pages (that I have found) from a web content page except about:blank and about:logo. The latter breaks an assumption and causes an error.
STR:
- Make a debug build.
- Go to https://ritter.vg/misc/ff/about.html
- Open about:logo in a new tab
Warnings:
[Parent 917050, IPDL Background] WARNING: '!ClientIsValidPrincipalInfo(aClientInfo.principalInfo())', file /home/tom/Documents/moz/mozilla-unified-2/dom/clients/manager/ClientManagerParent.cpp:112
IPDL protocol error: Handler returned error code!
###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)
[Parent 917050, IPDL Background] WARNING: '!ClientIsValidPrincipalInfo(aClientInfo.principalInfo())', file /home/tom/Documents/moz/mozilla-unified-2/dom/clients/manager/ClientManagerParent.cpp:124
IPDL protocol error: Handler returned error code!
###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ForgetFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)
[Parent 917050, Main Thread] WARNING: '!ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo())', file /home/tom/Documents/moz/mozilla-unified-2/dom/clients/manager/ClientSource.cpp:183
Comment 1•3 years ago
|
||
To be clear, the about: pages can be opened, it's 'just' that those warnings and errors are emitted. Reproduced on Ubuntu 20.04. I guess this is not a recent regression.
Comment 2•3 years ago
|
||
My guess above might've been wrong. The first warning was added recently in bug 1584007.
Eden: does the warning require any changes in DOM : Services Workers code? I'm not familiar with this code and don't know whether DOM : Core & HTML is the correct component for this ticket.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
It would be a regression caused by bug 1584007. Will fix it.
Assignee | ||
Comment 4•3 years ago
|
||
After running with the newest nightly build, the original warning message disappeared.
However, new warning messages show out as following
[Parent 66015, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4 (NS_ERROR_DOM_BAD_URI): file /Users/echuang/Firefox/mozilla-central/dom/security/nsContentSecurityManager.cpp:1291
[Parent 66015, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4 (NS_ERROR_DOM_BAD_URI): file /Users/echuang/Firefox/mozilla-central/dom/security/nsContentSecurityManager.cpp:1148
[Parent 66015, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4 (NS_ERROR_DOM_BAD_URI): file /Users/echuang/Firefox/mozilla-central/docshell/base/nsDocShell.cpp:10664
[Parent 66015, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4 (NS_ERROR_DOM_BAD_URI): file /Users/echuang/Firefox/mozilla-central/docshell/base/nsDocShell.cpp:888
And this blocks the page loading.
Changing the bug component back to DOM: Core & HTML.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
NS_ERROR_DOM_BAD_URI comes from https://searchfox.org/mozilla-central/rev/2c991232499e826e46f9d976eb653817340ba389/caps/nsScriptSecurityManager.cpp#869-877. It wants to make sure the target URI has no URI_DANGEROUS_TO_LOAD flag.
However, https://searchfox.org/mozilla-central/source/netwerk/protocol/about/nsAboutProtocolHandler.cpp#82-87 is called to get the protocol flags for checking for about::xxx URIs. And URI_DANGEROUS_TO_LOAD flag is set, so the loading is blocked.
Mirko I guess you understand this better than me. Would you like to take a look at it?
Assignee | ||
Updated•3 years ago
|
Comment 6•3 years ago
|
||
Eden: just rebased my Gecko tree and the warning is still emitted:
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
[Parent 54921, Main Thread] WARNING: '!wc', file /home/mirko/src/firefox/gecko2/dom/base/ThirdPartyUtil.cpp:226
[Parent 54921, Main Thread] WARNING: '!wc', file /home/mirko/src/firefox/gecko2/dom/base/ThirdPartyUtil.cpp:226
[Parent 54921, Main Thread] WARNING: '!wc', file /home/mirko/src/firefox/gecko2/dom/base/ThirdPartyUtil.cpp:226
[Parent 54921, IPDL Background] WARNING: '!ClientIsValidPrincipalInfo(aClientInfo.principalInfo())', file /home/mirko/src/firefox/gecko2/dom/clients/manager/ClientManagerParent.cpp:112
IPDL protocol error: Handler returned error code!
###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)
[Parent 54921, IPDL Background] WARNING: '!ClientIsValidPrincipalInfo(aClientInfo.principalInfo())', file /home/mirko/src/firefox/gecko2/dom/clients/manager/ClientManagerParent.cpp:124
IPDL protocol error: Handler returned error code!
###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ForgetFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)
However, it's preceded by this warning.
baku: can you please shed some light on this? It seems that warning is related to its following warnings.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Eden: since the newly added warning still occurs, you might want to have a look again, too.
Comment 8•3 years ago
|
||
One of the call-sites Eden links to in comment 4 is nsDocShell::OpenInitializedChannel where it appears that:
- We've added a ClientChannelHelper just above before the check that will return NS_ERROR_DOM_BAD_URI.
This makes sense to explain why ClientChannelHelper could be hearing about the principal which later gets mooted. And it does suggest this needs to be addressed unless we change the order of operations there which it's not clear would make sense in the success case.
But it does seem like the validation logic for the principal is unhappy. We do have some MozURL tests that cover about: scheme origins but maybe I'm missing something. :janv might have some thoughts, cc'ing him.
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Tim, it doesn't seem urgent, but could you take a look at this warning related to third party checks?
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Different warning, these days?
[Child 114769, Main Thread] WARNING: NS_ENSURE_TRUE(info) failed: file extensions/permissions/PermissionDelegateHandler.cpp:348
[Parent 114514, Main Thread] WARNING: '!ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo())', file /dom/clients/manager/ClientSource.cpp:183
[Parent 114514, Main Thread] WARNING: 'aOwner->IsDiscarded()', file obj-x86_64-pc-linux-gnu/dist/include/mozilla/dom/SyncedContextInlines.h:94
Comment 11•3 years ago
|
||
Everytime we get the !ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo()) warning we should be shutting down the child process, so how does this even work?
if (NS_WARN_IF(!ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo()))) {
mService->ForgetFutureSource(mClientInfo.ToIPC());
KillInvalidChild();
return;
}
The child version is similar, except Shutdown() instead of KillInValidChild(). So it's checking this at one point, and then at a later point it opens the document anyway?
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 12•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 13•3 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #11)
Everytime we get the !ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo()) warning we should be shutting down the child process, so how does this even work?
if (NS_WARN_IF(!ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo()))) { mService->ForgetFutureSource(mClientInfo.ToIPC()); KillInvalidChild(); return; }
The child version is similar, except Shutdown() instead of KillInValidChild(). So it's checking this at one point, and then at a later point it opens the document anyway?
Currently, the warning message is from https://searchfox.org/mozilla-central/rev/980b50947e2a855c92f2df74209dadad3ee4d119/dom/clients/manager/ClientSource.cpp#183
However, the ClientSource::Shotdown() would not close the content process. It just closes the corresponding Client related things.
That is the reason why we still see the document is loaded.
Comment 14•3 years ago
|
||
The severity field is not set for this bug.
:jesup, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Comment 15•3 years ago
|
||
Comment 16•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Description
•