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)

defect

Tracking

()

VERIFIED WORKSFORME

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.
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.
Assignee: trudelle → danm
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
Assignee: danm → syd
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.
Whiteboard: [PDT-]
yes a bother, but no mandatory for dogfood.  Please check in fix. Putting on
pdt- radar.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Fixed 1.12.00
syd: you shouldn't need to add onunload handlers. if you do, that means that
your window is leaking the nsXULDocument.
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.
you shouldn't need to do that. if you do, check the bloaty output and see if
you're leaking an nsXULDocument.
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Summary: [DOGFOOD]Window size not remembered for Seamonkey Components → [DOGFOOD][DEP] Window size not remembered for Seamonkey Components
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.
scalkins: that is already logged as bug 14513.
Depends on: 14513
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.
hmm. i thought that *browser* window size was correctly remembered on mac. is
it not?
It is..in the testcase above i put: -
Mac: Mozilla window size is remembered, but Aim, Mail and Composer window size
resets to defaults.
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?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
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.
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.
QA Contact: paulmac → sairuh
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
*** Bug 25923 has been marked as a duplicate of this bug. ***
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
Putting dogfood in the keyword field.
Keywords: dogfood
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
Using M13 (27-JAN-2000) on Win98, none of the components seem to remember
if they were maximized.
->jrgm
QA Contact: sairuh → jrgm
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.
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.
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?
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()?
Target Milestone: --- → M16
Putting on [dogfood-] radar.
Whiteboard: [PDT-] → [dogfood-]
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.)
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
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
(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.
verified worksforme
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.