Closed Bug 127044 Opened 23 years ago Closed 23 years ago

Browser/Mail window split in half

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 74522

People

(Reporter: jay, Assigned: dveditz)

Details

(Keywords: regression) 

Win98SE build 2002022103 latest morning build 7:50am CST

Browser window split in half, lower window displays programming such as:

    <menuitem id="menu_sendPage" label="&sendPage.label;"  so forth and so on ..

Upper half displays web page but not distorted, actually shows upper half of web
page.
Still with us in the 4th release of the day.
Summary: Browser/Mail window split in half → Browser/Mail window split in half
I'm not sure what you mean by the "browser/mail window" but have you tested this
on a new profile? Does deleting localstore.rdf cure it?
If this was a general bug, duplicates would have been pouring in..
New Profile and/or deleting localstore.rdf did nothing to fix this. See screen
shot at http://www.JayGarcia.com/Half_Window.gif

This just started with yesterdays first morning build release. I've never seen
anything like this previously. I agree, bug reports should be waiting in line to
post, dunno ...
resembles the screenshot in bug 126138
Installed 0.9.8 release and no problems encountered, display is normal.
Re-installed nightly and the problem returns. Re-install 0.9.8 again and problem
goes away, dunno.

Each install is over the previous install. I don't see how this can be on just
MY system.

Are you running in some kind of debug mode? (preferences/debug)
Not that I know of. I wasn't when I installed the nightly that showed the
problem and not now after installing 0.9.8 release. At first I thought that I
was somehow running a debug mode but checked all the prefs and all is normal.
There is something in the latest nightlies that is not agreeing with my system.
I can load 0.9.8 and it works flawlessly. Load the nightly and the display is as
posted. New profile, deleting localstore.rdf and xul.mfl have no effect. All of
the preference windows are also cut in half with the lower half displaying the
same as posted in my screen capture graphic. All of the pref windows cannot be
resized either. I have no idea at this point .......
Remove everything of Mozilla. Uninstall it, remove any Mozilla directory in
program files, remove any Mozilla directory in Windows\Application Data\ (e.g.
any profile - do backups of course), remove any occurance of Mozilla in Windows
folder (I think there are some files).

THEN, install the nightly. I'm pretty sure the cause is a corrupted profile.
Chucker: If it were a matter of a corrupted profile then why is 0.9.8 working as
intended. Posting this with it now. It's only the latest 4 nightly releases from
2/22 and 2/23 that are problematic.

As I mentioned I also tried creating a 'new' profile which had no effect, same
problem. Also relocated the /mozilla.org/ directory to another drive.

