Closed
Bug 245177
Opened 22 years ago
Closed 22 years ago
Doesn't show image gallery
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: mozilla, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8a1) Gecko/20040520
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8a1) Gecko/20040520
It has existed for a long time in Mozilla, but not in Opera or IE (through
CrossOver).
When viewing the above URL it may be noticed that the large image doesn't show,
and it means that when I want to go through the image gallery I can't do it with
Mozilla, but has to turn to eg. Opera or copy'n'paste the URL of each image into
the command line of the Mozilla browser.
I don't actually know if it is a CSS problem, and/or if it is actually a site
problem where Mozilla is in fact rendering it correctly, but the result is that
it doesn't show in Mozilla.
Also, I don't know the exact details in the difference between the reported
problematic URL and this one:
http://pics.jp.dk/nybillede/default.asp?id=1652&pixid=21141
Where I am able to see the large image in the middle and then click through the
other pictures.
Reproducible: Always
Steps to Reproduce:
1.Go to the specific URL
2.Notice that no image is shown in the middle
3.Click on one of the other smaller images at the bottom and notice that none of
them are shown either.
4.Compare with eg. Opera 7.50 and see that the images are shown as could be
expected.
Actual Results:
Only the index images at the bottom showed.
Expected Results:
Shown the images in the middle area.
Just in case it matters:
udgaard:~$ ldd /usr/local/mozilla/mozilla-bin
libmozjs.so => not found
libplds4.so => not found
libplc4.so => not found
libnspr4.so => not found
libpthread.so.0 => /lib/libpthread.so.0 (0x40022000)
libdl.so.2 => /lib/libdl.so.2 (0x40074000)
libgtk-1.2.so.0 => /usr/local/lib/libgtk-1.2.so.0 (0x40077000)
libgdk-1.2.so.0 => /usr/local/lib/libgdk-1.2.so.0 (0x4019d000)
libgmodule-1.2.so.0 => /usr/local/lib/libgmodule-1.2.so.0 (0x401cf000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x401d2000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401f8000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40200000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4020d000)
libm.so.6 => /lib/libm.so.6 (0x402c7000)
libc.so.6 => /lib/libc.so.6 (0x402ea000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
WFM. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040531
Sounds like you are blocking images from other than the originating site.
Edit->Preferences->Privacy & Security->Images->Image Acceptance Policy
Comment 2•22 years ago
|
||
The image shows fine with Linux trunk build 2004-05-21-06. Please check your
image preference settings and make sure that you allow loading of all images
(the central image on that page comes from a different server than the page
itself; the other URL you cite has both image and page coming from the same server).
| Reporter | ||
Comment 3•22 years ago
|
||
Impressed by the speed of first replies :-)
And thanks for reminding me of a missing piece of information. I do normally
have the setting of images loaded from other sites to off, but this time I did
test it before submitting the bug report and it doesn't matter if I have:
Edit->Preferences->Privacy & Security->Images->Image Acceptance Policy
set to "Accept all images", which is why I think there is a, if not a bug in CSS
then at least an issue that should be dealt with perhaps in a more liberal manner.
I mostly brought the working site in for the sake of comparison seen from a
users perspective. They may be browserwise totally unrelated.
Comment 4•22 years ago
|
||
Peter, the point is that neither Christine nor I can reproduce the problem..
Could you please make sure to restart the browser after changing that image
permission preference? That should not be necessary, but...
And what are your cache prefs?
With "allow all images" set: Does the page still not display with images if you
delete cache before loading it?
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout
QA Contact: ian → core.layout
| Reporter | ||
Comment 6•22 years ago
|
||
You are both right that either restarting the browser or clearing the cache may
affect the way it works and i did attempt both suggestions as well.
If you can't reproduce it I suspect that a library version (or a missing lib)
may be the culprit, which is why I at first also submitted the output of ldd.
As I however, on the exact same system am able to view the site with Opera 7.50
(static, tar.gz) and with IE 5.5 through CrossOver 1.3, I would at least like
Mozilla to tell me about a (potential?) problem. Even with a pre-release like
this one, I am not able to (with my limited browser knowledge) debug and find
better and more precise info about the problem.
Your inability to reproduce the problem and not being able to retrieve better
info about what might be wrong may in and of itself be a (different) problem, Of
course trusting that I am reporting truthfully, which I am to the best of my
ability I can assure you :-)
Regarding the output of your ldd: That's normal.
Are you using a proxy? If yes: What is the HTTP pref under
Edit->Preferences->Advanced->HTTP Networking ?
If HTTP 1.1: Try setting it to 1.0
If no: Can you check if setting the direct connection option to HTTP1.0 changes
anything. (Suspecting a faulty "transparent proxy" outside your control)
Also: Is keep-alive and/or pipelining enabled?
spamming.. one more thing: Are you using any mozilla addons/extentions?
Please also create a new profile and try with that. (since you say you've seen
the bug for a long time.)
| Reporter | ||
Comment 9•22 years ago
|
||
I use no proxy at where I am, ie. directly connected through a Cisco ADSL
router, but I attempted setting Networking to HTTP 1.0 and ensure that both
"Enable Keep-Alive" and "Enable Pipelining" were unset (until now, only the
first was set). That didn't help.
Until now I have only ever used the default profile, and creating a new one
enabled me to see the image gallery that I couldn't before, ie. it seems to have
fixed my original complaint.
I then, however, also noticed some other changes, with a greatly reduced
prefs.js file (789Bytes vs. 14446Bytes), eg. the Tools->User Agent Switcher had
disappeared and it seems to believe from startup that I am working offline, in
both profiles.
The present .mozilla/default profile is really old (years) and it probably
contains a lot of unnecessary cr*p, but I am somehow wondering what settings
would let me not see those images when nothing in the Edit->Preferences had
hinted at it.
Comment 10•22 years ago
|
||
Tested Mozilla 1.6 and 1.4: Images display fine.
There is an Advanced pref (Edit->Preferences->Advanced->Scripts & Plugins
"Allow scripts to:" Change images
(I'm looking the 1.4 UI right now - not sure if it changed later)
Anyways: The pref is checked (allowed) by default.
Was it de-selected in your old profile?
Since this doesn't happen for other users - or with new profiles - and it seems
somewhat futile to guess at random what might have caused it: Resolving as WFM.
If you remember possible addons/extentions you use/have used over the past
years: Please add info.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 11•22 years ago
|
||
Yes, that was it. Usually I have "Allow scripts to:" all unchecked, but
selecting/setting "Change images" allowed me to view the image gallery as I had
wanted.
Ergo, the problem was about a piece of UI I didn't expect to work like that, ie.
I didn't understand it correctly.
You may close it as WFM.
Thanks for clearing the matter up so swiftly and following it to the end.
Comment 12•22 years ago
|
||
Glad we found out what it was!
Personally I allow all "script stuff" in browser but NOT in mail.
So all except mail is checked in that pref pane.
Verifying WFM per reporter's comment 11
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•