Closed Bug 85946 Opened 23 years ago Closed 23 years ago

file picker isn't resizable on OpenVMS

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
OpenVMS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: timeless, Assigned: bryner)

Details

Attachments

(1 file)

Patch to make window resizable
701 bytes, patch
Details | Diff | Splinter Review 
based on Bug 70915 Downloaded file not moved from temp to final destination 

------- Additional Comments From Theo Jakobus 2001-04-04 07:34 -------
I activated "Open File..."
I changed Files type from "HTML" to "All" (this window should be resizable!)

This is quite possibly an OpenVMS issue, if QA comes to this conclusion, please 
select assignee: colin@theblakes.com and qa: jakobus@iaf.fhg.de
I don't know what kind of window the "Enter name of file to save to..."
window is, but it certainly isn't resizable the usual way (by grabbing an
edge and enlarging/shrinking). I'm not so sure that this is an OpenVMS
bug though. I think it may be a feature of the type of GTK window being used.

As a workaround, you CAN resize the window by right-clicking on the window's
title bar and selecting "Size".
->bryner, Mr File Picker. [i presume openVMS uses the xul file picker...]
Assignee: blake → bryner
Keywords: qawanted
> [i presume openVMS uses the xul file picker...]

Yes. Its a pretty standard UNIX-like port. Uses GTK 1.2.8.

Colin.
Yes, it's resizable on Linux.   I'm not the right owner for an openvms-specific
bug, since I have no access to openvms.

Some windows in Mozilla on OpenVMS are resizeable by grabbing a corner or any
edge and dragging. All of the "main" windows in the browser, composer, and 
mail are resizable.

But many (all?) of the other windows such as file save as, file open, and even
the prefs panel, are NOT resizable in this manner. It must have something to
do with the way the windows are created (if its a top-level or not?).

Why are the non-top-level windows in Linux resizeable? Does the OS make ALL
windows resizeable perhaps?
Here's what I see on OpenVMS (UNIX build, using GTK 1.2.8, on top of 
XWindows/MOTIF). Note that I am not a GUI person, so I desperately need
some help here.

The main browser, composer, and mail windows (are these superwins?) all have
a title bar with a "-" symbol in the left corner (clicking on it pops up a menu
containing Move, Size, Minimize, Maximize, Lower, etc) and "." and square
symbols in the right corner (clicking on "." minimizes the window and clicking
on the square maximizes the window). These windows are all resizable by 
dragging on an edge or corner. The visual clue that you are able to resize by
dragging in that the corners of these windows look like they've been broken
off and then glued back on (there's a small gap where they don't quite join!).

Other windows/dialogs do not have the "-", ".", and square in the title bar, 
do not have the broken corners, and are not resizable by dragging. These
windows always appear to be sub-windows, for example, if I'm in a browser 
window and bring up a FIND dialog, the FIND dialog is not resizeable. But if 
I minimize the browser window then the FIND dialog gets minimized with it (and
both share the same icon on the desktop).

So it appears that Mozilla is creating the FIND etc dialogs WITHOUT specifying
some kind of resize attribute. Do this make sense?

cc'ing Mr Blizzard since he understands all this GDK/X/Superwin stuff and I 
don't have a clue.
I did some debugging in nsWindow::ConvertBorderStyles.

For a regular window bs comes in as eBorderStyle_all and so we set 
GDK_DECOR_ALL. But for something like a FileOpen window bs is a mask containing
eBorderStyle_border and eBorderStyle_title. Note the eBorderStyle_resizeh,
_menu, _minimize, and _maximize are NOT defined. So this is why these windows
are not resizeable on OpenVMS.

In the debugger I forced bs to eBorderStyle_all for a FileOpen window and sure
enough I then get the "-" in the title bar, the "broken corner" effect, and
I can resize the window by dragging an edge/corner (but I still didn't get the
"." and square in the right of the title bar).

So, it looks to me like Mozilla is purposely NOT making the file picker (and
many other) windows resizeable. Maybe this should be a bug against Linux 
because the windows ARE resizeable there!
most likely the window manager on linux which you looked at was ignoring the 
styles.  This isn't uncommon.

However, the file picker really should be resizable, MSOfice (except 2k), 
WPOffice, W2k Notepad (and all native w32 apps that use std common dialogs) 
have sizable open/save dialogs.
Should I change the OS on this bug report so that it gets a little more 
visibility? Its certainly NOT an OpenVMS specific problem.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
0.9.6? There might not even be such a release!

Any chance this can get done before 1.0 ships? Give me some pointers and
I'll work on it!
The place to start on this would be to look at the chrome flags that are used
when the filepicker dialog is opened, in nsFilePicker.js:

"chrome, modal, titlebar, resizeable=yes, dependent=yes"

Obviously, the "resizeable=yes" isn't quite working as intended.  You should
trace through where those chrome flags are handled (in windowwatcher, I'd guess)
and see how that is converted to calls on the nsIWidget for the window.



Brian, thanks for the EXCELLENT pointer. You'll never guess what the problem
was. I'll submit the patch next for your approval. Hopefully we can still
squeeze this in to 0.9.4.
r=bryner
Don Melton, you're listed as XPFE owner, could you give me an approval
to check this in please.
Whiteboard: waiting for approval
Don left for greener pastures quite some time ago.  We don't really have a
module owner nowadays.  But for what it's worth, you've got my approval.
Mailed drivers for checkin permission.
Whiteboard: waiting for approval → waiting for approval from drivers
Hang on, this still need an sr=.

Ben, Blake, can one of you two sr this for me. Thanks.
Whiteboard: waiting for approval from drivers → waiting for sr
We should also figure out what to do in the other places where "resizeable" was
used instead of "resizable"....

a=asa on behalf of drivers
hm. how nice. sr=blake. can you file a bug on remaining instances of 'resizeable'?
checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Thanks for checking this in, Brian. I see also that you entered bug #96786 to 
track the other instances of "resizeable".
Keywords: qawanted → verifyme
QA Contact: sairuh → nobody
vrfy fixed
1.26 <bryner@netscape.com> 23 Aug 2001 23:53
Status: RESOLVED → VERIFIED
Whiteboard: waiting for sr
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: