Add resizing grippy to bottom-right of Windows windows

NEW
Unassigned

Status

()

defect
P3
normal
19 years ago
12 years ago

People

(Reporter: dean_tessman, Unassigned)

Tracking

({helpwanted})

Trunk
Future
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.

Comment 1

19 years ago
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
(Reporter)

Comment 2

19 years ago
Should this be marked 4xp?

Comment 3

19 years ago
german, are you going to put a grippy in seamonkey?
Assignee: leger → german
QA Contact: cbegle → elig

Comment 4

19 years ago
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
(Reporter)

Comment 5

19 years ago
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.

Comment 6

19 years ago
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
(Reporter)

Comment 7

19 years ago
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.

Comment 8

19 years ago
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.

Comment 9

19 years ago
Mass moving M18 bugs to M19
Target Milestone: M18 → M19

Comment 10

19 years ago
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

Updated

19 years ago
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?

Comment 12

19 years ago
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21

Updated

19 years ago
Target Milestone: M21 → Future

Updated

19 years ago
Keywords: helpwanted

Comment 13

19 years ago
*** Bug 62913 has been marked as a duplicate of this bug. ***
[--> XP Toolkit/Widgets]
Component: User Interface: Design Feedback → XP Toolkit/Widgets
QA Contact: claudius → jrgm

Comment 15

19 years ago
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.
(Reporter)

Comment 16

19 years ago
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.
(Reporter)

Comment 18

19 years ago
I say go ahead, make it skinnable.  We have to start skinning the window 
sometime.

Comment 19

19 years ago
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.

Comment 22

18 years ago
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.

Comment 24

18 years ago
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?

Comment 26

18 years ago
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.
(Reporter)

Comment 28

18 years ago
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.

Comment 29

18 years ago
*** Bug 77694 has been marked as a duplicate of this bug. ***

Comment 30

18 years ago
*** 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...
(Reporter)

Comment 32

18 years ago
Can you give a pointer to that check-in?  I'm kinda curious...

Comment 33

18 years ago
Dean, I believe you're looking for bug 80265.

Comment 34

18 years ago
This is now visible on Windows XP (not tried any other version), however the
grippy remains even if the window is maximised.

Comment 35

17 years ago
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?

Comment 36

17 years ago
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).

Comment 37

17 years ago
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.
(Reporter)

Comment 38

17 years ago
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?

Comment 39

17 years ago
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.

Comment 40

17 years ago
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.

Comment 41

17 years ago
wfm (classic theme)

Comment 42

16 years ago
*** Bug 80265 has been marked as a duplicate of this bug. ***

Comment 43

16 years ago
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.

Comment 44

16 years ago
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.

Updated

14 years ago
Assignee: danm.moz → nobody
You need to log in before you can comment on or make changes to this bug.