Closed
Bug 127044
Opened 23 years ago
Closed 23 years ago
Browser/Mail window split in half
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
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.
Reporter | ||
Comment 1•23 years ago
|
||
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..
Reporter | ||
Comment 3•23 years ago
|
||
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 ...
Reporter | ||
Comment 5•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
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.
Reporter | ||
Comment 8•23 years ago
|
||
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 .......
Comment 9•23 years ago
|
||
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.
Reporter | ||
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
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/...... ?)
Reporter | ||
Comment 14•23 years ago
|
||
The last build I downloaded/installed was from 02/23/2002 at 12:46 CST and the previous 3 uploaded builds.
Reporter | ||
Comment 15•23 years ago
|
||
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 ??
Comment 16•23 years ago
|
||
is this the installer build, the zip build ...? Give us the exact path/build
Comment 17•23 years ago
|
||
I suspect that some files are not updated for some reason. I would suggest uninstalling mozilla0.9.8 before installing nightly
Comment 18•23 years ago
|
||
scratch my last comment (note to self: should get more sleep before adding comments to bugs)
Comment 19•23 years ago
|
||
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?
Reporter | ||
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
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...
Reporter | ||
Comment 23•23 years ago
|
||
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.
Reporter | ||
Comment 24•23 years ago
|
||
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
Comment 25•23 years ago
|
||
similar descriptions/screenshots have now surfaced in bug 130331 and bug 130574
Keywords: regression
Reporter | ||
Comment 27•23 years ago
|
||
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.
Reporter | ||
Comment 28•23 years ago
|
||
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.
Assignee | ||
Comment 29•23 years ago
|
||
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.
Reporter | ||
Comment 30•23 years ago
|
||
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.
Assignee | ||
Comment 32•23 years ago
|
||
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
Reporter | ||
Comment 33•23 years ago
|
||
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.
Reporter | ||
Comment 34•23 years ago
|
||
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.
Comment 35•23 years ago
|
||
seems thisgets resolved as WFM now. Dup bug 131099 and bug 131422 joined the club, resolved as dup of bug 131016
Comment 36•23 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•