opened windows need sanity checks on size, position and visibility




18 years ago
15 years ago


(Reporter: chriss, Assigned: saari (gone))



Windows 98

Firefox Tracking Flags

(Not tracked)


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


(1 attachment)



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

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

Comment 1

18 years ago
Assigning bug to don. adding dogfood keyword
Assignee: leger → don
Keywords: dogfood

Comment 2

18 years ago
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: dogfood → beta1

Comment 3

18 years ago
Well, neither I nor others can repro this so I'm moving it out to M15 for later
Assignee: don → law
Priority: P3 → P2
Target Milestone: M15

Comment 4

18 years ago
I can reproduce with by substituting my original prefs folder. I'll be happy to 
help show this on a QA machine.

Comment 5

18 years ago
gbush, can you check out please?  See chriss. Thanks!
Component: Browser-General → Profile Manager BackEnd
QA Contact: cbegle → gbush
Whiteboard: [PDT+]

Comment 6

18 years ago

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


Comment 7

18 years ago
Created attachment 5063 [details]
Corrupt localstore.rdf file

Comment 8

18 years ago
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.

Comment 9

18 years ago
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

Comment 10

18 years ago
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

Comment 11

18 years ago
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.  

Comment 12

18 years ago
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.

Comment 13

18 years ago
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

Comment 14

18 years ago
Looks like this bug has morphed into "opened windows need sanity checks on size, 
position and visibility."
Component: other → XP Toolkit/Widgets
Summary: Seamonkey launches but windows are invisible → windows are invisible with corrupt localstore.rdf
Target Milestone: M15 → M18

Comment 15

18 years ago
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, 

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

Comment 16

18 years ago
Putting on the PDT- radar for beta1.  Would not hold for this.  We can relnote
the issue.
Keywords: relnote
Whiteboard: [PDT-]

Comment 17

18 years ago
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-]

Comment 18

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 19

18 years ago
Putting on PDT+ radar for beta1.

Comment 20

18 years ago
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
Target Milestone: M18 → M14


18 years ago
Whiteboard: [PDT+] → [PDT+] 2/21

Comment 21

18 years ago
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



18 years ago
Whiteboard: [PDT+] 2/21 → [PDT+] 2/24

Comment 22

18 years ago
Still needs more work
Whiteboard: [PDT+] 2/24 → [PDT+] 2/26

Comment 23

18 years ago
Assignee: saari → danm

Comment 24

18 years ago
You stole this from the beetles, I'm stealing it back
Assignee: danm → saari

Comment 25

18 years ago
changed ETA date
Whiteboard: [PDT+] 2/26 → [PDT+] 3/2

Comment 26

18 years ago
*** Bug 3976 has been marked as a duplicate of this bug. ***

Comment 27

18 years ago
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.

Comment 28

18 years ago
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

Comment 29

18 years ago
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...

Comment 30

18 years ago
I think they are related too. If 30116 can be fixed, then I think we can close 
this one down.

Comment 31

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 32

18 years ago

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.

Whiteboard: [PDT+] 3/2 w/b minus on 3/7 → [PDT+] 3/2 w/b minus on 3/7 - need machine to verify on

Comment 33

18 years ago
*** Bug 25628 has been marked as a duplicate of this bug. ***

Comment 34

18 years ago
changing QA contact-no longer ProfileManager component
QA Contact: gbush → jrgm

Comment 35

18 years ago
Marking Verified with build 2000-05-16-21 Win32 build.
You need to log in before you can comment on or make changes to this bug.