Fall out from the changes in Bug #357321 it is not possible to load remote images in news. They get blocked and the usual remote content blocker UI fails to appear. I know this doesn't give Joe exactly what he wants (he wants to always load remote images for news), but it restores the intended design behavior of giving UI for allowing remote images.

Does this mean bug 367372 is invalid? It claims that remote content *cannot* be blocked in news. I haven't tried to test any of this...

The nIMessageURI::GetURI implementation in nsNnntpUrl uses the url spec as the rdf resource uri for the message. The remote content policy manager attempts to get the hdr for the url object, such that DecomposeNewsMessageURI ends up trying to break apart a url spec when it thinks it is getting a resource uri. This failure prevents the remote content UI from appearing. Thus you can't choose to load remote content for that article for that sender. This approach does a couple things: 1) When constructing a nntp url in ConstructNntpUrl, set the message uri with the actual rdf resource URI instead of the url spec. Note: if originalMessageUri is null, then nsNntpUrl::GetURI falls back to returning the url spec anyway. 2) When cloning a news url, be sure to copy over the rdf uri attribute.

Thanks Scott, The danger there was that a casual newsgroup viewer would conclude the TB was not capable of rendering the content. Will test in tomorrows builds.

confirmed fixed in today's trunk and branch.

thanks Joe.