since there's "Block Image from Loading," why not also add "View Blocked Image" to the context menu? the only way to do this would be to go to Preferences > Advanced > Cookies and Images > View Blocked Images. would this be problematic since View Blocked Images (as it is now) is in the Cookie management dialog? eli, german, your thoughts?

There already is a "View Image" entry in the context menu.

was prolly unclear in my explanation/request... selecting View Image from the context menu will not display an image which has previously been blocked. here are steps to illustrate: 0. you'll need to use a build that's 2000.03.30.xx or earlier --otherwise you run into bug 34079. 1. go to the above URL. 2. over the banner at the top of the page, bring up the context menu. 3. from the context menu, select Block Image from Loading. 4. reload the page. note that banner's no longer there (black box instead), which is expected. 5. bring up context menu over banner area --note that Block Image from Loading is still active (shouldn't it be greyed out?). 6. select View Image. result: a new browser window opens, which is *blank* --mainly since it still thinks the image is blocked. another question, perhaps another bug: in step 5, why isn't Black Image from Loading greyed out over an already-blocked image?

I hope you are not thinking that the context menu item "View Image" is the opposite of the recently added "Block Image". It's not. Let me explain. "View Image" has been there all along. It's purpose is to view the selected image on a separate page. That's why you see a new page open up when you click on it. "Block Image" is the new feature whereby you can block an image from loading on the current page. Of course you have to do a reload before you can see the effect of "Block Image". So pressing "View Image" will always open up a new window. And, in the case that you have previously indicated that you want the image to be blocked, then nothing appears in that new window. This is by design. However, I do concede that it is strange to get an empty page when you said that you want to view an image. So I'm going to special case "View Image" as follows -- any time a page is just an image itself, the image will always load. I have the fix in hand and will check it in as soon as the tree opens. Now, regarding step 5, that's a separate issue. If you feel that it should be grayed out, then open a separate bug on it.

thanks for info, steve. spun off bug 34499 for step 5 above.

Fix checked in. File affected was if.cpp

unable to verify until 34079 is fixed.

[pardon the morphing] i've updated the summary to reflect what the applied fix was for. verified using opt comm bits on linux, winNT and macOS, 2000.04.13.10/09-m16. when an image is blocked (not viewable), i can still view it when i 1. move the mouse over to where the image used to be (black block now). 2. bring up context menu. 3. select View Image result: another browser window appears, displaying the actual image.

whoops, this has regressed --using today's builds, 2000.06.06.08 (opt commercial --i removed the imageblocking pref in all-ns.js).

This one's pretty serious -- it crashes! Furthermore, it's unpredictable. If you view any other image and then view the blocked image, it displays properly. If the blocked image is the first one viewed, I have had each of the following results: 1. Assertion failure followed by crash 2. Crash with no assertion failure 2. Loads normally I was loading altavista.com and was blocking the doubleclick image at the top of the page STACKTRACE AT ASSERTION FAILURE: NTDLL! 77f76274() nsDebug::Assertion(const char * 0x00366180, const char * 0x00366148, const char * 0x00366120, int 1183) line 242 + 13 bytes nsDebug::WarnIfFalse(const char * 0x00366180, const char * 0x00366148, const char * 0x00366120, int 1183) line 300 + 21 bytes nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x034b7dfc, nsIDocumentLoader * 0x034b7220, nsIChannel * 0x03515e30, unsigned int 2152398850) line 1183 + 98 bytes nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x034b7220, nsIChannel * 0x03515e30, unsigned int 2152398850) line 712 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 2152398850) line 542 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x034b7224, nsIChannel * 0x03515e30, nsISupports * 0x00000000, unsigned int 2152398850, const unsigned short * 0x00000000) line 485 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x034b71c0, nsIChannel * 0x03515e30, nsISupports * 0x00000000, unsigned int 2152398850, const unsigned short * 0x00000000) line 544 + 39 bytes nsLoadGroup::Cancel(nsLoadGroup * const 0x034b71c0, unsigned int 2152398850) line 225 nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x034b7220) line 246 + 31 bytes nsURILoader::Stop(nsURILoader * const 0x010ea720, nsISupports * 0x034b7238) line 581 + 23 bytes nsDocShell::StopLoad(nsDocShell * const 0x034b7ce0) line 241 nsDocShell::StopCurrentLoads(nsDocShell * const 0x034b7ce0) line 2712 nsDocShell::InternalLoad(nsDocShell * const 0x034b7ce0, nsIURI * 0x03516270, nsIURI * 0x00000000, const char * 0x00000000, nsIInputStream * 0x00000000, nsDocShell::loadType loadNormal) line 2372 + 15 bytes nsDocShell::LoadURI(nsDocShell * const 0x034b7ce0, nsIURI * 0x03516270, nsIDocShellLoadInfo * 0x00000000) line 218 + 64 bytes nsDocShell::LoadURI(nsDocShell * const 0x034b7cec, const unsigned short * 0x035163f0) line 1078 + 27 bytes XPTC_InvokeByIndex(nsISupports * 0x034b7cec, unsigned int 7, unsigned int 1, nsXPTCVariant * 0x0012e274) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x0335a1f0, nsXPCWrappedNative * 0x03516d30, const XPCNativeMemberDescriptor * 0x03515274, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 0x0267cf78, long * 0x0012e424) line 914 + 43 bytes WrappedNative_CallMethod(JSContext * 0x0335a1f0, JSObject * 0x027110d0, unsigned int 1, long * 0x0267cf78, long * 0x0012e424) line 200 + 34 bytes js_Invoke(JSContext * 0x0335a1f0, unsigned int 1, unsigned int 0) line 686 + 23 bytes js_Interpret(JSContext * 0x0335a1f0, long * 0x0012ed60) line 2487 + 15 bytes js_Invoke(JSContext * 0x0335a1f0, unsigned int 1, unsigned int 2) line 702 + 13 bytes js_InternalInvoke(JSContext * 0x0335a1f0, JSObject * 0x02686150, long 40443872, unsigned int 0, unsigned int 1, long * 0x0012eef8, long * 0x0012ee98) line 775 + 19 bytes JS_CallFunctionValue(JSContext * 0x0335a1f0, JSObject * 0x02686150, long 40443872, unsigned int 1, long * 0x0012eef8, long * 0x0012ee98) line 2801 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x0335a740, void * 0x02686150, void * 0x02691fe0, unsigned int 1, void * 0x0012eef8, int * 0x0012eef4, int 0) line 788 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03512fb4) line 154 + 64 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03464320, nsIDOMEvent * 0x03512fb4, nsIDOMEventTarget * 0x0335a7b0, unsigned int 1, unsigned int 7) line 754 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x033e7ad0, nsEvent * 0x0012fa30, nsIDOMEvent * * 0x0012f3d0, nsIDOMEventTarget * 0x0335a7b0, unsigned int 7, nsEventStatus * 0x0012fa70) line 1323 + 39 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0335a7a0, nsIPresContext * 0x033e7ad0, nsEvent * 0x0012fa30, nsIDOMEvent * * 0x0012f3d0, unsigned int 1, nsEventStatus * 0x0012fa70) line 404 nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x0335635c, nsIDocumentLoader * 0x03357080, nsIChannel * 0x033dec60, unsigned int 0) line 1150 + 56 bytes nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x03357080, nsIChannel * 0x033dec60, unsigned int 0) line 712 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 542 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 514 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x034b7224, nsIChannel * 0x034b8bd0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 485 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x034b71c0, nsIChannel * 0x034b8bd0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 544 + 39 bytes nsStreamIOChannel::OnStopRequest(nsStreamIOChannel * const 0x034b8bd4, nsIChannel * 0x034b8a50, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 632 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x034b8df0) line 307 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x034b86d0) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x034b86d0) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x010f5160) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00f40486, unsigned int 49420, unsigned int 0, long 17781088) line 1032 + 9 bytes USER32! 77e71268() 010f5 STACK TRACE AT CRASH: NTDLL! 77f76274() gc_root_marker(JSHashEntry * 0x03ce3060, int 234, void * 0x00e71d80) line 745 + 35 bytes JS_HashTableEnumerateEntries(JSHashTable * 0x00cf2070, int (JSHashEntry *, int, void *)* 0x002aff60 gc_root_marker(JSHashEntry *, int, void *), void * 0x00e71d80) line 364 + 15 bytes js_GC(JSContext * 0x03c55300) line 912 + 21 bytes js_ForceGC(JSContext * 0x03c55300) line 770 + 9 bytes JS_GC(JSContext * 0x03c55300) line 1154 + 9 bytes nsJSContext::GC(nsJSContext * const 0x03c57110) line 1067 + 13 bytes GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x03c55490, nsIDOMDocument * 0x00000000) line 280 DocumentViewerImpl::~DocumentViewerImpl() line 406 DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x03c2b6d0) line 344 + 154 bytes nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 0x00000000) line 449 nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 820 nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 559 nsDocShell::SetupNewViewer(nsDocShell * const 0x03c28350, nsIContentViewer * 0x03b25b10) line 2305 nsWebShell::SetupNewViewer(nsWebShell * const 0x03c28350, nsIContentViewer * 0x03b25b10) line 560 + 13 bytes nsDocShell::CreateContentViewer(nsDocShell * const 0x03c28350, const char * 0x0012fad0, nsIChannel * 0x03b22130, nsIStreamListener * * 0x0012fb10) line 2194 + 24 bytes nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x03c28030, const char * 0x0012fad0, int 0, const char * 0x1009abc0 gCommonEmptyBuffer, nsIChannel * 0x03b22130, nsIStreamListener * * 0x0012fb10, int * 0x0012fab4) line 100 + 33 bytes nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x03b22130, nsISupports * 0x00000000) line 347 + 109 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x03bd0d00, nsIChannel * 0x03b22130, nsISupports * 0x00000000) line 196 + 16 bytes nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x03b22030, nsIChannel * 0x03b22130, nsISupports * 0x00000000) line 1148 nsHTTPCacheListener::OnStartRequest(nsHTTPCacheListener * const 0x03b22730, nsIChannel * 0x03b22360, nsISupports * 0x00000000) line 147 AsyncReadStreamAdaptor::OnStartRequest(AsyncReadStreamAdaptor * const 0x03b23f64, nsIChannel * 0x03b22360, nsISupports * 0x00000000) line 131 + 37 bytes nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x03b237c0) line 212 + 26 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03b23770) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x03b23770) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x010f5160) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00820478, unsigned int 49420, unsigned int 0, long 17781088) line 1032 + 9 bytes USER32! 77e71268() 01

If I use the mozilla.org site as described in this report, then I do get the same results that sarah reported. Not a crash. Just a blank screen appears when I click on view-image. This is all very strange. I don't see the pattern yet.

Here's my latest observations on this one. With a fresh tree that I pulled and built last night I no longer get the crash described above. So let's forget about that. Furthermore, I go to two sites. One is altavista.com which has a double-click image right at the top. I block that one. Reload the page and indeed it is blocked. I then brink up the context menu and do "view image" and a separate browser window opens that displays the image properly. I then repeat the above but use the image at the top of mozilla.org. In this case, when I do the "view image", a blank window appears. So what's different in these two cases? I don't know yet.

OK, here's the problem. If you recall from my comments above, I originally fixed this problem on 4-4 by checking to see if the image is a whole page by itself and, if so, always loading it. The test for that is in if.cpp at line 1928: firstURI->Equals(uri, &eq); if (eq) { ... return TRUE; } Unfortunately, in the mozilla.org case the two uri's match identically except for the port number. So my test above it not detecting that this is an image that is the whole page. Don't know what the correct test should be. In any event, this bug is quite minor. Some blocked-images can be displayed with the context-menu's "view image" and others cannot. Under the current checkin rules, there is no way this is going to get fixed anytime soon (unless someone from the web wants to champion it).

anyone? bueller...?

