1818950 - Conversations add-on can't separate remote content notifications for different messages in the same window

Status: RESOLVED FIXED

(MailNews Core :: General, defect)

Description

[Mark Banner (:standard8)]

Conversations can display multiple messages in the message pane. It does this by loading a message list structure in a browser element, and then using content iframes to display the actual messages.

In bug 1799764, the handling for the remote content policy blocked notifications was changed.

The new way of notifying uses the observer service and passes two pieces of information - the URI of the content that was blocked, and the browsing context id of the element that triggered the load.

In Conversations' case, the element is the original browser element, rather than that of the content iframes. Hence Conversations is no longer able to determine which message has triggered the remote content blocked notification.

I think there's a few possibilities to fix this:

1. Change the notification to use the browsing context id of the actual browser/iframe that was blocked.
2. Rather than passing the blocked URI (which doesn't get used), pass the message URI like the original notification did.
3. Change the structure of the code, so that the blocked notification is passed back to a listener that is registered when DisplayMessage is called.

The last option would likely be the best from the architecture point of view - a listener would be registered when displaying a message and that one would be the only one to get notified. You don't have to listen to global notifications and then figure out if it is yours or not.

However, the last option would also likely be a lot more work.

I think the second option would probably be good enough from Conversations' perspective, though the first or last options would be preferable overall.

Comment 1

[Geoff Lankow (:darktrojan)]

Change the notification to use the browsing context id of the actual browser/iframe that was blocked.

This was the original design, but I changed it to use the top frame because blocked content in iframes wasn't causing the notification. We could fix that another way.

Rather than passing the blocked URI (which doesn't get used), pass the message URI like the original notification did.

It does get used, to give a list of content that can be allowed. Or it should do, it looks like it's a bit broken at the moment.

Comment 2

[Thomas D. (:thomas8)]

Updating whiteboard to [supernova3p]. 20230424_2303

Comment 3

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1818950 - Use the original BrowsingContext ID in `remote-content-blocked` notification. r=Standard8,#thunderbird-reviewers

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/478c05f7fd3b
Use the original BrowsingContext ID in remote-content-blocked notification. r=Standard8

Comment 5

[Wayne Mery (:wsmwk)]

Comment on attachment 9332991 [details]
Bug 1818950 - Use the original BrowsingContext ID in remote-content-blocked notification. r=Standard8,#thunderbird-reviewers

[Triage Comment]
Approved for beta

Comment 6

[Daniel Darnell [:dandarnell]]

Thunderbird 114.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/3fa509d907d0