Open Bug 57505 (LoadImages) Opened 24 years ago Updated 7 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: mpt, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: relnote-user [imagelib])

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.
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!
Assignee: ben → morse
Keywords: regression
QA Contact: sairuh → tpreston
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.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
alas, i don't think this can get fixed for nscp6 rtm --but could we at least get
it fixed in the trunk? thx!
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
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. ;)
Keywords: helpwanted
Relnote: `The "Show Images" command does not work.'
Keywords: relnoteRTM
Whiteboard: relnote-user
Target Milestone: M19 → M20
Summary: `Show Images' command not hooked up → [x]`Show Images' command not hooked up
Target Milestone: M20 → ---
Summary: [x]`Show Images' command not hooked up → `Show Images' command not hooked up
Whiteboard: relnote-user → [x]relnote-user
Blocks: 61710
Keywords: regressionnsbeta1
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.
Assignee: morse → pnunn
Status: ASSIGNED → NEW
Component: XP Apps: GUI Features → ImageLib
Whiteboard: [x]relnote-user → relnote-user
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.
Blocks: 66627
adding pavlov.  pnunn is on sabbatical, this should go to pavlov if urgent.
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.
-->Pavlov
Assignee: pnunn → pavlov
Pav or someone, is this just a chrome fix or a C++ component change?
this is still happening on 04/17/01 builds
Whiteboard: relnote-user → relnote-user [imagelib]
*** Bug 76562 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
Blocks: 81552
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.
Depends on: 73848
*** Bug 92822 has been marked as a duplicate of this bug. ***
Any news on this bug? Blocker seems to be resolved...
*** Bug 101058 has been marked as a duplicate of this bug. ***
terri, is this still broken?

pav, what's the progress on this bug?

just curious!
zero progress :)
Blocks: 101058
*** Bug 101058 has been marked as a duplicate of this bug. ***
Blocks: 104166
Keywords: useless-UI
Ehhhh, Stuart tells me this isn't his bug after all. --> XP Apps.
Assignee: pavlov → pchen
Component: ImageLib → XP Apps
QA Contact: tpreston → sairuh
steve? not sure who should own this...
Assignee: pchen → morse
QA Contact: sairuh → tpreston
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.
NO, this is not me.  See my comments 4 and 7 above.  Assigning to 
browser-general so it can get reassigned, probably to imagelib.
Assignee: morse → asa
Component: XP Apps → Browser-General
QA Contact: tpreston → doronr
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.
Assignee: asa → adamlock
Component: Browser-General → Embedding: Docshell
QA Contact: doronr → adamlock
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.
Assignee: adamlock → pchen
Component: Embedding: Docshell → XP Apps
QA Contact: adamlock → sairuh
round and round we go...sigh.
Target Milestone: Future → ---
->ben p2/098
Assignee: pchen → ben
Priority: P3 → P2
Target Milestone: --- → mozilla0.9.8
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
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?
Target Milestone: mozilla0.9.8 → mozilla0.9.9
*** Bug 117044 has been marked as a duplicate of this bug. ***
As far as I know, this is not on any of our plans, so, ->Future. Someone should
feel free to help out ;)
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → Future
Perhaps the menu item for show images should be cut if this feature is non
functional and futured.
*** Bug 119396 has been marked as a duplicate of this bug. ***
I just removed the menuitem. Taking this bug.
Assignee: ben → blaker
Status: ASSIGNED → NEW
Keywords: useless-UI
*** Bug 126411 has been marked as a duplicate of this bug. ***
nsbeta1- per nav triage team.  We can live without this command for MachV
Keywords: nsbeta1nsbeta1-
Keywords: 4xp
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.
What is this bug talking about ? What is now Tools->Image Manager->... ?

/me lost in a maze of "load image" bugs
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....
*** Bug 134366 has been marked as a duplicate of this bug. ***
*** Bug 93604 has been marked as a duplicate of this bug. ***
Alias: LoadImages
Summary: `Show Images' command not hooked up → Implement Netscape 4.x "Manual Image Loading" functionality for low-bandwidth users (was: `Show Images' command not hooked up
*** Bug 159903 has been marked as a duplicate of this bug. ***
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.
Debogosifying summary. Comment 45 is obviously not this bug, it's bug 34165.
Summary: Implement Netscape 4.x "Manual Image Loading" functionality for low-bandwidth users (was: `Show Images' command not hooked up → "Load Images" command not available (show images after page loads)
*** Bug 153091 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1-nsbeta1
nominating for Buffy--not that I have much hope :-(
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
OK, I've got a plan for this:
1. Turn off imageblocking pref
2. Reload the page
3. Turn on imageblocking pref
Comments?
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.
Dupe of bug 47475? BTW, it has a patch.
doesn't sound like a dup to me; this bug is forthe menu command, that one for
the context menu command.
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.
Keywords: mozilla1.0
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.
*** Bug 201029 has been marked as a duplicate of this bug. ***
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.
THat's Bug 47475
*** Bug 212215 has been marked as a duplicate of this bug. ***
Reference comment #57: "When images are blocked the ALT tag doesn't show up."

I believe that is bug #57505.  
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).  
Is this going to get fixed at all?
Blocks: 237334
*** Bug 241419 has been marked as a duplicate of this bug. ***
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:-)
(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 ;-)
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?
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?
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.
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.
Assignee: firefox → nobody
(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...
(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/
Product: Core → Mozilla Application Suite
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.
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.  
Assignee: nobody → jag
Priority: P2 → --
QA Contact: bugzilla
Target Milestone: Future → ---
Assignee: jag-mozilla → nobody
You need to log in before you can comment on or make changes to this bug.