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...]

> [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.

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.

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.

Hang on, this still need an sr=.

Ben, Blake, can one of you two sr this for me. Thanks.

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.

Thanks for checking this in, Brian. I see also that you entered bug #96786 to track the other instances of "resizeable".

vrfy fixed 1.26 <bryner@netscape.com> 23 Aug 2001 23:53