Closed Bug 36479 Opened 24 years ago Closed 24 years ago

dual monitors under win98 crashes in GKGFXWIN.DLL

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: grey, Assigned: mikepinkerton)

References

Details

(Keywords: crash, helpwanted, Whiteboard: [nsbeta2+] 6/1 (needs external verification)) 

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Win98; U)
BuildID:    M15 Release

I have expereinced this crash in the M15 release build, and the nightly 
available during mid-day April 19. M14, M14 crypto, and NS6PR1 all worked fine. 
To isolate this problem, I have deleted all previous versions of Mozilla, along 
with the mozregistry.dat, and everything else I could fine everywhere, including 
rebooting after every crash to make sure it's not other system instabilities. I 
have checked the release notes, found no references to this, searched bugilla 
for anything related to GKGFXWIN and GKGFXWIN.DLL and came up empty. Both M15 
and today's nightly do the exact same thing, and crash in the same area. Windows 
GPF data is as follows:

MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 0177:60a41b34.
Registers:
EAX=00000000 CS=0177 EIP=60a41b34 EFLGS=00010246
EBX=0071fd40 SS=017f ESP=0068ef54 EBP=0068ef70
ECX=0068ef5c DS=017f ESI=00c6f660 FS=4de7
EDX=8000a728 ES=017f EDI=00000000 GS=0000
Bytes at CS:EIP:
d8 4f 14 d9 5d f8 d9 ee d8 5d f8 d9 05 b8 36 a4 
Stack dump:
0123aea4 00c6f660 00000300 00000400 00000000 00000000 0123bed0 0068efa0 60a42459 
0068ef90 00c6f660 60b3096f 00c6f660 0068ef90 80000000 00000000 

Talkback doesn't come up for anything, or I'd have sent talkback data. Sorry. If 
anyone has specific questions or if I can do anything to help give greater 
detail about this, please feel free to emails me anytime.

Reproducible: Always
Steps to Reproduce:
1. Put on crash helmet.
2. Start browser.
3. Crash.

Actual Results:  Boom. It crashes and I get a headache.

Expected Results:  Started.

Again, Windows GPF data:

MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 0177:60a41b34.
Registers:
EAX=00000000 CS=0177 EIP=60a41b34 EFLGS=00010246
EBX=0071fd40 SS=017f ESP=0068ef54 EBP=0068ef70
ECX=0068ef5c DS=017f ESI=00c6f660 FS=4de7
EDX=8000a728 ES=017f EDI=00000000 GS=0000
Bytes at CS:EIP:
d8 4f 14 d9 5d f8 d9 ee d8 5d f8 d9 05 b8 36 a4 
Stack dump:
0123aea4 00c6f660 00000300 00000400 00000000 00000000 0123bed0 0068efa0 60a42459 
0068ef90 00c6f660 60b3096f 00c6f660 0068ef90 80000000 00000000
this worksforme with the 4/19 build under windows98 and NT.
I'm going to try tonight's nightly and see what happens.
Here's the crash data for tonight's (April 21, 2000) nightly:

MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 0177:60af215c.
Registers:
EAX=00000000 CS=0177 EIP=60af215c EFLGS=00010246
EBX=00745e28 SS=017f ESP=0068f00c EBP=0068f028
ECX=0068f014 DS=017f ESI=0107aad0 FS=37ef
EDX=00000001 ES=017f EDI=00000000 GS=0000
Bytes at CS:EIP:
d8 4f 14 d9 5d f8 d9 ee d8 5d f8 d9 05 c8 46 af 
Stack dump:
01141b54 0107aad0 00000300 00000400 00000000 00000000 0111bc70 0068f058
60af2a81 0068f044 80000000 60be0b1a 0107aad0 0068f044 00000000 00000000 

Any ideas on how I might be able to narrow this down? I just now, seconds ago, 
fired up M14 with crypto, and it worked perfectly. Started up quite fast 
actually. Maybe 10 seconds or so...

Oh, and I'm running an Athlon 700, 128MB, Voodoo3 PCI card. 
*** Bug 36528 has been marked as a duplicate of this bug. ***
*** Bug 36144 has been marked as a duplicate of this bug. ***
starsaa@usa.net and jblaine@shore.net I added you to the cc: list on this bug.  
can any of you get a nightly talkback build and try this again.  
if you are using a talkback-enabled mozilla build (such as):
  
  ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip

and submit the talkback report with your email address entered into it, then
we can dig up the stack trace from there. Update the bug report if you submit
a report from one of these crashes. Thanks.
Severity: blocker → critical
Downloaded 4/20 nightly talkback build.  Same problem.  Crash happens before
talkback stuff is "enabled" or whatever.  I assume talkback stuff is supposed
to catch crashes and allow me to send a dump to you folks.  It never gets that
far.
have any of you tried running mozila with command line options like -console, 
-ProfileManager, -installer, -mail, etc. to see if it produces different 
results.  Have you tried teh Installer.exed builds, the zipped builds...

Is it creating the profile directory or anything besides the mozregistry.dat?

Me too. I always DL the talkback versions, and I can't get TB to generate a 
report. I'll grab the most recent nightly and try again. Also, I'll try to get 
as much debug data as possible, but so far this is it... Apparently Mozilla 
doesn't load far enough to start whatever TB needs to start.

Asadotzler: Now, nothing besides mozregistry.dat gets built no matter what 
switch I use. I tried those too. Sory for not mentioning it.

Alos, I've been using the ZIPped builds. Tonight I'll try an Installer build, 
since that's something I have yet to do. :)
1. mozilla.exe -ProfileManager = Same page fault.

2. mozilla.exe -console = Same page fault with the following shown in the
   DOS window:

stdout directed to dynamic console
stderr directed to dynamic console
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Profile Manager : Command Line Options : End
has multiple monitor apis is 1
****** number of sceens 2
WEBSHELL+ = 1
gShellCounter: 0
WEBSHELL+ = 2
gShellCounter: 1
calling loadpage...
startPage:: newProfile1_1
gShellCounter: 2
got a request
has multiple monitor apis is 1
*** found screen 11a2
has multiple monitor apis is 1

3.  mozilla.exe -installer = Same page fault.
4.  mozilla.exe -mail = Same page fault.

As mentioned already at the beginning of this bug report, the Installer version
does the same thing (page fault).

The only remnant I see from running it is that mozregistry.dat is created.  No
profile (Users50) area is set up ever.
Same errors here, except for -Console switch. Here's the output from that:

stdout directed to dynamic console
stderr directed to dynamic console
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Profile Manager : Command Line Options : End
ProfileManager : GetProfileDir
ProfileManager : GetProfileDir
Profile Manager : Profile Wizard and Manager activites : End

Still can't get Talkback to catch the crash. Is there anyway to either manually 
initialize Talkback or gather the information manually with another program?

Mozilla.exe -console

stdout directed to dynamic console
stderr directed to dynamic console
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Profile Manager : Command Line Options : End
has multiple monitor apis is 1
****** number of sceens 2
WEBSHELL+ = 1
WEBSHELL+ = 2
calling loadpage...
startPage:: newProfile1_1
got a request
has multiple monitor apis is 1
*** found screen 11a2
has multiple monitor apis is 1


GPF Data:

MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 0177:60ae2139.
Registers:
EAX=00000000 CS=0177 EIP=60ae2139 EFLGS=00010246
EBX=0070f468 SS=017f ESP=0068efec EBP=0068f008
ECX=0068eff4 DS=017f ESI=0110a9f0 FS=2adf
EDX=00000400 ES=017f EDI=00000000 GS=0000
Bytes at CS:EIP:
d8 4f 14 d9 5d fc d9 ee d8 5d fc d9 05 c8 46 ae 
Stack dump:
018b4544 0110a9f0 00000300 00000400 00000000 018b5040 00000000 0068f038 60ae2b0b 
0068f024 80000000 60bd0bd1 0110a9f0 0068f024 00000000 00000000 

Also tried the installer EXE for M15 and the same thing happens. Crash on 
startup. Here's the GPF data from that:

MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 0177:60a41b34.
Registers:
EAX=00000000 CS=0177 EIP=60a41b34 EFLGS=00010246
EBX=0070c718 SS=017f ESP=0068ef74 EBP=0068ef90
ECX=0068ef7c DS=017f ESI=00c7f750 FS=4957
EDX=8000ae60 ES=017f EDI=00000000 GS=0000
Bytes at CS:EIP:
d8 4f 14 d9 5d f8 d9 ee d8 5d f8 d9 05 b8 36 a4 
Stack dump:
01204324 00c7f750 00000300 00000400 00000000 00000000 01205c20 0068efc0 60a42459 
0068efb0 00c7f750 60b3096f 00c7f750 0068efb0 80000000 00000000 
Ok, from what I'm seeing, both jblaine@shore.net and I both have dual monitors. 
Could this be the problem? Have any of you guys tried testing this on a multi 
monitor Win98 system? I'm running Win98 4.10.1998, not Win98 SE, with a Voodoo3 
PCI and a Mystique 220 for a secondary display. Just trying to narrow the 
possibilities...

Still can't get Talkback to catch anything...
Indeed, I have a dual monitor setup at work (running 98 SE).  My
cards are both TNT2s, the primary one is a TNT2 Ultra.  Note that I
am home for the weekend and won't be able to help on this until
Monday when I am back at work.
I am also using a dual monitor setup. M15 gave me the following error

MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 0167:60a41b34.
Registers:
EAX=00000000 CS=0167 EIP=60a41b34 EFLGS=00010246
EBX=0071e028 SS=016f ESP=0068ef74 EBP=0068ef90
ECX=0068ef7c DS=016f ESI=0148f750 FS=5de7
EDX=80006248 ES=016f EDI=00000000 GS=0000
Bytes at CS:EIP:
d8 4f 14 d9 5d f8 d9 ee d8 5d f8 d9 05 b8 36 a4 
Stack dump:
021635d4 0148f750 0000023c 00000320 00000000 00000000 02164ec0 0068efc0 60a42459 
0068efb0 0148f750 60b3096f 0148f750 0068efb0 80000000 00000000 
Ok guys. I disabled my second monitor, and WITHOUT RESTARTING THE COMPUTER, I 
ran Mozilla, Nightly from 4-20. It worked perfectly. I re-enabled the monitor, 
and CRASH. I disabled it again, it worked, re-enabled screen 2, CRASH.

I'm not a developer, but a long time tech, and to me, I'd say this is a 
DEFINITE dual monitor bug for 98, all versions. I don't know if it happens in NT 
or W2k.

This bug is real, and now reproduceable. Dual displays on Win98 cause M15 and 
later to crash. I'm not a Moz developer, so I'm not going to do it, but _I_ feel 
this should be remarked as confirmed. I've run M15 and every nightly since M15 
was released (I never DLed a nightly before the 19)th, and now they all exhibit 
the same behavior. Crash on Dual monitor (verifyed through three different 
users) and FOR ME, works when the second screen is disabled, no reboot needed.
copying pinkerton on this one if it is a dual monitor problem then maybe he 
knows it.  
i've heard of problems, but no one in the building has been able to help me find 
them. our only dual-monitor PC is hyatt's win2k box and his machine exhibits none 
of the problems.

i need help here. my pc is NT4.

Hi again. Ok, i've now managed to reproduce it on three different w98 dual 
display systems. My Athlon 700 with Win98, a Pentium MMX with W98SE, and a 
K6-500 with W98SE. I'll see what I can do about trying it under NT.

Pinkerton: If you have any Win98 machines that you can play with for half an 
hour, and a second PCI vid card and monitor you can 'borrow' for a bit, it's 
very easy to setup 98 with dual displays. Just plug the vid card into a PCI clot 
with a higher address line than your primary (it's trial and error, if the new 
card winds up booting to the BIOS screen, shut down and swap them). 98 will see 
it and ask you for drivers. Then, go to Display Properties and click the new 
monitor. 98 will walk you thourgh the rest.

Is there anything else I can do to help with this? Anyway to get talkback info 
manually? I'm a fairly advanced tech head, but don't do a lot of development. 
But I'm not gunshy about picking bits out of the sky, so any suggestions you 
have so I can get you guys more data is OK by me. I'm just glad I'm finally able 
to contribute SOMETHING to the project... :)
OK, Confirming this bug and updating summary to reflect real issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Splash screen, then crash in GKGFXWIN.DLL → dual monitors under win98 crashes in GKGFXWIN.DLL
Probably a dup of bug #36239 both cause a crash in module gkgfxwin.dll and
occured when using Windows 98, this appears to be a win98 only problem as it
works on hyatt's win2k box.

