Open Bug 27795 Opened 25 years ago Updated 2 years ago

Add resizing grippy to bottom-right of Windows windows

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: deanis74, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 file)

Windows sizing grippy image
106 bytes, image/gif
Details 
From Bug Helper:
User-Agent: Mozilla/4.7 [en] (WinNT; U)
BuildID:    2000021416
For any resizeable Windows window, there is a resizing grippy in the 
bottom-right corner.  Mozilla lacks this grippy, which means that you have to be 
extremely precise when you're trying to grab the bottom-right corner to resize 
the window.
Reproducible: Always
Steps to Reproduce:
Start the browser.
Actual Results:  There should be a grippy in the bottom-right corner of the app 
window, along the status bar.
Expected Results:  There is no grippy.  The user has to grab directly on the 
window frame in order to resize.
N4.x had this as well as all my WinNT apps. Basically the bottom bar on all my
apps are gray and the bottom right corner has a triangle set of marks that are
used as a grab point for resizing the current window.
URL: any
Component: Browser-General → User Interface: Design Feedback
Should this be marked 4xp?
german, are you going to put a grippy in seamonkey?
Assignee: leger → german
QA Contact: cbegle → elig
Yes this would be a reasonable thing to request, though I am not sure who to
forward this bug to, since it has nothing to do with XUL or any other XPFE stuff
or even the Ui spec. Its a native window in win32 we are talking about, so in
lack of any further knowledge I am going to forward this one to Peter's group
(XPFE toolkit).
Assignee: german → trudelle
I don't think that there's a window style to accomplish this.  I think that I 
can draw the sizing grippy and then respond to the WM_NCHITTEST message.  I'll 
look into this angle.
reassigning to danm as p3 for m18. Dean, let us know if you come up with a fix
for this.
Assignee: trudelle → danm
Target Milestone: M18
I'm halfway there, but I'm feeling pretty dumb right now.  I have the sizing box 
painting for every single nsWindow - buttons, scrollbars, etc.  How the heck do 
I limit it to the top-level windows (eg. browser, composer, ...).  I tried 
checking mIsTopWidgetWindow but that didn't get me much further.  I know I'm 
missing something really really simple.
As you've noticed, mTopWidgetWindow is true for a lot of windows inside the 
actual top-level window. That's not useful to you. I don't know what you're 
planning, but you may want to try just using ::GetParent. You may also want to 
think about adding a different flag to the window that actually means top-level 
the way you want it to.

Mass moving M18 bugs to M19
Target Milestone: M18 → M19
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt
QA Contact: mpt → claudius
Summary: there is no resizing grippy in the bottom-right corner of any window → Add resizing grippy to bottom-right of Windows windows
This is Windows only, so I can't QA it, sorry. Claudius?

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
Target Milestone: M21 → Future
Keywords: helpwanted
*** Bug 62913 has been marked as a duplicate of this bug. ***
[--> XP Toolkit/Widgets]
URL: http://msdn.microsoft.com/library/def...
Component: User Interface: Design Feedback → XP Toolkit/Widgets
QA Contact: claudius → jrgm
Rather than force-painting a native widget in the bottom right corner, can we
have a XUL widget for this purpose? That way it could be made skinnable and
would blend in better.
This doesn't sound too bad.  If there's no XUL widget specified, would it be 
possible to paint the native widget?  Or wait, maybe we don't want that.  Should 
it be up to skin designers to decide whether they want the grippy?
On Windows the grippy is part of the window border, so it should only be 
skinnable if the window border is also skinnable, and it isn't.