Maybe this has something to do with XUL caching?
Can you go to Preferences -> Networking and check the box that says 'Disable XUL
cache' and see if that makes a difference.
Vadim: Makes no difference.
seems like the builds have invalid xul files judging from the screenshot. Could
you tell us exactly which builds you were testing (i.e.
ftp://ftp.mozilla.org/pub/mozilla/nightly/...... ?)
The last build I downloaded/installed was from 02/23/2002 at 12:46 CST and the
previous 3 uploaded builds.
Ok, I took the suggestion to completely wipe Mozilla. Also wiped 6.2.1, all
registry entries for both, rebooted, loaded the latest nightly. Same problem !!

Next ??

is this the installer build, the zip build ...? Give us the exact path/build
I suspect that some files are not updated for some reason. I would suggest
uninstalling mozilla0.9.8 before installing nightly
scratch my last comment (note to self: should get more sleep before adding
comments to bugs)
just curious, jay do you defrag your drive or have had any related computer
problems?  I have not experienced this yet on w2k.  Is it platform specific?
Drives defragged and scandisked, registry cleaned, etc. using OnTrack Utilities.
Like I mentioned previously, why does 0.9.8 perform where those latest nightlies
don't. I can completely wipe Mozilla, load the nightly and it bombs. I can come
right back again with 0.9.8 writing OVER the nightly and it works perfectly.
I've even tried installing /mozilla.org/ directory to 4 different partitions
with no luck. Tried a NEW profile, no luck.

Using the "installer" version, not the zip.
this happened to me as well - turned out it was a corruption thanks to Netscape
Messenger with NS 6.2. The Messenger files were installed in Moz, confusing it
very badly...
Patrick: I don't have 6.2 installed and it still doesn't work.
Interesting !!!

I thought maybe that my download was corrupted somehow by CuteFTP for the
nightlies that didn't work. So, I downloaded from another box and installed over
the network and for whatever reason the latest nightly, 2002022503, works ...
even more perplexed now, ain't computers fun ?? !! I'll try the next nightly
release from the "infected" box to confirm.

Solved, but have no clue as to why.

I've been downloading the nightlies to my D: drive 9 gig SCSI formatted as a
single FAT32 partition. 

Downloaded the latest nightly to another drive and FAT16 partition. Nightly
installs and runs/displays with no problems whatsoever. Download the SAME file
to the FAT32 drive and it screws up again. I haven't a clue.

Interesting note is that 0.9.8 downloaded to the FAT32 drive works ok but the
last 5 or 6 nighlies misbehave.

Again, this is Win98SE

similar descriptions/screenshots have now surfaced in bug 130331 and bug 130574
now also reported in bug 131016
Keywords: regression
I can reproduce this 100% by downloading and installing from my FAT32 partition.
Downloading and installing the same bits from a FAT16 partition does not
reproduce this problem. This started with the very next nightly build after the
0.9.8 release. I can still download and install 0.9.8 from the FAT32 partition.
Downloaded today's build 2002031708 to my FAT32 partition, installed and problem
continues.

Copied the bits from the FAT32 partition to a FAT16 partition, installed and
problem goes away. It's not the bits that are being corrupted but rather the
actual installation FROM the FAT32 partition that is causing this.

Are you saying it matters where the *installer* is located, not where Mozilla 
is installed? That if the installer is on a Fat16 disk but you install to the 
Fat32 disk it works OK?

Where is your temp directory, by the way? The installer unpacks itself to and 
runs from the temp directory. It's hard to imagine the unpacking process 
depends on FAT16 vs FAT32, and the result after that point should be the 
installer running out of the same temp directory. Then again, it's hard to 
imagine FAT16 vs FAT32 making a difference to Mozilla itself yet here we are.

CC'ing law and blythe in case either of them have heard of any Win9x FAT32 
wierdness before.
FAT32 Partition is D: drive 
FAT16 Partition is F: drive 
D: is the only FAT32 partition drive and D: is a dedicated drive with only a
single FAT32 partition.

Also have a F:\download\ directory on the FAT16 F: drive.

If I download the bits to D:\download and install to F:\mozilla.org\ the problem
exists.

If I download to F:\download and install to F:\mozilla.org\ the problem does not
exist.

If I move the bits from D to F and install to F:\mozilla.org\ the problem does
not exist.

If I use the bits on D: and installal to D:\mozilla.org\ the problem exists.

If I use the bits from F:\download\ and install to D:\mozilla.org\ the problem
does not exist.

Seems like it only matters where the archive is stored when installing.


Forgot to mention, /temp/ is F:\temp\ the FAT16 partition.
Jay: do you have any .xpi files in the same directory as the downloaded stub? 
If so those are being used in favor of the downloaded ones (it's a feature, 
honest).  Delete those, or move the stub to a different directory on your 
FAT32 drive before running it and report what happens.

We may need to re-think our policy of local .xpi overrides, this wouldn't be 
the first complaint we've gotten about that (mostly from people who switch 
between the stub and blob forms).

Moving back to installer since Jay has confirmed it's the installer directory 
that matters to this bug, not the final Mozilla directory.
Assignee: asa → dveditz
Component: Browser-General → Installer
QA Contact: doronr → bugzilla
ONLY the downloaded 10meg bits (full install I may mention) is on the FAT32
drive. There is nothing remotely resembling Mozilla on the FAT32 drive. I
already thought of that and took the appropriate precautions, scandisk/defrag also.

Embarrassed !!!! 

There WAS a MAIL.XPI in the D:\download directory that for whatever reason (old
age?) that I simply missed. All is well and fine now. Embarrassed or not at
least we gained some valuable knowledge and experience here.

seems thisgets resolved as WFM now. Dup bug 131099 and bug 131422 joined the
club, resolved as dup of bug 131016
dupe of bug 74522 "installer should use extracted xpi file instead of local xpi"

*** This bug has been marked as a duplicate of 74522 ***
Severity: blocker → normal
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → gbush
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.