Closed Bug 26834 Opened 25 years ago Closed 25 years ago

opened windows need sanity checks on size, position and visibility

Categories

(Core :: XUL, defect, P2)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: chriss, Assigned: saari)

References

Details

(Keywords: relnote, Whiteboard: [PDT+] 3/2 w/b minus on 3/7 - need machine to verify on)

Attachments

(1 file)

I started noticing this on 2/4 build. Problem still exists with 2/6 build.

Steps:
1. Install seamonkey
2. Launch seamonkey and pick profile (I have 2)
3. My home page appears to load based on the Win98 task bar, but no windows are 
visible. My screen resolution is 1024 x 768
Assigning bug to don. adding dogfood keyword
Assignee: leger → don
Keywords: dogfood
I tried reverting to M13 and still had the problem.
Then I deleted my seamonkey files, mozreg.dat file, and user50 folde and 
reinstalled M13. Now I can see the apprunner window.

I saved my mozreg.dat file and user50 file if those would be interesting.
It seems that some file was corrupted and starting with a fresh istallation 
fixed the problem.

Changing keyword from dogfood to beta1.
Keywords: dogfoodbeta1
Well, neither I nor others can repro this so I'm moving it out to M15 for later
investigation.
Assignee: don → law
Priority: P3 → P2
Target Milestone: M15
I can reproduce with by substituting my original prefs folder. I'll be happy to 
help show this on a QA machine.
gbush, can you check out please?  See chriss. Thanks!
Component: Browser-General → Profile Manager BackEnd
QA Contact: cbegle → gbush
Whiteboard: [PDT+]
Chris,

I would like to take a look at this-give me a call

Grace
I isolated the bug to the localstore.rdf file. I've attached a corrupt version 
of it. To reproduce the bug:
1) Rename your existing localstore.rdf file something else
2) Copy the attached file and rename it localstore.rdf
3) Start seamonkey - you should notice that the window doesn't appear

Also, I think I found a way to corrupt this file. When trying to connect to an 
IMAP server, but connection is taking a while, close the mail window. This 
results in a crash which corrupted the file.
That's localstore.RDF?
                  ===

Well, I know what to do with it now (although for a minute there I thought it 
should go to danm since it was the *window* that was invisible :-).

Chris; perhaps the root cause is in the IMAP code, but I suspect you're in a 
better position to know that.
Assignee: law → waterson
Uh, yeah. Sorry. If your localstore.rdf gets whacked, you're out of luck. 
There's not much I can do. Last I heard, danm/davidm were working on code to 
keep a window on the screen if it's coordinates got out of whack. So, I'm gonna 
give it to danm.
Assignee: waterson → danm
I was able to launch with this corrupt localstore.rdf file.  BUT the window was 
minimized - I had to maximize it- see bug 26581 for something similar.  
gbush: on my Win98 machine, swapping the file results in what looks like a 
minimized window, but if you click on it, nothing appears.

I would be happy if we dealt with off screen coordinates in a way that lets you 
see the window.
This ain't never been a profile manager backend bug.  Of the 2 million choices 
listed under components, I saw none that was completely obvious.  Someone please 
put this in the right component.  Thanks,  Steve
Component: Profile Manager BackEnd → other
Looks like this bug has morphed into "opened windows need sanity checks on size, 
position and visibility."
Status: NEW → ASSIGNED
Component: other → XP Toolkit/Widgets
Summary: Seamonkey launches but windows are invisible → windows are invisible with corrupt localstore.rdf
Target Milestone: M15 → M18
Taking danm's advice and making the bug description match what the bug really 
means. Removing PDT+ to see if this is really necessary for beta1. (It's not, 
IMO.)