This is one of the few features that I would really like to see currently. Basically I just want to be able to peer at screenshots without having to go through the menu/dialog mess to alter my blocked sites data.

Sometimes, when I block an image from loading it will stop all other images from loading as well. is this part of the same problem?

It's not an image that you block, but rather a site. So if the other images are from the same site, then blocking one image will block them all.

Changing fictional "M30" to reality

future fix for something that used to work? poot.

yes, double the poot. it should be easy if it's a regression, and this would be nice to have in this release. (as a side note: steve, has that "blocking one image blocks all images in site" issue been reported? if that's the intended behavior, I guess a wording change in the context menu is needed)

I think you meant "tasks menu" rather than "context menu". The wording change has already been made there.

I'm away from Mozilla so I can't be certain, but I think I actually mean the right-click image context menu...last I remember, it said something kind of ambiguous, like "Block Image" or something...can someone let me know what it says now?

*** Bug 47276 has been marked as a duplicate of this bug. ***

.

Note : Bug 24533 will be fixed someday, and that means "View Image" will open in the same window, it will no longer open a new window. I'm not sure this changes how we fix this bug, but it should be taken into account by whoever does it.

Resummarizing, since this doesn't just apply to blocked images, but also when automatic image loading is turned off.

*** Bug 65105 has been marked as a duplicate of this bug. ***

->pavlov?

i think this bug depends on quite a few other things.. such as automatic image loading working :-)

*** Bug 138507 has been marked as a duplicate of this bug. ***

*** Bug 150226 has been marked as a duplicate of this bug. ***

*** Bug 151045 has been marked as a duplicate of this bug. ***

*** Bug 165800 has been marked as a duplicate of this bug. ***

Yes, View Image should either disappear from the content menu when an image is blocked, or it should remain int he menu, but show the image on view image, not just a blank page.

I'm voting for the case 'view image should show the image', as this is the only way to get an image despite of the 'block images' setting. Since this is a very specific decision of the user to click that menu item, we can assume that he really wants to view the previously blocked image then.

in case automatic image loading is off (like in my config when i'm on slow dialup), the situation with "View image" is even worse. when you select "view image", actual image is downloaded and stored in cache, but only usual broken image placeholder is presented to the user! Steps to reproduce: 1. Turn off auto loading of images in Preferences 2. Clear cache 2. Load www.mozilla.org or any site with images 3. Right click on any image, select "View image" 4. Behold "broken image" placeholder 5. Go to your user cache directory, sort files by date and view last file - it is actually an image you selected to view! Expected behavior: it would be nice to see selected image, it is already loaded from network, after all.

*** Bug 176771 has been marked as a duplicate of this bug. ***

*** Bug 183163 has been marked as a duplicate of this bug. ***

*** Bug 184367 has been marked as a duplicate of this bug. ***

I guess that more usable and advanced suggestion for this bug is fixing bug 47475. Maybe, this bug even should be marked as a dupe of 47475

Should be blocked on 47475, more like. Once bug 47475 is fixed this bug may be a no-op but it will still need to be tested.

I checked it in Mozilla 1.3 - still doesn't fixed :(

*** Bug 67159 has been marked as a duplicate of this bug. ***

*** Bug 101897 has been marked as a duplicate of this bug. ***

Fixed by checkin of attachment 119027 [details] [diff] [review].

*** Bug 67159 has been marked as a duplicate of this bug. ***

ok.. i checked this fix in mozilla 1.4b under my win XP machine.. Seems it fixed but not ot end.. First when I disable pix in browser I still not see "border" which show me that here image on the page sometimes.. Most of seems it happen when image contain alt="bla" in <img src=""> tag, or also seems when <img src="" tag contain border=0 It's also strange because sometimes it works pretty fine (cache troubles?) When I try click right button on disabled image and choose "View image" page move to image! (in the same tab but without any other content).. seems it should upload it to the page as in IE way (or mozilla should has special setting for it "Open in new window" or "Upload disabled images to the page")

Shouldn't we reopen this bug cause these sings ?