The root cause of this bug is that when opening the devtools (`about:devtools-toolbox`), the about page may also embed a 3rd-party frame with chrome URL, ex, chrome://devtools/content/debugger/index.html. Although the frame has system privilege and it is not a tracker, we may still deny the storage access permission when setting cookiebehavior to **REJCET ALL**, which trigger the `MOZ_ASSERT` [here](https://searchfox.org/mozilla-central/rev/9c6e7500c0015a2c60be7b1b888261d95095ce27/toolkit/components/antitracking/ContentBlockingNotifier.cpp#) that asserts while notifying blocking events for windows with system principal). baku, steven, I would like to check with you do you think we should always allow storage permission for system privileged windows no matter what cookiebehavior is set? or we should respect cookiebehavior for system content. If the latter case is the case we want, the solution for this bug will be not notifying content blocking events when we block storage access for system content, because no UX requires that info.
Bug 1623044 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The root cause of this bug is that when opening the devtools (`about:devtools-toolbox`), the about page may also embed a 3rd-party frame with chrome URL, ex, chrome://devtools/content/debugger/index.html. Although the frame has system privilege and it is not a tracker, we may still deny the storage access permission when setting cookiebehavior to *REJCET ALL*, which trigger the `MOZ_ASSERT` [here](https://searchfox.org/mozilla-central/rev/9c6e7500c0015a2c60be7b1b888261d95095ce27/toolkit/components/antitracking/ContentBlockingNotifier.cpp#) that asserts while notifying blocking events for windows with system principal). baku, steven, I would like to check with you do you think we should always allow storage permission for system privileged windows no matter what cookiebehavior is set? or we should respect cookiebehavior for system content. If the latter case is the case we want, the solution for this bug will be not notifying content blocking events when we block storage access for system content, because no UX requires that info.
The root cause of this bug is that when opening the devtools (`about:devtools-toolbox`), the about page may also embed a 3rd-party frame with chrome URL, ex, chrome://devtools/content/debugger/index.html. Although the frame has system privilege and it is not a tracker, we may still deny the storage access permission when setting cookiebehavior to *REJCET ALL*, which trigger the `MOZ_ASSERT` [here](https://searchfox.org/mozilla-central/rev/9c6e7500c0015a2c60be7b1b888261d95095ce27/toolkit/components/antitracking/ContentBlockingNotifier.cpp#) that asserts while notifying blocking events for windows with system principal. baku, steven, I would like to check with you do you think we should always allow storage permission for system privileged windows no matter what cookiebehavior is set? or we should respect cookiebehavior for system content. If the latter case is the case we want, the solution for this bug will be not notifying content blocking events when we block storage access for system content, because no UX requires that info.