PDT: the risk here is that someone will be able to open a window on a large 
display (e.g., 1024x768), move the window to the bottom right-hand corner of 
the display, change their display size to a smaller value (e.g., 640x480), and 
then not be able to see the window on a smaller display. Bad. But beta blocker?
Summary: windows are invisible with corrupt localstore.rdf → opened windows need sanity checks on size, position and visibility
Whiteboard: [PDT+]
Putting on the PDT- radar for beta1.  Would not hold for this.  We can relnote
the issue.
Keywords: relnote
Whiteboard: [PDT-]
Sorry, I think this is a beta stopper IMO.
This bug keeps hitting me on M13. It's especially bad when demoing the browser,
but also occurs in daily use. It does not result from changing screen resolution 
for me. 

The localstore.rdf file appears to be getting corrupted if the browser crashes.
The result is that on restart the browser doesn't appear. It has nothing to do
with resizing the screen resolution as Waterson suggests. I see this even when 
staying in the same resolution. I suspect that the fie corruption happens on 
Win95/98 bug and doesn't apprear on WinNT.

Clearing PDT-
Whiteboard: [PDT-]
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Putting on PDT+ radar for beta1.
I'll take this because it nails me on MacOS; I have a laptop that drives another 
monitor (two screens essentially) and if I run mozilla on the wrong screen, and 
then use just the laptop screen, the window appears offscreen.

Not to mention that I cannot use the right third of my external screen because 
someone thinks that is offscreen. If you try and move the window over there, it 
just pops back into place as if it dropped a bungie anchor.
Assignee: danm → saari
Status: ASSIGNED → NEW
Target Milestone: M18 → M14
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 2/21
Well this sucks, we persist only positive coordinates for window placement.



Hello, it is 2000 now, we have OSes with negative coordinate space. We have OSes

with non whole number coordinate systems. We should be persistig a signed float

instead of doing behind the scenes magic with our coordinate systems on MacOS.



I can make the window show up on screen, but not necessarily the right size, at

least on MacOS. Grumble grumble

Whiteboard: [PDT+] 2/21 → [PDT+] 2/24
Still needs more work
Whiteboard: [PDT+] 2/24 → [PDT+] 2/26
.
Assignee: saari → danm
Status: ASSIGNED → NEW
You stole this from the beetles, I'm stealing it back
Assignee: danm → saari
changed ETA date
Status: NEW → ASSIGNED
Whiteboard: [PDT+] 2/26 → [PDT+] 3/2
*** Bug 3976 has been marked as a duplicate of this bug. ***
This bug will turn one year old on March 18, and was originally set to be fixed 
for m3(!), so it would be nice to see this fixed.  I change screen res on a 
regular basis, and having to figure out where to leave mozilla is rather 
annoying.  Check out 3976 on what some of the former issues were for the bug.  
One of the other issues was when you maximize the window on a high res, close 
mozilla, shrink the res, and open mozilla, mozilla's window will spill off the 
desktop.  This is still present in 2000022708 on NT.
Please update the landing date for this in the status whiteboard.
Put warning about latering (PDT-) to beta2 if not complete by 3/7
Whiteboard: [PDT+] 3/2 → [PDT+] 3/2 w/b minus on 3/7
How does this bug relate to bug 30116 ("Can lose window if minimize and then 
shut down")? I'm tempted to say that 30116 is a dup of this bug...
I think they are related too. If 30116 can be fixed, then I think we can close 
this one down.
Fixed. Things won't show up off screen now. Linux might need more special 
attention as negative coordinates are used as special values, and those values 
percolate down to the widget code, so I couldn't just put something back on 
screen if it was in negative space.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
chriss,

Will you verify this is fixed?  or let me check out on your machine- I have not 
been able to reproduce on any of my machines.

Grace
Whiteboard: [PDT+] 3/2 w/b minus on 3/7 → [PDT+] 3/2 w/b minus on 3/7 - need machine to verify on
*** Bug 25628 has been marked as a duplicate of this bug. ***
changing QA contact-no longer ProfileManager component
QA Contact: gbush → jrgm
Marking Verified with build 2000-05-16-21 Win32 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: