245360 - show border / blocked image icon (like broken image icon) when an image is blocked.

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[(not reading, please use [e-mail] instead)]

show border / blocked image icon (like broken image icon) when an image is blocked.

Comment 1

[Scott MacGregor]

This will be an important part of our blocking remote content feature. 

Right now we don't show any border or a blocked image icon when layout blocks an
image. This makes sense for the browser. When blocking an image from a page you
don't want to see where the image was on the page. The idea is to layout the
page without this image.

However, for a "blocked remote content view" in mail, we are going to want a
view that looks similar to the way broken images are presented.

Currently, 
http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsImageFrame.cpp#425
nsImageFrame::HandleLoadError returns right away for the blocked image case.

One way to fix this is to create a return value for the content policy manager
to return besides just nsIContentPolicy::REJECT_REQUEST which gives a hint to
the image frame as to how to render the requested object.

Another possibility is to make HandleLoadError check for a custom blocked image
style similar to what we use for broken images: -moz-force-broken-image-icon. 

cc'ing Boris for suggestions and discussion.

For a screen shot of Outlooks' blocked image view see: 
http://bugzilla.mozilla.org/attachment.cgi?id=144800&action=view

Comment 2

[Boris Zbarsky [:bzbarsky]]

> One way to fix this is to create a return value for the content policy manager
> to return besides just nsIContentPolicy::REJECT_REQUEST which gives a hint to
> the image frame as to how to render the requested object.

Actually, REJECT_REQUEST should show the placeholder.  REJECT_TYPE should not. 
That's not been implemented yet.  See bug 11011 and various dependencies (in
particular bug 41924

Comment 3

[Scott MacGregor]

(In reply to comment #2)
> Actually, REJECT_REQUEST should show the placeholder.  REJECT_TYPE should not. 
> That's not been implemented yet.  See bug 11011 and various dependencies (in
> particular bug 41924

Hmm, that's interesting, if I understand you right, you think this may already
be working and I may just be calling something incorrectly. So the mailnews
content policy manager returns nsIContentPolicy::REJECT_REQUEST for remote
images. This values trickles back to nsContentUtils::CanLoadImage which returns
PR_FALSE based on the decision value.
Which then falls back to:

nsImageLoadingContent::ImageURIChanged which turns the boolean into
NS_ERROR_IMAGE_BLOCKED. Which then calls
nsImageLoadingContent::CancelImageRequests with NS_ERROR_IMAGE_BLOCKED. But we
don't have an image request yet so there aren't any requests to cancel. 

time passes then we come into nsImageFrame::Init which asks the image loader if
the image is blocked which it is. We now call HandleLoadError with a value of
NS_ERROR_IMAGE_BLOCKED. HandleLoadError looks like this at the beginning:

  if (aStatus == NS_ERROR_IMAGE_BLOCKED &&
      !(gIconLoad && gIconLoad->mPrefAllImagesBlocked)) {
    // don't display any alt feedback in this case; we're blocking images
    // from that site and don't care to see anything from them
    return NS_OK;
  }

mPrefAllImagesBlocked is 0. gIconLoad is valid icon request. So we end up
hitting this return and the blocked/broken icon is not shown.

That's what I am seeing when I return REJECT_REQUEST.

I'll keep digging.

Comment 4

[Scott MacGregor]

could this be as easy as changing the pref value for:

 pref("network.image.imageBehavior", 0); // 0-Accept, 1-dontAcceptForeign, 2-dontUse

which controls  gIconLoad->mPrefAllImagesBlocked?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> if I understand you right, you think this may already be working and I may just
> be calling something incorrectly.

No... I would _like_ this to be working, and that's why the
REJECT_REQUEST/REJECT_TYPE difference was implemented.  But code in layout to
make use of that difference hasn't been written yet.

The utlimate goal is to remove that pref check in nsImageFrame.  That pref
should only be read by nsImgManager.

Comment 6

[Boris Zbarsky [:bzbarsky]]

And that pref is global, so changing it will affect all images, period.  That
may not be an issue for thunderbird, perhaps, but we need to fix the general
arch issue no matter what.

Comment 7

[Scott MacGregor]

marking fixed, this pref does waht I need. Fixed on the branch and trunk.