(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #4) > Ok, so maybe you can explain the changes of your patch on bug 1633459, which reverts it from using the browsing context to docshell? Is it just because the setting happens in content instead of the parent process and which causes crashes? 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 1637493 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #4) > Ok, so maybe you can explain the changes of your patch on bug 1633459, which reverts it from using the browsing context to docshell? Is it just because the setting happens in content instead of the parent process and which causes crashes? 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 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`.