jrgm, pink, does this look like bug 36239 to you?
after reading these comments, and bug 26239, I tried swapping the position of my 
monitors. I normally run like this:

Primary | Secondary

but in bug 36239 the guy had them swapped, with primary on the right. So I 
switched positions (logically) and then ran Mozilla. Worked until I went to 
access a menu, then crash. Exactly as described in bug 36239. Again, I switched 
back to my normal config with primary of left, and re-ran Mozilla. Crash on 
splash, as everything here says. Looks like a dupe. Too bad talkback still 
wouldn't catch the crash in the other config though...
Ack! Ignore that first bug number reference, typo!
Summary and Update:

All errors under Win98
1. Mozilla crashed during splash screen with Primary display on left. Mozilla 
starts on primary, but crashes in GKGFXWIN.DLL.

2. With Primary display on right, top, or bottom, Mozilla starts fine. Sidebar 
is collapseable with no error. All buttons to the left of the Bookmarks button 
(Home, Mozilla.org, Tinderbox, etc.) work fine. Bookmark button, and all Menu 
bar functions crash mozilla in GKGFXWIN.DLL.

3. Disabling secondary display before running Mozilla results in no crashes at 
all. All buttons and menus work fine.

4. Disabling secondary monitor, then running Mozilla, and then RE-ENABLING the 
secondary display, WHILE MOZILLA IS STILL RUNNING, results in NO CRASHES. No 
matter the orientation, Mozilla will run fine if the secondary display is 
enabled after Mozilla is up, and Moz is on Primary.

5. Take number 4, and place secondary display on right or bottom. Mozilla runs, 
buttons work, no crash. BUT menus appear on primary display. On the right side 
of Primary if Secondary is on right, or on the bottom if secondary is on bottom. 
(Netscape 4.7x does something similar, menus open to the left side when primary 
is on right and window is on secondary, but never crashes) If secondary is on 
top or left, then the window becomes unresponsive until you move it back to the 
primary.

6. I have me secondary display on the right, with a small offset in levels. My 
secondary is a few pixels lower than my primary. This is because I can 'throw' 
the mouse to the top left, and click to close a program when it's maximized. The 
mouse get's stuck in the corner, just like on a single display system. When I 
arrange both displays to be level, then Mozilla starts fine, but crashes when 
you access a menu. It only crashes on startup when the displays are not lined up 
perfectly.

My observations lead me to believe this:

GKGFXWIN.DLL is having problems interpreting non-standard window coordinates 
begin passed to it by Windows (I'd say the GDI, right?).

It can't handle extended X or Y coords when starting (multi monitor setups) and 
thus crashes on menu access. With offset diaplays, Moz crashes on start up.

It can handle extended positive X,Y coords fine when it's running, but always 
draw menus on the primary display's coords. Offset secondary coords crash 
GKGFXWIN.DLL.

It doesn't recognize negative coords at all. Even though it's located in a -X,-Y 
based window. When the Moz window is half on a neg coord screen and half on a 
positive coord screen, the menus on the positive side work, the neg side ones 
don't. Thus, Negative coordinates must be viewed at completely invalid.

I haven't done any heavy duty programming like this in a while, but I'm going to 
browse through the source to see if I can make any other recommendations. Any 
idea who would be in charge of the code that works with these types of 
interactions?
Finally got it to generate some TB data.
Incident number TB9339762Y
It's commented as RE: bug 36239, typo meant to say this one, but that one leads 
here. My bad...
Ok. More digging. I think I've found where the problems lie, source wise. More 
so, Bug 21942, which is marked as Verified and Fixed, as of M15, is in reality 
NOT fixed, but alive and well, and I'd say a direct relation to this bug. 
Probably this bug's older brother.

Can the module owner get to gether with me, whoever he/she/it/they/them are? I'd 
like to swap ideas...
well, that would be me.

Adding crash keyword.
Keywords: crash
pinkerton@netscape.com - would you like to take this bug out of 
Browser-General, or assign it to yourself? :-)

Gerv
gaak
Assignee: asadotzler → pinkerton
*** Bug 36239 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → M18
*** Bug 37547 has been marked as a duplicate of this bug. ***
Keywords: nsbeta2
*** Bug 36462 has been marked as a duplicate of this bug. ***
*** Bug 38356 has been marked as a duplicate of this bug. ***
moving back to my beta2 radar.
Component: Browser-General → XP Toolkit/Widgets
Target Milestone: M18 → M17
[nsbeta2+] 6/1
Whiteboard: [nsbeta2+] 6/1
I feel just sick about this, but i made a 98 development machine and i cannot 
duplicate the problem. at all. it works fine with two monitors.

marking WORKSFORME as it works on win98 and win2k.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
First, It's real. The problem is when Mozilla is accessing the coords to draw 
the menu, it crashes. That occurs only after Moz has been successfully run on 
the system, so it has made a mozregistry.dat, etc.

Second, tell me your system specs. Since I'm getting almost nowhere fiddling 
with the code, I may as well use my mountain of equipment for testing 
purooses...
Occurs on my system as well.

specs:
Windows 98 (first edition)
Primary monitor: ATI All-In-Wonder 128 at 1280x1024, 32bpp (19")
Secondary monitor: ATI Rage 128 at 1024x768, 16bpp (15")

Experienced everyone else's problems, including the "has multiple monitor apis 
is 1" end console line. I do get a different dump, however:
"MOZILLA caused an invalid page fault in
module GKGFXWIN.DLL at 018f:60a84296.
Registers:
EAX=00000000 CS=018f EIP=60a84296 EFLGS=00010246
EBX=00ff64f0 SS=0197 ESP=0068f70c EBP=0068f728
ECX=0068f718 DS=0197 ESI=00000000 FS=655f
EDX=00000500 ES=0197 EDI=00000028 GS=0000
Bytes at CS:EIP:
d8 4e 14 d9 5d fc d9 ee d8 5d fc d9 05 d8 66 a8 
Stack dump:
00ff64f0 00fe5f60 00000000 00000400 00000500 01aea5c0 00000000 0068f748 60a84a24 
0068f738 0068f7c8 00000000 00000000 00000000 00000000 0068f788"

Occured with every nightly of the past week (when I first enabled dual 
monitors).

Request reopen status from someone..
ok, well, i'll grant that this crashes. i don't doubt that. i cannot duplicate 
the problem. No one with a development environment that can help debug has 
stepped forward.

I'm at a loss, and this won't get fixed unless someone can help me.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: M17 → M19
Status: REOPENED → ASSIGNED
I have Visual Studio 6 Enterprise edition (damn thing cost enough). What can I 
do? I'm rusty in C, but not green. I narrowed down the problems to the fixes 
for bugs 21942 and 32611, version 1.5 of nsScreenManagerWin.cpp, and the couple 
files that go with it, but I don't see that as being as helpful as I'd like to 
be. Let me know what you'd liek to see.

I can let VC++ grab the debug data, save the workspace and send it to you if 
you'd like...
*** Bug 39620 has been marked as a duplicate of this bug. ***
I'd be glad to help kill this bug. I get talkback data when I bomb on my win2k 
system, I'll send it in on monday. I'll also do a build and see if I see 
anything obvious in the debugger when it crashes.
Alos, the problem is in the "fixes" for the bugs where the menus would appear in 
the primary monitor even when the Moz window was on a secondary screen. I think 
the numbers referenced in the source were bug 21942 and bug 32611.

IIRC bug 32612 is the GTK version of this whole multi screen deal...
I have a Dell Inspiron 7000.  Windows 98 second edition and get the same 
problem.  I don't know if it will help but I made a drwatson log.  I put it at
http://users.solve.net/~chadp1/WATSON00.WLG

Just built mozilla and tested; unfortunately this crash only occurs in 
optimized builds. I was able to browse just fine with the debug build. Will try 
building optimized with symbols next...
ok, well i fixed two things w/in that routine, but i'm still guessing about what 
the real problem is. marking fixed, would like it if someone could verify by 
repulling nsScreenManagerWin.cpp who has the crash.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
haven't pulled the mentioned changes yet. some debugging reveals that the call 
to screen->GetRect from nsDeviceContextWin :: ComputeFullAreaUsingScreen is 
trashing the stack; the crash then occurs at outRect->y = NSToIntRound(y * 
mDevUnitsToAppUnits);

couldn't figure out why the stack is getting trashed though. will try the 
latest as soon as cvs lets me have it.
Still crashes in the same spot with the new changes. Removing the call to 
GetRect and filling in outRect with the single-monitor values prevents the 
crash; this also results in the menus being drawn on the wrong screen.
fuck. ok, well, there's no way i can fix this myself since i don't have a single 
machine anywhere that replicates it. obviously something is wrong deep within 
nsDeviceContextWin::FindScreen() but i have no idea what since i can't step 
through it.
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: FIXED → ---
Found and fixed the bug. All the multi-monitor APIs that you GetProcAddress for 
need to be declared as WINAPI. Otherwise they will smash the stack on return 
due to the calling convention mismatch. I changed the 3 typedefs in nsScreenWin 
and nsScreenManagerWin to include WINAPI and it worked on my box.

Somebody just needs to check these changes in for me, I'm still waiting on my 
cvs write access.
you rock! i'll do that today!

see, this is what you get when you leave win32 programming to a mac weenie ;)

can you give me a patch? i can't seem to get that to compile. thanks.
Status: REOPENED → ASSIGNED
nsScreenWin.cpp
typedef BOOL (WINAPI *GetMonitorInfoProc)(HMONITOR inMon, LPMONITORINFO 
ioInfo); 

nsScreenManagerWin.cpp
typedef HMONITOR (WINAPI *MonitorFromRectProc)(LPCRECT inRect, DWORD inFlag); 
typedef BOOL (WINAPI *EnumDisplayMonitorsProc)(HDC, LPCRECT, MONITORENUMPROC, 
LPARAM);
First, THANK YOU!

Second, YOU SUCK! I went to cash my paycheck, and stopped at a Borders to browse 
the Computer Programming section with a printout of the source to those files. 
And I found the exact thing you did! =-]

Congrats, and thank you. And Pink? Why is it you can call yourself a Mac Weenie, 
but when we PeeCee nuts call you that, you get upset? =-]

Also, one note I also found that may be of service in the future: For Multimon 
systems with displays that are offset (like mine were) rather than forming one 
continuous screen, while Windows prevents the mouse from going off the display 
areas, there are addressable areas of the virtual display that are accessable to 
programs (it's a feature, not a bug, really). Should folks who wish to use the 
Gecko core in other projects should make note to specifically address the 
displays (like this is doing) rather than the entire virtual screen.
Left as an exercise to the reader: why did this only show up in optimized 
builds? The stack would still have been off by 8 bytes following the return 
from GetMonitorInfo, I guess maybe there is enough padding in debug builds to 
allow that to go unpunished. 

*** Bug 40423 has been marked as a duplicate of this bug. ***
fixed, oh finally fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Can the folks who experienced this crash let us know if you're running
OK with tomorrow's win32 build.  Thanks, and a big thanks to
juberti@aol.com and jesusx@who.net (jesusx) for tracking this down!
Whiteboard: [nsbeta2+] 6/1 → [nsbeta2+] 6/1 (needs external verification)
I've been pulling down builds all day, but they're not working yet. As soon as I 
get a functioning build, you'll know. I'm glad to have helped (and look forward 
to trying to squash more bugs) and absolutely love juberti@aol.com for finding 
the fix. =-]
The fix won't be in the nightlies until the next set that comes out (tomorrow 
a.m. PST) -- mike just checked the code in about a half-hour ago. You can 
of course roll your own though, and you'll get the fix now.
IT WORKS! IT WORKS! IT REALLY REALLY WORKS!!! It's fast, friendly, and now the 
official browser of this egomaniac! Woohoo!

Oh, and the fix seems to have solved our problem. Good work fellows. Cherrio... 
=-]
Last Comment (posted with Build 2000052420!)
First, the Name's Grey Hodge. Yessiree. And tomorrow, I'll be filing a flurry of
bugs, after I DL another build to bang around and verify first.

Second, this fix, as simple as it was, sows the great amount of time and effort
in Mozilla because Mozilla, even with one window spread across two displays,
performs MUCH faster than even any Explorer window (NOT IE, any ol' explorer
window), even when resizing! Blistering speed.

In short, and closing, Moz seems to now work _flawlessly_ with multiple displays
(at least on the two I have). <knock wood>

Marking Verified per Greg's comments.
Status: RESOLVED → VERIFIED
Works great now, thanks for the good work!
You need to log in before you can comment on or make changes to this bug.