Explanation I posts on Bug 1637493: The issue is that the docShell customUserAgent changes are kinda midway through refactoring. The property was moved from nsDocShell to BrowsingContext and then the callers to docShell.customUserAgent = were updated to docShell.browsingContext.customUserAgent =. This means that the setting still happens from the Content process. BrowsingContext is split across Content/Parent; the setting from Content is forwarded to the Parent. There's a test on the Content side to determine if it's OK to send and a check in the Parent side to also. In Bug 1633459, the assert in firing in the Parent because a change is being made after the BrowsingContext has changed process and the sender is no longer allowed to set the override. (The Content side thought it was OK to send). I put the IDL attribute back into nsIDocShell so I can reject setting the override if the doc shell knows it's losing rights to change it's BrowsingContext (The check to mWillProcessChange). This is just an interim fix to stop the assert until we can update all the uses of .customUserAgent = ... to originate from the Parent process, which always has rights to set the property on a BrowsingContext.
Bug 1633459 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Explanation I posted on Bug 1637493: The issue is that the docShell customUserAgent changes are kinda midway through refactoring. The property was moved from nsDocShell to BrowsingContext and then the callers to docShell.customUserAgent = were updated to docShell.browsingContext.customUserAgent =. This means that the setting still happens from the Content process. BrowsingContext is split across Content/Parent; the setting from Content is forwarded to the Parent. There's a test on the Content side to determine if it's OK to send and a check in the Parent side to also. In Bug 1633459, the assert in firing in the Parent because a change is being made after the BrowsingContext has changed process and the sender is no longer allowed to set the override. (The Content side thought it was OK to send). I put the IDL attribute back into nsIDocShell so I can reject setting the override if the doc shell knows it's losing rights to change it's BrowsingContext (The check to mWillProcessChange). This is just an interim fix to stop the assert until we can update all the uses of .customUserAgent = ... to originate from the Parent process, which always has rights to set the property on a BrowsingContext.