19580 - Scrollbars are absent when loading a graphic

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect, P3)

Description

[Chris Moyer]

I've tried this with Gif's and Jpg's and whenever I load an image that is not
part of an HTML doc, the scrollbars do not appear, even if the image is much
bigger that the viewing area. I have tried this with M11 and the nightly build
from Friday, Nov 19th. I'm not sure if there is another bug report that covers
this more broadly, but I could not find one.

Comment 1

[leger]

elig, can you reproduce?

Comment 2

[Chris Moyer]

Attachment: Shot of error

Comment 3

[Chris Moyer]

I created a screenshot of the error. When I was working with it, I discovered
that if you type in the address, it works fine, but If I start at file:/// and
then click on the image, the scrollbars are never created.

Comment 4

[pnunn]

This looks like a job for <tahdah>__Frame Person__!
Patrick, is this in your backyard or should it go
to Troy?? just guessing..
-pn

Comment 5

[Eli Goldberg]

I can't reproduce this on any platform, using 1999 12.2.99 and 1999 12.3.99 AM
builds.

[e-mail], can you still reproduce this on a current (e.g. within 72
hours) build? If so, could you please attach a test case to this web page?

Comment 6

[Chris Moyer]

I recreated this bug with BUILD ID: 1999120216



I have added a URL, which demonstrates this error on my system, and also a new

screenshot of the error, and the actual image.



I've noticed that this error only seems to happen less than 50% of the time when

the image is at an http:// address, but aways happens on my system for a file://

address.  I will also attach  the image from my system that I used for the

screenshot.

Comment 7

[Chris Moyer]

Attachment: Shot of an image, without scrollbars, and the whole image in gqview.

Comment 8

[Chris Moyer]

Attachment: Image used to create the above erro shot.

Comment 9

[Chris Moyer]

After uploading the attachments, it appears that the problem _only_ occurs when
viewing an image on the local computer.  I don't know if th eimage is dealt with
differently then.

Comment 10

[Eli Goldberg]

Thanks for the specific test case and additional information! Will try to
reproduce now...

Comment 11

[Eli Goldberg]

Unfortunately, I still can't reproduce this on any platform using the 1999120608
build, including on Linux. Any words of brilliance, Patrick?

I've added mcafee to the CC: list, in case he might know of configuration
differences off the top of his head which could possibly trigger this bug.

It may also be worth mentioning this during tomorrow's BugDay and see if anyone
else can reproduce it.

Comment 12

[Patrick C. Beard]

Works on MacOS. Kicking to pavlov to see if it is still a problem on linux... If
pavlov can't reproduce, close it.

Comment 13

[Peter Trudelle]

Works fine using today's opt comm bits on RH 6.1, resolving as wfm.

Comment 14

[Eli Goldberg]

I'm rubber-stamping this as Verified/WORKSFORME with guilt; [e-mail], if
you can find any way this could be reproduced in Mountain View on a current
build, we can re-open it.

Otherwise, there's no way a developer (at least, in this building ;) could fix
it.