308445 - image scaling (zooming) breaks with window resize

Status: NEW

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Ulrik Sverdrup]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050911 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050911 Camino/1.0a1

Camino automatically scales large images to fit the window. When opening just an
image in a new window (from a link), and the window is resized, Camino behaves
strangely.


Reproducible: Always

Steps to Reproduce:
1. Go to a location where a large image is loaded into a smaller new window
(like the URL above)
2. Click the link
3. Resize the window (make it smaller for best effect)
4. Click the image to zoom in and out some times.

Actual Results:  
Many bad things happen: the image is not fitted to the window, parts are not
visible. When the image is zoomed in, scrollbars might not appear.
After zooming in and out Camino gets stuck and you can't zoom in or out anymore.

Expected Results:  
The image should fit to the window (zoom out style), or present scrollbars to
enable viewing of all parts of the image (zoom in style).
Camino should not "become stuck" or send the origin of the image (thinking about
the upper left corner) around in the browser view.

Comment 1

[Ulrik Sverdrup]

This bug is enabled by Camino letting you resize all pop-up windows where other
browsers might not let you. I don't think we should take away that great feature
(but prehaps show a resize widget?)

Comment 2

[Ulrik Sverdrup]

(spamming)
The zooming is dependent on where you click in the image; if you click in the
upper left corner, the image is correctly positioned (although no scrollbars are
created when needed)

Comment 3

[Wevah (Nate Weaver)]

I think this is because our default "image" page (the pseudopage shown when we
display a single image) has a non-zero margin/padding. See also bug 160627
(though scrollbars=no works in Camino now).

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Wevah: so is this essentially a dupe of the remaining issue (non-zero
padding/margin) in bug 160627?

Comment 5

[Wevah (Nate Weaver)]

I think it's that plus comment 1.

Comment 6

[Ulrik Sverdrup]

The easiest way to fix this is to make camino bring out those scrollbars when
they are needed. The issue is partially a regression from a change where we
removed scrollbars from pop-up windows.

And then we also need to fix the reason to why it gets stuck after multiple
resizes and zooms, but I don't know the way to fix that.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Ok, it seems to be enough little pieces of this and that and itself to be its
own NEW bug :-)

Comment 8

[Wevah (Nate Weaver)]

(In reply to comment #6)
> The easiest way to fix this is to make camino bring out those scrollbars when
> they are needed. The issue is partially a regression from a change where we
> removed scrollbars from pop-up windows.

Not showing scrollbars is intended behavior if scrollbars=no is specified in the
JavaScript.

> And then we also need to fix the reason to why it gets stuck after multiple
> resizes and zooms, but I don't know the way to fix that.

This should be fixed if it does occur, though I can't reproduce it. (I did
manage to cause a crash by clicking around, though, so I have a bug to file on
that...)

Comment 9

[Wevah (Nate Weaver)]

I do think the main issue here *is* in fact bug 160627. Safari's "image only"
windows have the image hugging the top-left corner (as opposed to having
non-zero margins like we have).

Comment 10

[Ulrik Sverdrup]

(In reply to comment #8)
> (In reply to comment #6)
> > The easiest way to fix this is to make camino bring out those scrollbars when
> > they are needed. The issue is partially a regression from a change where we
> > removed scrollbars from pop-up windows.
> 
> Not showing scrollbars is intended behavior if scrollbars=no is specified in the
> JavaScript.
In that case, we should also disable image scaling. Or: Keep current (nice)
behaviour but stay responsible, that is display the scrollbars after we change
image and viewport size (not intented by the creator of the site, so the browser
must itself take responsible after that point)

(In reply to comment #9)
> I do think the main issue here *is* in fact bug 160627. Safari's "image only"
> windows have the image hugging the top-left corner (as opposed to having
> non-zero margins like we have).
We should keep the behavior of zooming in to the area where the user clicked.
However, the image boundaries should not lose contact with the window boundaries
(if not the image is smaller than the window bounds; in this case the image
should be just as large or larger as we're toggling between normal and zoom out)

Comment 11

[Wevah (Nate Weaver)]

(In reply to comment #10)
> Or: Keep current (nice)
> behaviour but stay responsible, that is display the scrollbars after we change
> image and viewport size (not intented by the creator of the site, so the browser
> must itself take responsible after that point)

It used to be like this. This was changed on purpose. See bug 232765
(disclaimer: I filed it).

> (In reply to comment #9)
> > I do think the main issue here *is* in fact bug 160627. Safari's "image only"

> We should keep the behavior of zooming in to the area where the user clicked.
> However, the image boundaries should not lose contact with the window boundaries
> (if not the image is smaller than the window bounds; in this case the image
> should be just as large or larger as we're toggling between normal and zoom out)

I agree with you here. If the user clicks in the lower-right corner of the image
to zoom, the corner of the image shouldn't move any farther left or up than the
lower-right corner of the viewport.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #11)
> I agree with you here. If the user clicks in the lower-right corner of the image
> to zoom, the corner of the image shouldn't move any farther left or up than the
> lower-right corner of the viewport.

Gecko behavior seems to be to center the point where you clicked to resize
(i.e., "zoom in here", even if there's only one level of zoom) when displaying
the resized image, which is fine when there are scrollbars :-)

You can get out of the "stuck" problem, BTW, by using the arrow keys to scroll
back to the top-left corner.

Comment 13

[Simon Fraser [no longer active]]

I can't easily reproduce this on the given url.

Comment 14

[Simon Fraser [no longer active]]

Happens in FF too (it's just not so obvious because you can't resize the window).

Comment 15

[Boris Zbarsky [:bzbarsky]]

So what exactly is the bug here?  I can't tell from all the discussion.

If this is a NEW layout bug, it needs a minimal testcase attached to the bug.  I don't see one.

Comment 16

[Simon Fraser [no longer active]]

(In reply to comment #15)
> So what exactly is the bug here?  I can't tell from all the discussion.

The bug is that the image scaling code centers the actual-size image on the locatino where you clicked, which may cause the top-left of the image to disappear. In a window without scrollbars, this is bad.

Comment 17

[Boris Zbarsky [:bzbarsky]]

But in a window without scrollbars part of the image will just not be reachable no matter what, right?  Or am I missing something?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Put another way, what is the proposed behavior change here?

Comment 19

[Simon Fraser [no longer active]]

Attachment: Testcase

Comment 20

[Simon Fraser [no longer active]]

(In reply to comment #18)
> Put another way, what is the proposed behavior change here?

The reporter is proposing that we should show scrollbars in this case.

Comment 21

[Boris Zbarsky [:bzbarsky]]

But how is this case different from any other "non-scrollable window with overflowing content" case?  If what we're proposing is that we just always show scrollbars on all windows, I suspect that won't really fly.

Comment 22

[Ioana (away)]

request answered in comment 19...