57505 - (LoadImages) "Load Images" command not available (show images after page loads)

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Matthew T (active 1999-2002)]

Build: 2000102008, Mac OS 9.0

To reproduce:
* In the Images category of prefs, turn images off.
* Browse to a page which contains images.
* Open the `View' menu.

What should happen:
* The `Show Images' item is enabled.

What actually happens:
* The `Show Images' item is disabled.

This has probably been reported already, but I can't find it.

Comment 1

[sairuh (rarely reading bugmail)]

weird...this is reminiscent of http://bugscape.mcom.com/show_bug.cgi?id=2544,
which was fixed (commercial only).

this isn't a problem for me using the linux commercial branch bits
[2000.10.24.09-n6]. am currently waiting for my mac commercial build to install;
will update soon.

asa, could you also check the latest linux and win32 mozilla bits? am wondering
if (1) if this is trunk only, (2) if it's mozilla only, and/or (3) if it's mac
only. thx much!

Comment 2

[sairuh (rarely reading bugmail)]

i take my comment back (i was doing the wrong thing to repro this).

this is indeed a problem in the commercial branch, on all platforms.

Comment 3

[sairuh (rarely reading bugmail)]

alas, i don't think this can get fixed for nscp6 rtm --but could we at least get
it fixed in the trunk? thx!

Comment 4

[Stephen P. Morse]

Well this was simply a feature that was never implemented.  I implemented 
selective image blocking and, as a fallout, did total image blocking as well.  
But implementing of total image blocking was not my intent and I never 
investigated its nuances.

This bug should be assigned to whomever would have done total image blocking if 
I had not at least made a start at it.  Not sure whom that would be (pnunn?).  
In any case, you can leave this on my plate for now but I probably won't get to 
it for a long time.  If someone wants to take it from me and fix it sooner (on 
the trunk at least), go right ahead.

Comment 5

[sairuh (rarely reading bugmail)]

now that you mention it, i did file bug 21947 a long time ago, but it was dup'd
for a bug that was for a [temporary] shutoff of menu items that didn't work
[back in February 2000]. the funny thing is that i have some memory of this
working... dang, those memory implants are fritzing again. ;)

Comment 6

[Matthew T (active 1999-2002)]

Relnote: `The "Show Images" command does not work.'

Comment 7

[Stephen P. Morse]

Selective image blocking is done in the nsCookie.cpp file and so would get 
classified as a cookie bug.  Total image blocking is done in the image library.

This bug involves total image blocking.  So reassigning.

Comment 8

[schorsch]

It might be of motivational help to mention that this is pretty much the only
missing feature that keeps me (and probably many others) from actively testing
Mozilla. A certain kind of power user tends to surf with image loading off,
which requires the possibility to reload them on demand. An extra button in a
toolbar would be a nice addition, but is not of the same urgency.

Comment 9

[Chris McAfee]

adding pavlov.  pnunn is on sabbatical, this should go to pavlov if urgent.

Comment 10

[dipa]

I totally agree with Schorsch although I use and test Mozilla (only at work, 
where bandwidth is not a concern). The Show Images command in the View menu was 
a great feature of Nav 3.x., as a means to temporarily activate automatice image 
loading. Later, it was omited and one had to use Preferences->Advanced or the 
Image button in the toolbar which was too clumsy when the page has frames. I 
wholeheartedly wish for this feature to return in Moz 1.0 :)
BTW, I think perhaps it would be better to assign more priority to all those 
(currently inactive in Mozilla) features of the Nav 3.x/4.x. Then, some nice IE 
features could be implemented as well. Thx anyway for listening my suggestions.

Comment 11

[Matthew T (active 1999-2002)]

-->Pavlov

Comment 12

[Aaron Leventhal]

Pav or someone, is this just a chrome fix or a C++ component change?

Comment 13

[Tom Everingham]

this is still happening on 04/17/01 builds

Comment 14

[Keyser Sose]

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

Comment 15

[Sean Richardson]

It is currently impossible to test this bug or any fix for it until bug 73848, 
"Image blocking no longer works", is fixed, so setting blocker.

Comment 16

[sairuh (rarely reading bugmail)]

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

Comment 17

[Paul Sokolovsky]

Any news on this bug? Blocker seems to be resolved...

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[sairuh (rarely reading bugmail)]

terri, is this still broken?

pav, what's the progress on this bug?

just curious!

Comment 20

[Stuart Parmenter]

zero progress :)

Comment 21

[Stephen P. Morse]

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

Comment 22

[Matthew T (active 1999-2002)]

Ehhhh, Stuart tells me this isn't his bug after all. --> XP Apps.

Comment 23

[sairuh (rarely reading bugmail)]

steve? not sure who should own this...

Comment 24

[Stuart Parmenter]

this bug has multiple parts.. disabling image loads on a page goes through the
content policy stuff I think... I believe this is going to require selectivly
allowing images on a page to load, and changing an image's src to whatever it is
currently to force the image to reload.  this should result in it showing up.. 
But I don't know how to turn off images on a page or how to selectivly allow an
image on a page to load.  you may want to talk to valeski or shaver about it as
I think they added this for embedding a little while ago.

Comment 25

[Stephen P. Morse]

NO, this is not me.  See my comments 4 and 7 above.  Assigning to 
browser-general so it can get reassigned, probably to imagelib.

Comment 26

[timeless]

Browser General doesn't do proper assignments of developer handled bugs. It 
does general triages of untouched bugs. I'll take a random stab based on 
pavlov's comments, although XPApps something would be a nice fit for the 
generic summary.

Comment 27

[Adam Lock]

Docshell has an allowImages property but it is up to others to store, set and
get that value as appropriate. Getting is probably done indirectly through a
content policy object.

Reassigning to XPApps.

Comment 28

[sairuh (rarely reading bugmail)]

round and round we go...sigh.

Comment 29

[Peter Trudelle]

->ben p2/098

Comment 30

[timeless]

bug 81263 is what adam lock was talking about. ok, that's a good start.

valeski, should we be concerned about 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/embedding/browser/webBrowse
r/nsWebBrowserContentPolicy.cpp&rev=1.1&mark=64-68#57

Comment 31

[Judson Valeski]

cc'ing shaver. I don't think that meta redirect #if 0 is going to impact this
bug, but, I'm not sure if it's harming other things; mike?

Comment 32

[Matthew T (active 1999-2002)]

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

Comment 33

[Ben Goodger (use ben at mozilla dot org for email)]

As far as I know, this is not on any of our plans, so, ->Future. Someone should
feel free to help out ;)

Comment 34

[Adam Lock]

Perhaps the menu item for show images should be cut if this feature is non
functional and futured.

Comment 35

[Asa Dotzler [:asa]]

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

Comment 36

[Blake Ross]

I just removed the menuitem. Taking this bug.

Comment 37

[Boris Zbarsky [:bzbarsky]]

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

Comment 38

[Peter Trudelle]

nsbeta1- per nav triage team.  We can live without this command for MachV

Comment 39

[WB]

I vote for the 'Show Images' menu item to be enabled, because I also use Opera, and appreciate it's 
similar functionality, i.e., I have image auto-loading turned OFF, but then I can hit Shift-G on a 
given window, to simply load the images on a one-time basis.  FWIW, in opera, you can instead hit 'G' 
(no shift), if you want a given window to always load images during that session.

A few years 
ago, I was able to surf the web fairly comfortably with just a 14.4k modem.  Now, I have a 56k modem, 
and, you'd think that my speed would be a lot faster.  However, in the intervening years, web 
designers have added more images, scripts, and other enhancements to their pages, such that they 
are becoming slower and slower to load.  That is why now, I've set 'Auto load images' in Opera to 
*OFF*.  And that is why I think this feature should be added (back) to Mozilla and Netscape.

Comment 40

[John Levon]

What is this bug talking about ? What is now Tools->Image Manager->... ?

/me lost in a maze of "load image" bugs

Comment 41

[Masato]

This Bug (or MailingList:) is for implementing the old Netscape 4.x "Manual
Image Downloading" (disable automatic image loading without blocking immages or
interfere  with the rules)
its useful for Modem Users who can choice the images they need and already
cached images are loaded imidiatly....

Comment 42

[Michael Lefevre]

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

Comment 43

[Jesse Ruderman]

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

Comment 44

[Wesha]

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

Comment 45

[egor]

this bug is not only about "image button"
this bug is about IMAGE LOADIN PROCESS
if image loading disabled you CAN NOT VIEW ANY IMAGE FILE "directly"

forexample: 
http://www.site.com/image.jpg - if you'll turn off images and try to see ANY 
pic... you'll se NOTHING.

Comment 46

[Matthew T (active 1999-2002)]

Debogosifying summary. Comment 45 is obviously not this bug, it's bug 34165.

Comment 47

[Matthew T (active 1999-2002)]

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

Comment 48

[Daniel Veditz [:dveditz]]

nominating for Buffy--not that I have much hope :-(

Comment 49

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 50

[[e-mail]]

OK, I've got a plan for this:
1. Turn off imageblocking pref
2. Reload the page
3. Turn on imageblocking pref
Comments?

Comment 51

[Aaron Lawrence]

The last suggestion, well it sounds functional, but ugly. 

I'd just like to say that, even with high speed, this would be useful. Some
sites, like TomsHardware.com, use gratuitous large images all the time, like
company logos instead of a list of names, so the page still takes a while to
load. If you're paying by the MB like I do on broadband, this is even more painful.

Comment 52

[Manko]

Dupe of bug 47475? BTW, it has a patch.

Comment 53

[Christian :Biesinger (don't email me, ping me on IRC)]

doesn't sound like a dup to me; this bug is forthe menu command, that one for
the context menu command.

Comment 54

[Michael Lefevre]

bug 47475 is related, but not the same. that bug probably depends on this one.
the patch there is useless - it's 18 months old and wouldn't work at all.

Comment 55

[mozilla]

seems related to 47792?

There are so many bugs/dups related to this 2yr old "NEW" bug, maybe if some of
us on the CC list vote for the bug, someone will actually take notice and fix it?

I mean, it worked in NS3/4, so I'm sure it can work here.

Comment 56

[Boris Zbarsky [:bzbarsky]]

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

Comment 57

[James Stauffer]

It would be nice to load only certain images on a page (MS IE "Show Picture"). 
Related idea: When images are blocked the ALT tag doesn't show up.

Comment 58

[Aaron Lawrence]

THat's Bug 47475

Comment 59

[Charles Fenwick]

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

Comment 60

[David E. Ross]

Reference comment #57: "When images are blocked the ALT tag doesn't show up."

I believe that is bug #57505.  

Comment 61

[David E. Ross]

Oops!  I posted comment #60 to the wrong bug (a consequence of browsing multiple
bugs via tabbed browsing).  There should be a method for those who insert
comments into a bug report to delete them (at least before any additional
comments are inserted).  

Comment 62

[Elmo Recio]

Is this going to get fixed at all?

Comment 63

[Stefan Borggraefe]

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

Comment 64

[Gorshunov]

I wonder how many years will pass until this bug is fixed. I'd like to propose
to add new item into "target milestone" like "NEVER". That will solve the problem:-)

Comment 65

[Darin Fisher]

(In reply to comment #64)
> I wonder how many years will pass until this bug is fixed. I'd like to propose
> to add new item into "target milestone" like "NEVER". That will solve the
problem:-)

Please keep your comments constructive.  Your comment only adds noise to this
bug. It increases the burden on developers, who may wish to fix this bug,
because they must weed through the spam in order to pick out the valuable comments.

As you can see, this bug has the "Future" milestone and "helpwanted" keyword. 
That means the owner of this bug has stated that he is simply not able to work
on this bug any time soon and that patches are most welcome ;-)

Comment 66

[Andrey ``Bass'' Shcheglov]

I'm neither a C++ guru, nor a person familiar with Mozilla API. Which RTFM
should I read first in order to start working on fixing this bug?

Comment 67

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I was wondering if this might be less work than anticipated. Say, create a
special CSS stylesheet that disables all images, then have a command to
dynamically either add or remove it from a document. 

So, as a first step, could anyone create such a stylesheet and attach it to this
bug?

Comment 68

[Matthew T (active 1999-2002)]

You mean something like "* {background-image: inherit !important} img {display: none
!important}"? Nice idea, but I see three problems. 1: It would hide the ALT text as 
well as the image, making the Web with images off practically unusable. (It's 
unusable in Safari for this reason.) 2: It wouldn't work for the OBJECT element 
(which should be loaded only if it's not of type image/*). 3: There would be nothing 
to {right-|Ctrl+}click on to load a particular image.

Comment 69

[timeless]

what to read first? probably some interface files (.idl) which relate to image
loading. i'm not sure where they are, for the time being you could just load
http://lxr.mozilla.org/seamonkey/find?string=\.idl$ and browse through looking
for good hits, nsIImageLoadingContent.idl looks like a reasonable candidate.
personally i'd start w/ interfaces listed in layout and content and then jump to
things in dom or gfx/libpr0n.

if you don't know what an idl file is, then that'd be the thing about which to
read first. i'd have hoped you could find something useful in
http://www.mozilla.org/hacking/, but i can't at first glance.

you could read bits near:
http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/

you'll probably want to visit:
http://unstable.elemental.com/mozilla/

and for a nice overview of xpcom, i'd probably start at:
http://www-106.ibm.com/developerworks/webservices/library/co-xpcom.html

don't take the order of the links i've listed as a bible, do read at least 2
levels deep from most of them.

I haven't read the mozilla books that are available, but you might want to, perhaps:
http://books.mozdev.org/chapters/ch08.html

note: just because something is in print doesn't mean it's right.

it's probably a good idea for you to get mozilla building before you try to hack it:
http://www.mozilla.org/build/

for more timely answers (after you do at least /some/ homework), visit
irc.mozilla.org #developers, be nice, curtious and above all patient. it could
take me 8 hours to respond to your question (not very likely, i don't seem to
sleep for that long), but generally someone will read your question and answer
it or, if someone joins who is better able to answer your question, someone who
read your question will probably be nice enough to suggest that you ask that
person for advice.

Comment 70

[Andrey ``Bass'' Shcheglov]

(In reply to comment #69)
> if you don't know what an idl file is, then that'd be the thing about which to
> read first. i'd have hoped you could find something useful in
> http://www.mozilla.org/hacking/, but i can't at first glance.

Thanks a lot for the links, this information is really valuable. I do know what
an IDL file is, though it seems that *in mozilla*, IDL is used in some uncommon
way. I mean, no corba-related stuff.

> it's probably a good idea for you to get mozilla building before you try to
hack it:
I always build mozilla myself :) Though ./configure; make all install has
nothing to do with 'Load images' command unavailable...

Comment 71

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #70)
> Thanks a lot for the links, this information is really valuable. I do know what
> an IDL file is, though it seems that *in mozilla*, IDL is used in some uncommon
> way. I mean, no corba-related stuff.

Hmm, like with COM and CORBA (I think), it is used to define interfaces. but in
mozilla, the implementation of them is usually local and in the same process.

see http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/index.html
maybe http://www.mozilla.org/scriptable/
possibly http://www.mozilla.org/scriptable/xpidl/syntax.html but that's
supposedly out of date
http://www.mozilla.org/scriptable/xpidl/

Comment 72

[Aaron Lawrence]

Maybe we should close this. 
- It has had 4 years without updates
- there is at least one plugin which can basically do this 
https://addons.mozilla.org/en-US/firefox/addon/232
- users who want to browse without images is becoming a very small minority now, so a plugin seems appropriate - for the desktop versions anyway.

Comment 73

[David E. Ross]

I browse some sites with my preferences set to refuse all images.  These are sites that have excessive, gratuitous, large image files.  I do this because -- as with over 40% of the Internet users in the U.S. -- I'm on a dial-up connection.  

I don't need the cited add-on.  I use PrefBar to control my preferences for images.  

However, an extension or other add-on should not be considered equivalent to fixing a problem or implementing an RFE within a browser.  Add-ons are not inherent to a browser; they require separate installation.  As browsers evolve, add-ons often become incompatible.  

Either implement the requested RFE, or else justify a WONTFIX on the basis that the RFE requests something inappropriate.