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)
Tracking
()
NEW
Future
People
(Reporter: dean_tessman, Unassigned)
References
()
Details
(Keywords: helpwanted)
Attachments
(1 file)
(deleted),
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.
Comment 1•25 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•25 years ago
|
||
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
Reporter | ||
Comment 5•25 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•25 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•25 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.
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 10•25 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•25 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
Comment 11•25 years ago
|
||
This is Windows only, so I can't QA it, sorry. Claudius?
Comment 12•24 years ago
|
||
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
Keywords: helpwanted
Comment 13•24 years ago
|
||
*** Bug 62913 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
[--> XP Toolkit/Widgets]
Component: User Interface: Design Feedback → XP Toolkit/Widgets
QA Contact: claudius → jrgm
Comment 15•24 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•24 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?
Comment 17•24 years ago
|
||
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•24 years ago
|
||
I say go ahead, make it skinnable. We have to start skinning the window
sometime.
Comment 19•24 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.
Comment 20•24 years ago
|
||
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 21•24 years ago
|
||
Comment 22•24 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.
Comment 23•24 years ago
|
||
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•24 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.
Comment 25•24 years ago
|
||
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•24 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.
Comment 27•24 years ago
|
||
When you turn off the status bar in folder windows (probably other windows too),
the grippy disappears.
Reporter | ||
Comment 28•24 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•24 years ago
|
||
*** Bug 77694 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
*** Bug 86801 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
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•23 years ago
|
||
Can you give a pointer to that check-in? I'm kinda curious...
Comment 33•23 years ago
|
||
Dean, I believe you're looking for bug 80265.
Comment 34•23 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•22 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•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
wfm (classic theme)
Comment 42•22 years ago
|
||
*** Bug 80265 has been marked as a duplicate of this bug. ***
Comment 43•22 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•22 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•2 years ago
|
Severity: normal → S3
Comment 45•2 years ago
|
||
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)
Comment 46•2 years ago
|
||
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.
Description
•