Using Mozilla 1.1 on Win98FE... it was working okay for a while, modulo the instability (Matrox incompatibility?) in bug 157256. A couple weeks back I installed Netscape 7.0, discovering that it shares Mozilla's ApplicationData directory. So to run them both at once, I need to have two profiles. Okay. And since the main "inferiority" of NS7 is its lack of popup suppression, I installed adblocker.xpi. I don't know if that's relevant to this problem, which impacts both Mozilla 1.1 and Netscape 7 equally. When I display a page that contains .gifs, the image doesn't register. View Image says it cannot be displayed "because it contains errors". For instance, the homepage http://www.nytimes.com/ looks really bad without the Times logo on top. Some other things render weirdly too. I get the wrong fonts, as well as no graphics, on pages like The Register (http://www.theregister.co.uk). The CompUSA homepage is unreadable due to its colors. I have it set to show all graphics. Reinstalling Moz 1.1 didn't help. BTW, h/w is an Athlon 1000, 128 MB, Matrox G400, EPoX 8KTA3 (VIA chip) mobo.
Same problem on http://www.crpgl.lu and http://www.crpgl.lu/Images/Menu4.gif with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020915. It worked two weeks ago.
Interesting discovery -- it depends on profile! I had two profiles for myself, my original one in \Users50 and a copy in \Profiles. I needed the copy because, after installing Netscape 7, it wouldn't run against a profile that Mozilla already had open. Anyway, both of these profiles were spooged and didn't work right. But, after uninstalling Netscape 7 and Mozilla to be sure and reinstalling Mozilla 1.1, I tried the other profiles (mozProfile and a couple left over from visits by family members). They displayed correctly. So I blew away one of my two duplicate profiles, re-created it (from defaults), copied in my bookmark and cookie files, and reset the prefs. Something in one of the prefs files is causing the problem. I still have to manually reset the prefs in order to make PDFs display externally, rather than as plugins. But that's another bugzilla entry.
I've got v1.2a and, for example, mapquest maps are not displaying when the Preferences->Privacy & Security->Images->Accept Images that come from the originating server only turned Selected. I'm still trying the sites that I've visited that had missing images before I switched the above "switch". Maybe a more descriptive message in the Image control box is necessary to say that if you select this, you may not get some images that you would expect from a website (example: maps in www.mapquest.com may not display). I expect this has to do with some sites using different servers or cookie domains to serve images (caching servers?).
Ok - i've tested the sites I had problems with including the ones listed in this bug - they all seem to work for me now (moz 1.2a on win2kp). Maybe another selection in the Image control pane should be "ONLY accept images from the server's domain". This way, moz is still a bit more secure and a bit more open to accept images from other servers in the senders domain. The technical view for my example is that www.mapquest.com uses art.mapquest.com to generate graphics. If your security is too strict, then you get all the nice mapquest wrapping but no map.
*** This bug has been marked as a duplicate of 147845 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
I don't think it's a duplicate. There is no screen corruption here.
This bug isn't a duplicate of 147845. Screen (memory) corruption isn't the problem that is discussed here. It is the fact that some web sites have different servers to serve images and, for the most part, most people have "Accept images that come from the originating server" selected. For example, www.mapquest.com uses a different server and sometimes a different domain for the map graphic. What may appease the security gods is to have a compromise button that has "accept images that come from the same domain"...
Status: RESOLVED → UNCONFIRMED
Component: ImageLib → Networking
Resolution: DUPLICATE → ---
Summary: GIF images won't display; errors reported → Images won't display; errors reported (allow images from original server blocks images from same domain)
Assignee: pavlov → dougt
QA Contact: tpreston → benc
-> image blocking, if I understand this correctly.
Assignee: dougt → morse
Component: Networking → Image Blocking
QA Contact: benc → tever
Correct. Image blocking is the issue. Maybe a nice addition to the "Security -> Images" pane would be to "allow images from the same domain". This will allow for reverse-squid or image servers to work with web servers on different boxes on the same domain. See my examples earlier in the bug comments.
dup of bug 121084? What is your cache prefs?
Reassigning unconfirmed image blocking bugs to the new owner
Assignee: morse → mstoltz
Cache prefs are the defaults from a clean install 1.3b 20030108 I don't think it is a "bug" in the truest sense but more of a misunderstanding or limitation in the image blocking feature(s). For any site that has graphics from some other domain or different host, those images will be blocked if the "accept images that come from the originating server only" is checked. The example site I used was www.mapquest.com. The page text and wrappers are from that "site" but the map graphics are from a different "server" but in the same domain and thus the images are blocked. My rec was to add another button that said/did "accept images that come from the same domain" - where only the server name changed and the domain component was the same.
Severity: normal → enhancement
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Images won't display; errors reported (allow images from original server blocks images from same domain) → [RFE] "accept images from same domain" option
Target Milestone: --- → Future
I recommend wontfix to avoid feature creep; this may be best handled in an add-on module. But I leave that to the next module owner to decide.
This is actually what is done. Only the tail of the hostname is checked (domain.com) But is was broken for some time, but should be fixed now (only on trunk, not on the 1.4 branch). Reporter, could you try a recent nightly?
*** Bug 202611 has been marked as a duplicate of this bug. ***
*** Bug 270987 has been marked as a duplicate of this bug. ***
*** Bug 299022 has been marked as a duplicate of this bug. ***
Assignee: security-bugs → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.