34165 - (viewblocked) `View Image' fails when blocked or when automatic loading is off

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[sairuh (rarely reading bugmail)]

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?

Comment 1

[Stephen P. Morse]

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

Comment 2

[sairuh (rarely reading bugmail)]

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?

Comment 3

[Stephen P. Morse]

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.

Comment 4

[sairuh (rarely reading bugmail)]

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

Comment 5

[Stephen P. Morse]

Fix checked in.  File affected was if.cpp

Comment 6

[sairuh (rarely reading bugmail)]

unable to verify until 34079 is fixed.

Comment 7

[sairuh (rarely reading bugmail)]

[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.

Comment 8

[sairuh (rarely reading bugmail)]

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

Comment 9

[Stephen P. Morse]

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

Comment 10

[Stephen P. Morse]

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.

Comment 11

[Stephen P. Morse]

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.

Comment 12

[Stephen P. Morse]

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).

Comment 13

[sairuh (rarely reading bugmail)]

anyone? bueller...?

Comment 14

[briareos]

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.

Comment 15

[Michael Goit]

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?

Comment 16

[Stephen P. Morse]

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.

Comment 17

[Daniel Veditz [:dveditz]]

Changing fictional "M30" to reality

Comment 18

[sairuh (rarely reading bugmail)]

future fix for something that used to work? poot.

Comment 19

[Blake Ross]

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)

Comment 20

[Stephen P. Morse]

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

Comment 21

[Blake Ross]

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?

Comment 22

[Stephen P. Morse]

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

Comment 23

[Stephen P. Morse]

.

Comment 24

[Fabian Guisset]

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.

Comment 25

[Matthew T (active 1999-2002)]

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

Comment 26

[Keyser Sose]

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

Comment 27

[sairuh (rarely reading bugmail)]

->pavlov?

Comment 28

[Stuart Parmenter]

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

Comment 29

[Matthias Versen [:Matti]]

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

Comment 30

[John Levon]

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

Comment 31

[Michael Lefevre]

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

Comment 32

[Olav Vitters]

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

Comment 33

[Alex Radu]

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.

Comment 34

[beanladen]

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.

Comment 35

[kmike]

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.

Comment 36

[Wesha]

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

Comment 37

[R.K.Aa.]

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

Comment 38

[R.K.Aa.]

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

Comment 39

[Manko]

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

Comment 40

[Ian Collier]

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.

Comment 41

[Marat Fatkullin]

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

Comment 42

[Boris Zbarsky [:bzbarsky]]

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

Comment 43

[Boris Zbarsky [:bzbarsky]]

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

Comment 44

[Boris Zbarsky [:bzbarsky]]

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

Comment 45

[Michiel van Leeuwen (email: mvl+moz@)]

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

Comment 46

[Marat Fatkullin]

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")

Comment 47

[Marat Fatkullin]

Shouldn't we reopen this bug cause these sings ?