360880 - Some pages which need no zooming (or should shrink) to fit content instead maximize to screen

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect, P3)

Description

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

STR:

1. Visit http://www.caminobrowser.org/start/ (in a sufficiently large window that there are no scrollbars)
2. Zoom

Expected: No change (or shrinking, were that implemented)
Actual: Window maximizes to screen

Again, not sure how common this is. 1.1 for now, but like bug 360878, an early candidate to be kicked.

about:bookmarks, about:blank, about:config, and about:history also exhibit this problem.

Comment 1

[Torben]

For about:blank this is the designed behaviour, I would have prefered doing nothing but was outvoted (Bug 155956 comment 81 and Bug 155956 comment 83). This is easy to change should we change our mind.

about:bookmarks, and about:history behaves strangly, maximizing to screen was the least buggy behaviour I could come up with :-( about:config and http://www.caminobrowser.org/start/ should have worked fine, I'll look into it tonight.

Comment 2

[philippe (part-time)]

Attachment: test case, quirks mode

I got really strange effects when checking that c-b.o page. That page is in Quirks Mode, and all the contents is in an absolute positioned block.
When I remove the margin rule on the body element, the contents part of the window collapses to something like 10px tall. It doesn't matter how much content there is.
If margins are specified the old style way: marginwidth="0" topmargin="0" leftmargin="0" marginheight="0" is appended to the body tag, then the behaviour is as described in comment #0.
If margins are specified in the stylesheet, the window also collapses.

If that page is in Strict mode (using a full doctype) then 'zoom' has absolutely no effect, as long as the window is larger than the content (no scrollbars).

Comment 3

[philippe (part-time)]

Attachment: test case, margins on body, quirks mode

This test case may be more common than the previous one

Comment 4

[philippe (part-time)]

(In reply to comment #2)
> If margins are specified in the stylesheet, the window also collapses.

correction: if margins are specified, except 'margin:auto' (used by that c-b.o page).

Comment 5

[Chris Lawson (gone)]

*** Bug 361049 has been marked as a duplicate of this bug. ***

Comment 6

[Stuart Morgan]

Would it make sense to never shrink vertically when zooming?

Comment 7

[Ben Willmore]

I guess this belongs here, though the behaviour is different from that described.

The new zoom behaviour doesn't work with Gmail.  E.G:

* Log in to Gmail
* Shrink window down horizontally and vertically
* Click zoom

Actual: Nothing happens
Expected: Resize to fit contents

[IMHO, even the expected behaviour makes little sense in a tabbed browser, where each tab has a different size content.]

Comment 8

[Ben Willmore]

The behaviour is also peculiar on http://guardian.co.uk

1. Go to guardian.co.uk
2. Shrink the window way down.
3. Toggle zoom. The window toggles between the size you resize to and the content width.  Good so far.
4. Now expand the window to fill the screen.
5. Toggle zoom.  Currently, for me, nothing happens.  I believe I have also seen the window toggle to another size, with an inch or so vertical margin around the content.

Expected: Zoom-to size should depend only on content size, not on current window size.

Comment 9

[Ben Willmore]

metafilter.com also behaves poorly.

1. Go to metafilter.com
2. Shrink the window as narrow as it will go
3. Hit zoom repeatedly.
4. The window width increases in small steps up to some maximum (still quite narrow) width.  Then it goes back to as-narrow-as-it-will-go.  The cycle repeats.

Comment 10

[Paul Borokhov (lensovet)]

(In reply to comment #6)
> Would it make sense to never shrink vertically when zooming?
well, considering the amount of problems it's probably causing, i'd guess so. after all, we're viewing webpages here, not photos, so yes, i think that zooming vertically should simply switch between full-screen and user-set sizes.

Comment 11

[Torben]

Re comments 7 - 9, none of these are this bug:

Comment 7 is that we never reduce the width, ATM there is no way to get a smaller than window width from gecko :-( This may (or may not) change when the reflow-branch lands (see bug 360765).

Comment 8 is that we don't handle frames very well. I'm not sure what the best solution here is, for some pages (ie gmail) increasing to screen height makes sense but not always.

Comment 9 is strange, I'm not sure exactly is happening but this might be fixable.

http://www.caminobrowser.org/start/ for some reason returns 0 as its scrollHeight, this is the same I noticed in bug 155956 comment 101. about:config fails earlier in GeckoUtils::GetIntrisicSize, I'll add some more debugging code to see if I can figure out what's going wrong.

The testcases in comments 2 and 3 really belong in bug 361049, even though we get a strange height it is not 0. I'll reopen bug 361049 to look into this.

As for comment 6 and 10, never reducing the height will not fix this bug (but is an easy soution for bug 361049).

Comment 12

[Ben Willmore]

>Comment 7 is that we never reduce the width, ATM there is no way to get a
>smaller than window width from gecko :-(

In that case, there is no way that the zoom button is going to behave in the standard OS X way.  When I click zoom, I expect the window to toggle between two states.  Now, in Camino, clicking zoom sometimes toggles, and sometimes does nothing.  Unless I know that there's no way to get a smaller than window width from gecko, I cannot predict what zoom is going to do.

IMHO this is less intuitive, and less OS-X-like, than the old behaviour, which at least toggled between 'user size' and 'big enough for the content', even though 'big enough for the content' was really full screen.

Comment 13

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

FIXED by checkin of patch in bug 361049.

Comment 14

[froodian (Ian Leue)]

Is it actually?  I was under the impression (given comments 9 and 11) that this bug wasn't fixed by the patch that was reviewed and landed.

Comment 15

[froodian (Ian Leue)]

(sorry, that's bug 361049 comment 9 and 11)

Comment 16

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

Oops, I followed the wrong link :(  Sorry.

Comment 17

[Torben]

Attachment: WIP (from bug 361049)

Moving the earlier patch from bug 361049 here so it don't get lost. Will not apply to current trunk/branch, I'll update after christmas.

Comment 18

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

Torben, will you have a chance to work on this in the next month or so?  We're moving it to 1.2 for bookkeeping, but we'd like to get it for 1.1.

Comment 19

[Torben]

> Torben, will you have a chance to work on this in the next month or so?

I hope so, however, I've just moved and ATM have no internet conection at home, so no promises.

Comment 20

[Mike]

> Comment 7 is that we never reduce the width...

That is not how I read it. 
1. Open Camino [I am using Version 2007050909 (1.5)] 
2. Navigate to 
http://mail.google.com/
or 
http://download.sketchup.com/sketchuphelp/gsu6_mac/gsumac.html
3. Make the window as small as possible
4. Click the Zoom button
5. It does nothing

Expected: Enlarging to window to proper size.

Something with these Google pages does not allow for enlarging of the window to fit the content.

Comment 21

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

Mike, could you file comment 20 as a separate bug please?  It's almost comment 8, but as torben notes elsewhere, not this bug (and we need to begin unravelling this bug so it stays fixable).

Comment 22

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

Setting priority per 1.6 roadmap.

Comment 23

[Samuel Sidler (old account; do not CC)]

Torben, we'd really like to get this in 1.6. Do you have time to finish your work in the next month?

Comment 24

[Torben]

(In reply to comment #23)
> Torben, we'd really like to get this in 1.6. Do you have time to finish your
> work in the next month?

I'll try to do this at the end of the month, but no promisses.

Comment 25

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

Pushing off; at this point, it's probably too risky to take a patch for this for 1.6 :(

Comment 27

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]