Closed
Bug 202906
Opened 21 years ago
Closed 19 years ago
[FIX]"Load images from originating server only" does not show alt text
Categories
(Core :: Layout: Images, Video, and HTML Frames, enhancement, P1)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
Details
Attachments
(1 file, 1 obsolete file)
27.33 KB,
patch
|
mvl
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
This is just broken -- we fail to replace the image frame and fail to show the alt text.
This should have nothing to do with ContentPolicy (the dependency on bug 201885). I put forth that any failure to load the image, caused by anything (OOM, ConPol rejection, or anything else) should result in the alt text being displayed. I'm not going to remove the dependency, but I strongly suggest it be removed.
http://lxr.mozilla.org/seamonkey/search?string=nsIContentPolicy::IMAGE http://lxr.mozilla.org/seamonkey/source/content/base/src/nsImageLoadingContent.cpp#545 The above point to where the fix to this could easily go. Just separate the !shouldLoad case.
Alternately, if you really want to make content policy's decision about an image to affect alt-text-showing, I suggest you use the |extra| parameter I am providing to accomplish that (how you do that is not my concern).
Assignee | ||
Comment 4•21 years ago
|
||
This has everything to do with content policy, because there are two reasons that an image load may be blocked: 1) All image loads are blocked 2) This particular site is not allowed to load images The alt text behavior should be different for those cases. Hence the dependecy on bug 201885. Note that the core gecko image loading code cannot encode ANY knowledge of any content policy implementations -- if it's not in the content policy API, it's not usable from this code. As in, the "extra" parameter is completely useless here.
I disagree that those two cases should be different, but I'll see if there is some way to facilitate you here. What other cases could/does anything else care about why a request was rejected? Perhaps this discussion should continue in bug 201885, since that's closer to my work.
Assignee | ||
Comment 6•21 years ago
|
||
Let's just keep it all in bug 191839
Comment 7•20 years ago
|
||
"Do not load any images" also seems to have this problem.
Severity: normal → enhancement
Assignee | ||
Comment 8•20 years ago
|
||
Not really tested yet...
Assignee | ||
Comment 9•20 years ago
|
||
I tested this, and it works and all.. mvl, does the setup (only show alt text for images blocked by type) seem reasonable?
Assignee: jdunn → bzbarsky
Attachment #173790 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #174769 -
Flags: superreview?(jst)
Attachment #174769 -
Flags: review?(mvl)
Assignee | ||
Updated•20 years ago
|
Priority: -- → P1
Summary: "Load images from originating server only" does not show alt text → [FIX]"Load images from originating server only" does not show alt text
Target Milestone: --- → mozilla1.8beta2
Comment 10•19 years ago
|
||
I can think of two reasons to block images: faster loading or not wanting ads. The first user will disable image loading in prefs, but does want alt text, to at least know something about the images. (Alt is in html, so loaded anyway. Showing it doesn't block the goal). The other will block images based on host, and doesn't want the alternative text, which is likely an ad also. So the setup sounds right to me.
Assignee | ||
Comment 11•19 years ago
|
||
OK. In that case, wanna review? ;)
Comment 12•19 years ago
|
||
Comment on attachment 174769 [details] [diff] [review] Merged to trunk >Index: content/base/public/nsContentUtils.h >+ * @param aImageBlockingStatus the nsIContentPolicy blocking status for this >+ * image. This will be set even if a security check fails for the >+ * image, to some reasonable REJECT_* value. This out param will only >+ * be set if it's non-null. > * @return PR_TRUE if the load can proceed, or PR_FALSE if it is blocked It might be worth it noticing that the return value is a subset of aImageBlockingStatus, so they are not independant. >Index: content/base/src/nsImageLoadingContent.h >+ * @param aNewImageStatus the nsIContentPolicy status of the new image (I don't really know this code, just from looking at this file:) what is 'the new image'? Does a new image get created if a load is cancelled? >Index: layout/generic/nsImageFrame.h You can remove mPrefAllImagesBlocked from this file, right? It isn't used anymore. (at least, it is never set anymore, so i really hope nothing reads it anymore :) ) r=mvl
Attachment #174769 -
Flags: review?(mvl) → review+
Assignee | ||
Comment 13•19 years ago
|
||
> what is 'the new image'? The cancel method is called when the src of an image changes; the new image is the image the new src points to. > You can remove mPrefAllImagesBlocked from this file, right? Yep. Good catch. jst, assume I added comments for the first two review comments from mvl and fixed the third one, ok?
Comment 14•19 years ago
|
||
Comment on attachment 174769 [details] [diff] [review] Merged to trunk Yeah, and you probably want to change the IID in nsIImageLoadingContent.idl since you're changing the signature of a method... sr=jst
Attachment #174769 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Comment 15•19 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•