Closed
Bug 23773
Opened 25 years ago
Closed 24 years ago
[DEP] linux, mac: Window size not remembered for Seamonkey Components
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
VERIFIED
WORKSFORME
M16
People
(Reporter: scalkins, Assigned: slogan)
References
Details
(Keywords: platform-parity, Whiteboard: [dogfood-] worksforme blocked by bugscape #1001 -- no standalone AIM on mac)
All platforms: Win build 2000-01-12-11 M13 (NT) Linux 2000-01-11-10 M13 (RH 6.0) Mac 2000-01-12-08 M13 (Mac OS 8.6) Steps to reproduce: 1) Launch Seamonkey. 2) Open the Mail, AIM and Composer components via the Tasks menu. 3) Resize each of these components windows so they are very tiny, very slim, etc...such that you would notice if the change "took". 4)Either: a)Close the components window by dismissing it's window (i.e. via File -->Close, or clicking on the X in upper right corner of window)or b)Exit Seamonkey via File-->Quit 5)a)If you simply closed the component window, reopen it via the Tasks menu. b)If you closed seamonkey, relaunch Seamonkey and open the same components to see if the window sizes are the same. Expected results: Window sizes stay at the changed size when the components are re-opened. Actual results: Win: Mozilla window size is remembered, but Aim, Mail and Composer window size resets to defaults. Mac: Mozilla window size is remembered, but Aim, Mail and Composer window size resets to defaults. Linux: Mozilla, Aim, Mail and Composer window size all reset to defaults. Setting to dogfood for PDT review as it's very annoying to have to reset this every time I go into Seamonkey for each component.
Comment 1•25 years ago
|
||
I'll second the vote to make this dogfood. It's very annoying to have to resize every window every time one comes up, and it's very time consuming to have to decipher localstore.rdf every few weeks to see what the magic code has changed to to set the initial window sizes to something usable.
Updated•25 years ago
|
Assignee: trudelle → danm
Comment 2•25 years ago
|
||
This is annoying, but if it keeps anyone from using dogfood, then maybe they should stick to commercial releases. I wouldn't hold the beta for this, even though it bites me several times a day. reassigning to danm for triage, possible dup of 15775
Updated•25 years ago
|
Assignee: danm → syd
Comment 3•25 years ago
|
||
This is not a problem with the toolkit. Syd (or whoever does UI work for the IM components) needs to add persist="x y width height" to each of the task windows. That's it. akkana: there is another bug assigned to pavlov for the window sizes on linux. X does not properly update DOM attributes when the window size changes.
yes a bother, but no mandatory for dogfood. Please check in fix. Putting on pdt- radar.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 5•25 years ago
|
||
I added this ability to AIM. There's more to it than adding the persist arg to the window xul, however. You need to put JS in the load and unload handlers for each window as well.
Comment 6•25 years ago
|
||
Fixed 1.12.00
Comment 7•25 years ago
|
||
syd: you shouldn't need to add onunload handlers. if you do, that means that your window is leaking the nsXULDocument.
Comment 8•25 years ago
|
||
Maybe I'm using the wrong terminology. By onunload handler I mean the onunload arg to the window tag. That's OK, right? All the other top level xul files use them.
Comment 9•25 years ago
|
||
you shouldn't need to do that. if you do, check the bloaty output and see if you're leaking an nsXULDocument.
Reporter | ||
Comment 10•25 years ago
|
||
This is still a problem for all components on Linux comm rel build 2000-01-13-08 M13. Waiting on Mac and Win builds to see if problems persist there also. Reopening.
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Summary: [DOGFOOD]Window size not remembered for Seamonkey Components → [DOGFOOD][DEP] Window size not remembered for Seamonkey Components
Comment 11•25 years ago
|
||
This is because the infrastructure does not support this on Linux or Mac yet. Please find the bugzilla bug that is tracking it and reference it here.
Comment 12•25 years ago
|
||
scalkins: that is already logged as bug 14513.
Reporter | ||
Comment 13•25 years ago
|
||
waterson: bug 14513 is Linux only. Should I change it to All platforms [PP]to account for Mac? Also, should this bug be marked fixed, and should I open separate bugs for the components which still don't keep their sizes? Sorry for a buncha questions, but do appreciate everyones help.
Comment 14•25 years ago
|
||
hmm. i thought that *browser* window size was correctly remembered on mac. is it not?
Reporter | ||
Comment 15•25 years ago
|
||
It is..in the testcase above i put: - Mac: Mozilla window size is remembered, but Aim, Mail and Composer window size resets to defaults.
Comment 16•25 years ago
|
||
oh right. and amusil mentioned last night that he was seeing the "onunload" handler running before the "onload", which was clobbering values in one of the windows. hmm. alex: have you been able to figure out anything more?
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 17•25 years ago
|
||
I did not figure out why the onunload problem is happening. It happens for both our standalone App window and IM window, but not for the Navigator window. I put in a workaround that fixes it for now in our windows. I believe the state of platforms is this: - Windows: location and size remembered - Mac: only size remembered - Linux: nothing is remembered I think there should be 2 new bugs filed: - Position and Size hints not working on Linux - Position hints not working on Mac Plus, a bug needs to be filed for each component that does not support hints at all (which currently must be tested for on Windows due to the two bugs mentioned above). Since AIM now supports hints correctly and is only waiting for platform specific infrastructure to be working on Mac and Linux, I'm marking this bug fixed.
Comment 18•25 years ago
|
||
fwiw: remembering position and window size is on marketing's beta list. For mail windows, we'll review this and file any bugs as necessary as alex suggested.
Updated•25 years ago
|
QA Contact: paulmac → sairuh
Comment 19•25 years ago
|
||
this is sairuh's qa area on the browser side hey sairuh can you file bugs for anything not already covered in existing bugs? thanks
Comment 20•25 years ago
|
||
*** Bug 25923 has been marked as a duplicate of this bug. ***
Comment 21•25 years ago
|
||
not a problem using the 2000-02-01-08 comm bits on winNT. however, window size is not remembered on linux [2000-02-01-10 comm]. unable to test w/today's mac comm bits: used y'day's mac comm bits instead, but it still failed. reopening w/added platform parity.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [DOGFOOD][DEP] Window size not remembered for Seamonkey Components → [DOGFOOD][DEP][PP] linux, mac: Window size not remembered for Seamonkey Components
Updated•25 years ago
|
Keywords: pp
Summary: [DOGFOOD][DEP][PP] linux, mac: Window size not remembered for Seamonkey Components → [DEP] linux, mac: Window size not remembered for Seamonkey Components
Comment 23•25 years ago
|
||
Using M13 (27-JAN-2000) on Win98, none of the components seem to remember if they were maximized.
Comment 25•24 years ago
|
||
re: earlier comments that "window size is not remembered on Linux" ...it *is* remembered, at the wrong times. When logging out of "My Netscape" I got a small popup window with an advertisement in it; now any additional windows I open remember the size of the small window. All-too-reproducible, not to mention annoying.
Comment 26•24 years ago
|
||
The popup size becoming the browser window size is bug 28199. Aside from that, and from windows that don't bother to remember their window size (like the mail compose window, bug 28260), and that I never quit with a maximized window so I haven't tried that, otherwise window size has been working for me on linux.
Comment 27•24 years ago
|
||
Hmmm... In <window>, are the attributes named x,y or screenX,screenY? navigator.js:BrowserClose() seems to store the values in x,y while the persist in navigator.xul is on screenX,screenY. In Linux, screenX and screenY are stored in localstore.rdf with values -1, while in Windows the correct values are stored. Changing BrowserClose so it stores to screenX and screenY fixes Linux and works for Windows, which leaves us with my second question: why are attributes x and y equivalent to screenX and screenY under Windows?
Comment 28•24 years ago
|
||
Sorry for wasting a bit of your time there... I just realised that navigator.js:BrowserClose() is a dirty fix which only works when using File->Close and shouldn't be needed anyway. To answer my own question why it worked on Windows even though the wrong attributes were set: because it should work even without BrowserClose(). Again, sorry for increasing the noise/signal ratio. P.S. Until this is correctly fixed, is it worth adding that same dirty fix to navigator.js:Shutdown()?
Updated•24 years ago
|
Target Milestone: --- → M16
Reporter | ||
Comment 30•24 years ago
|
||
CLicking on X's and File-->Close to dismiss and then reopen seems to remember sizes fine on all platforms today (at least as far as AIM is concerned.)
Comment 31•24 years ago
|
||
Using today's opt. comm. builds: win32(95) : addrbook, composer, mailnews, browser, AIM all persist their size and position correctly mac (os9) : addrbook, composer, mailnews, browser all persist their size and position correctly AIM cannot be tested on Mac due to bugscape #1001 linux (rh6.1) : addrbook, composer, mailnews, browser, AIM all persist their size correctly Position is not persisted on linux, but that's bug #31086
Whiteboard: [dogfood-] → [dogfood-] worksforme blocked by bugscape #1001 -- no standalone AIM on mac
Updated•24 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 32•24 years ago
|
||
(Duh! make a command file, add '-aim', get standalone AIM on the mac) Okay, so now that I can test AIM on mac, it persists size and location correctly. So (modulo bug 31086) this is WORKSFORME.
You need to log in
before you can comment on or make changes to this bug.
Description
•