Some of Mozilla's dialogs on Mac OS have an equivalent natively-drawn grippy, 
and it blends in quite well with Modern without needing to be skinnable.
I say go ahead, make it skinnable.  We have to start skinning the window 
sometime.
Filed bug 65008 for implementing this feature on BeOS. Not all apps in BeOS have
a resising grippy (I don't think Opera and NetPositive do) but the ones that do
have it are a lot easier to resise.
There's just one slight problem...
Some windows have the taskbar at the bottom, others the status bar.
So I think any solution has to include XUL, so that the right widget is shown.
Well both the taskbar and the statusbar have room for the resizing widget so
that shouldn't be a problem. But well have to make sure that the widget is only
drawn on windows that are resisale and have a status bar/taskbar.
I would rather not see the status bar leave space for the widget "in case".
I would like the resising widget to be defined in XUL so as to be skinnable and
automagically appear on the taskbar or status bar as and if appropriate.
Leaving space for the resizing widget is useful as it also solves another
problem. When you were scrolling down and the security icon was immediately
below the scrollbar then it was easy to accedentially click.
On Windows the grippy is part of the window border, so it should only be 
skinnable if the window border is also skinnable, and it isn't, and it 
shouldn't be. Please, let's keep this bug focused on making Mozilla better (by 
adding the grippy), not making it worse (by skinning the window border).

Why should this be restricted to windows which have a status bar? Why not all 
resizable windows?
The only reason I said have it on windows with a status bar/taskbar is otherwise
we have the problem of it eating into content. I don't think any windows apps
have the resizing widget where there's no statusbar. Perhaps we could have it in
a window where there's a horizontal and vertical scrollbar because there's a
blank corner. Buy when there's only one scrollbar what do we do? The resizing
widget would cover part of the scrollbars buttons.
When you turn off the status bar in folder windows (probably other windows too),
the grippy disappears.
Technically, the grippie is traditionally part of the status bar (or "status 
window" as it's refered to in developer docs), which is why it disappears when 
you hide the status bar.  "You can specify the SBARS_SIZEGRIP style to include 
a sizing grip at the right end of the status window."

Of course, there's at least one window in Win2000 that has a grippie and no 
status bar, the open/save common dialogs.  So the common coupling seems to be 
going away.
*** Bug 77694 has been marked as a duplicate of this bug. ***
*** Bug 86801 has been marked as a duplicate of this bug. ***
A recent checkin has introduced a XUL element <resizer class="window-diagonal">
although it doesn't have a binding yet so it's invisible...
Can you give a pointer to that check-in?  I'm kinda curious...
Dean, I believe you're looking for bug 80265.
This is now visible on Windows XP (not tried any other version), however the
grippy remains even if the window is maximised.
What's the status of this bug?  If it works for winxp, how hard can it be to get
it in win98 and windows 2k?  Wouldn't it be just a matter of changing a graphic
and flipping a switch?
With Jan 6 builds, I have noticed that a grippy is now present in windows 2000.
 However, windows XP now has the windows 2000 style grippy, whereas before it
had a native looking graphic (several dots instead of diagonal lines).
Okay, first off, this bug is one step closer to getting fixed.  I personally can
confirm that the grippy is present in WinXP and Win2k.  However, the XP grippy
now has a bug where it is displaying the Win2K graphic.  

Since there have been no comments posted to this bug, I will assume that
whomever is working to fix the grippies is not following it.  I have done a
search with the term "grippy" nad found no others that refer to this resizing
grippy.  

Therefore, unless someone has a better idea, I'm gonna file a new bug on this
graphic issue before the code is in there too long.
My guess is the grippy on sub-XP Windows is due to bug 172751 being fixed on Dec
3.  Cc: Tim Hill

Tim: Any chance you fix for that bug caused comment 36?
Are you talking about the Classic skin or the Modern skin?  The Classic skin 
should have right resizer graphic for your OS.  The Modern skin isn't really a 
native skin, so it simply uses a graphic (which happens to look like the 
Windows 2000 style resizer) -- bug 184169.  If you want a different graphic, 
you can file a separate bug for that.
Okay Tim, but the only thing is that the resizer *USED* to match the native
theme.  Looks like a bug to me, unless they're purposefully trying to make their
theme look old.
wfm (classic theme)

*** Bug 80265 has been marked as a duplicate of this bug. ***
I suggest to change the title of this bug to:
"Add a resize grippy to bottom-right of Windows and OS/2 windows and dialogs"

This will help users find this bug and prevent dupes. 

We should also include resizable dialogs (or resizable windows without a
status-bar). Here are several typical examples where the grippy is invisible
(suggested in Bug 198388):

* Popup Exceptions dialog
* Customize Character coding dialog
* Form Manager
* Cookie Manager
* Image Manager
* Password Manager
* Javascript Console
* DOM Inspector
* Source Viewer

Why would we want to hide such an important UI feedback?

Prog.
I would appreciate if someone could explain the relationship (if there is one)
of this bug with bugs related to the windowFeature resizable of sub-windows. Bug
87972, bug 101509 and bug 177838.
Also, I'd like to point out that other bugs affect the actual display, visual
rendering of the window resizing grippy in the statusbar.

window.open(strURL, "", "width=316,height=158,resizable,status");
or any width < 316 will make the sub-window clip the right most part of the
statusbar, therefore the entire resizing grippy.

window.open(strURL, "", "width=400,height=134,resizable,status");
or any height < 134 (or any outerHeight < 178) will make the subwindow clip the
bottom most part of the window, therefore the entire statusbar.

The thing is: the requested sizes of a popup window have (thanks to bugs) a
decisive impact on the ability for an user to see and use the widget by which he
could resize a rendered window with inappropriate/unsatisfactory/insufficient sizes.

4 screenshots demonstrating all this are available, if necessary.

XP Pro SP1, Moz 1.3final (build 20030312) here.
Assignee: danm.moz → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: