169550 - Help window must be <= 462px height by default

Status: VERIFIED FIXED

(SeaMonkey :: Help Documentation, defect)

Description

[Harold E. Russell]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1) Gecko/20020826

Menu select: Help>Help Contents 
The Help window runs out the top and bottom of my screen. 
I cannot get to the top of the window to resize or close it.
The present window appears to be sized for 640x480 or larger.
I have a Sony PCG-C1VN with a 1024x400 screen.


Reproducible: Always

Steps to Reproduce:
1.Menu select: Help>Help Contents 
2.
3.

Actual Results:  
The Help window runs out the top and bottom of my screen.

Expected Results:  
Use a conservative window size, e.g. 480x320, and let the user resize it if desired.

Please have pity on those of us who don't have acres of screen space.

Comment 1

[Skewer]

Interesting... it seems your hardware has an abnormal screen size of less than
480px height. I don't think you're going to get much satisfaction out of
dimensions that small, since even Windows' built-in dialogs tend to fall off the
screen at that size. However, Mozilla does need to be compatible with 640x480,
since that is a well recognized screen size. The Help window I'm seeing has
dimensions of 575x492. Confirming that to that end the help window is too large.

Comment 2

[Harold E. Russell]

Sorry, but there is nothing abnormal about my screen size and it works very well
for my needs; light weight, small footprint for business travel. It is a common
size amongst many subnotebook computers; Sony Picturebook, Toshiba Libretto,
etal. The 640x480 guideline is a maximum default not the minimum which you
imply. There are many fully functional windows in Linux, MSwindows, and other OS
GUIs that are less than 640X480. Also, you don't account for overscan which may
result in loss of edge pixels regardless of the manufacturers' claims of display
performance parameters. Furthermore, throwing up a window that hogs the entire
screen is both annoying and rude. I don't mean to sound harsh; a person, working
on say a 1600x1200 screen, can easily develop a nice looking window that won't
be usable on anything else. It's just a part of being human. "When you're up to
your **** in alligators, it is difficult to remember that your job is to drain
the swamp."

Comment 3

[Skewer]

The average control panel size in Windows XP is 400x450px. If your computer's
control panels are smaller, they were probably customized by the manufacturer so
they wouldn't fall off the screen. Regardless, we're really making a sacrifice
by adjusting for 640x480 displays. Anyone remember the anarchy in sizing the old
pref panels? We've reached a fixed size-562x462px. We could set the bar at 400px
height, but then someone would show up with a computer that has a 300px high
display and insist that we change it again.

If we resize the help dialog to 462px or less, it will be the same size as the
pref dialog, and satisfy the 640x480 requirement. Since Help is sizable, I would
also suggest that if the user's screen is less than the size of the Help dialog,
that it be set to a maximized windowstate or cropped by the dimensions of the
available screen space excluding key elements like the taskbar.

Comment 4

[Harold E. Russell]

The Preference window size works fine for me. The real problem is that essential
controls are at the edges of the windows and become inaccessible when moved off
screen. This is a flaw in MSwindows not Mozilla. Also, the Mozilla style guide
makes no reference to window styles and formats, maybe it should. A similar
problem exists in some Linux releases where I found that even on a default
desktop screen, some of the initial setup controls were out of reach and the
window couldn't be resized and relocated by the user. Remember that the original
Windows CE devices were 240 pixels high and with the rapid increase of PDA
networking small windows may become the norm. My Sony is 320x320, big for a PDA.
In order to survive one must be better than M$. As for WinXP, I'll go back to
pencil and paper first.

Comment 5

[Brant Gurganus]

I wonder if we can use sizing relative to the screen and then it should work
just about anywhere with satisfactory results.  Don't know if XUL allows that
though.

Comment 6

[Harold E. Russell]

BLG has a good point. I don't know if it is possible either. The real problem
seems to be two-fold: 1) The internal fields are fixed and do not allow window
resizing. 2) Scroll bars are not implemented; which would allow smaller windows
for those who need/want them and still keep the same interior format. The
nuisance of scrolling is minor compared to being unable to take any action
whatsoever.

Another solution, which may or may not be feasible, is to create a hotkey/mouse
combination that would allow a window to be repositioned from any interior point
instead of just the top bar. This could have beneficial implications in a wide
range of situations.

Comment 7

[Matthew T (active 1999-2002)]

This appears to be a duplicate of bug 117048, which may need to be reopened.

Comment 8

[Ian Oeschger (gone)]

moving stuff over to an outside-the-firewall email for the time being, looking
for people to pick these Help and doc bugs up for me.

Comment 9

[R.J. Keller]

--> me

Brant, talk to me on IRC about what you think about this.

Comment 10

[R.J. Keller]

This will be fixed for 1.6 alpha

Comment 11

[R.J. Keller]

==> brant

Is this worth our time and effort?

Comment 12

[Harold E. Russell]

Mozilla and everything else in the open source arena operates in a very dynamic
environment. It is frequently used in areas and applications where commercial
software is not and never will be available. When everything goes to Hell in a
handbasket, the lowest common denominator is 640x480 VGA. It ain't pretty, but
at least you have a starting point from which to get back to a working system.
Any critical control windows must fit in that area or else you will be sitting
in front of a useless pile of scrap metal and silicon. Given overscan and other
annoying hardware idiosyncracies, 600x400 VGA is probably a safe compromize for
working windows.

Comment 13

[R.J. Keller]

I think that help works with 640x480, but not 100% sure.

Brant might of already of fixed this and I never noticed. I'll have to check
with him.

Comment 14

[Brant Gurganus]

I think we can do something along these lines pretty easily.  I thought we had
already done it, but I guess not.

Comment 15

[R.J. Keller]

--> me

How did this go to Brant? I must've been tired when I reassigned this :) sorry
for  all the jumping around.

I'll see if I can cook up a patch for this.

Comment 16

[R.J. Keller]

Brant's too busy

--> me

Comment 17

[R.J. Keller]

-> Future

Comment 18

[R.J. Keller]

Attachment: Patch resizes window when appropriate.

If the help window is outside of the screen's width or height, resize the help
window to be 75% of the screen's width and height.

I haven't been able to test this patch since I can't seem to get the help
window big enough ;).

Comment 19

[R.J. Keller]

Comment on attachment 133529 [details] [diff] [review]
Patch resizes window when appropriate.

Neil, can you review this? I know that this is a somewhat controversial patch,
so tell me what you think of this change.

Comment 20

[Daniel Wang]

Comment on attachment 133529 [details] [diff] [review]
Patch resizes window when appropriate.

I think I can do r- :-p

const WINDOW_WIDTH = document.documentElement.getAttribute("width");
const WINDOW_HEIGHT = document.documentElement.getAttribute("height");

should be
WINDOW_WIDTH = window.width;
WINDOW_HEIGHT = window.height;

Comment 21

[R.J. Keller]

Attachment: Patch 2

Can't remember which one is correct.

Comment 22

[R.J. Keller]

Comment on attachment 133535 [details] [diff] [review]
Patch 2

caillon, can you review? I'd personally like you to review this one.

Comment 23

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 133535 [details] [diff] [review]
Patch 2

>
><HTML><HEAD/><BODY><PRE>Index: help.js
>===================================================================
>RCS file: /cvsroot/mozilla/extensions/help/resources/content/help.js,v
>retrieving revision 1.48
>diff -u -r1.48 help.js
>--- help.js	16 Oct 2003 08:17:06 -0000	1.48
>+++ help.js	17 Oct 2003 21:26:18 -0000
>@@ -127,6 +127,17 @@
> 
>   //Always show the Table of Contents sidebar at startup.
>   showPanel('help-toc');
>+
>+  //Check to make sure the help window isn't off the screen. If the width of
>+  //the window is off the screen, then resize the window to 75% of the
>+  //width and height of the screen.
>+  const WINDOW_WIDTH = document.width;
>+  const WINDOW_HEIGHT = document.height;

Why do you even need the temporaries?  Just use document.height and width in
the if check below, like you do for screen.avail*

But...


>+
>+  
>+  if (WINDOW_WIDTH >= screen.availWidth ||
>+      WINDOW_HEIGHT >= screen.availHeight)
>+    window.resizeBy(screen.availWidth * 0.75, screen.availHeight * 0.75);


I guess I don't really understand why we are doing this for this window, but
not for anything else.... My main concern is what if say only 25% of the window
is shown on screen, and you cut out that 25%?  I tend to move my windows around
like this sometimes to clear desktop space...  This might hide the help window
completely, which is not cool :-(


> }
> 
> function loadHelpRDF() {
></PRE></BODY></HTML>

Comment 24

[R.J. Keller]

Attachment: Better Patch ;)

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 133799 [details] [diff] [review]
Better Patch ;)

Better. :-)

Comment 26

[R.J. Keller]

Fix checked in.

Comment 27

[R.J. Keller]

Note to QA: This patch fixes the problem by changing the default width of the
help window to 480 and the height to 360. Because the help window size is saved,
you may need a new profile to see these changes.

Comment 28

[Daniel Wang]

v