Closed Bug 25979 Opened 25 years ago Closed 24 years ago

Win98 has poor color in 256 color mode

Categories

(Core :: Layout, defect, P3)

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: paulmac, Assigned: dcone)

References

Details

(Whiteboard: [nsbeta2+][w/b minus on 6/15]fix in tree) 

When switching from mozilla to another app and then back, colors do not look 
right. It looks like we are not handling the palette change notification 
correctly. There is no problem when running in high color mode.

Steps to Reproduce: 
1) Set computer to 256 mode
2) Bring up mozilla
3) Toggle to Netscape 4.x
4) Come back to mozilla

Results: Colors are very ugly, images are blurred, toolbars are messed up.

This is on windows 98 using 256 colors. Problem does not occur in 16-bit color.
Don -- this is a windows palette problem. Can you take a look?
Assignee: rickg → dcone
Status: NEW → ASSIGNED
Target Milestone: M14
marking beta, as this makes the browser extremely ugly if you use 256 colors on
win98 (which I do).
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Is there a reciepe.. this works for me.  I tried Viewer and Mozilla on NT and 
Windows 98 (on my laptop).  I will put "Works For Me", feel free to re-open if 
you can reproduce.. and let me know a reciepe with a page.  I tried on a few 
computers and the palette seems fine.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I found a reciepe!
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Fixed.. some of the updates were not happening..
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Don, I am still seeing this using today's 2/11 build, which has your fix in it. 
All I have to do is go to http://www.mozilla.org (or any webpage) and as I 
re-size the browser window, each re-flow causes the pallette to switch. It's 
especially noticable in the mozilla gif and in all the toolbar.

I don't notice any improvement. The grey in the toolbar turns orange, the blue 
turns green, etc., as I resize.

Is there anything I can do to help? This really is ugly...

Re-opening bug.
Status: RESOLVED → REOPENED
QA Contact: petersen → paulmac
Resolution: FIXED → ---
Can you fill me in on something.. the tree is still closed and changes are still 
going in.. Is todays build really from today.  I thought the tree had to be 
opened inorder to get a "Todays Build".  

the tree is closed until it's been verified that there is no hoarkage. QA (like 
myself) gets the builds while the tree is closed to do this verification. The 
tree opens after it passes our tests.

So yes, I'm pretty sure I have the change, assuming it was checking in before 
8am, which it looks like it was.
I can no longer get this to happen on my NT or my windows 98 machine.  The fix I 
put in (I repulled and rebuilt) keeps the problem from happening.   If I take 
out the fix.. it starts to happen again.  If Mozilla is the background.. the 
colors will change.. this is normal.. at least for now. But when Mozilla is the 
foreground.. I can no longer get this to happen.
The problem is this.  If you use the ::SelectPalette with a value of FALSE
" ::SelectPalette(hDC,(HPALETTE)palInfo.palette,FALSE)" line 2456 in 
mozilla/widget/src/windows/nsWindow.cpp
the palette colors will be correct.. but the application will crash if you have 
an FTP open and you quit.  
recipe:
1. Make sure you are in 8 bit (256 colors)
2. Open any FTP site.. to start a new FTP thread.
3. quit.  The appliation will freeze (or go into and endless loop)

If you use the ::SelectPalette with a value of TRUE
" ::SelectPalette(hDC,(HPALETTE)palInfo.palette,TRUE)" , the palette will look 
incorrect but will not freeze in the FTP case.

The ::SelectPalette must be true, so something bad is happening with this 
thread.. I was told to hand this off to you.. you would know who would handle 
this problem.. The bug for the freeze.. which is closed because I have TRUE in 
for the ::SelectPalette() (so it wont freeze), is bug number 7426.. this is the 
freeze bug.. which will come back as soon as you use FALSE in the 
::SelectPalette call.
Assignee: dcone → warren
Status: REOPENED → NEW
Not sure why this came to me. If there's a problem with having the ftp directory 
listing window open and we crash due to color palette problems, then it's surely 
a widget issue. I suggest you get a backtrace of the crash and find the guilty 
party.
Assignee: warren → dcone
Thanks for the help!
Assignee: dcone → warren
First, why do we call SelectPalette every time we scroll a scrollbar? That 
seems like an unnecessary performance issue. Anyway...

I tried changing the SelectPalette call to pass FALSE, and then switched my 
display to 256 color. Everything worked fine for me. Ftp and file directory 
listings worked great -- no hangs. I don't have to reboot before trying this, 
do I? I'm sure I was in 256 color mode because everything looked like crap 
(btw, a lot of our icons are hosed in this mode). I would hit the SelectPalette  
call for just about everything I did too.

Sorry. Back to Don Cone.
Assignee: warren → dcone
Aah, this is interesting. I switched back to True Color mode (and mozilla 
really looked like crap at that point) (and 4.x lost some icons too) -- then I 
tried to quit and got this hang:

USER32! 77e78001()
nsView::~nsView() line 153
nsView::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsView::Destroy(nsView * const 0x032f1820) line 257 + 34 bytes
nsFrame::Destroy(nsFrame * const 0x02536c00, nsIPresContext * 0x02135c80) line 
406
nsContainerFrame::Destroy(nsContainerFrame * const 0x02536c00, nsIPresContext * 
0x02135c80) line 99
nsMenuPopupFrame::Destroy(nsMenuPopupFrame * const 0x02536c00, nsIPresContext * 
0x02135c80) line 983
nsFrameList::DestroyFrames(nsIPresContext * 0x02135c80) line 36
nsMenuFrame::Destroy(nsMenuFrame * const 0x02554fa0, nsIPresContext * 
0x02135c80) line 210
nsFrameList::DestroyFrames(nsIPresContext * 0x02135c80) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x02554f34, nsIPresContext * 
0x02135c80) line 98
nsMenuBarFrame::Destroy(nsMenuBarFrame * const 0x02554f34, nsIPresContext * 
0x02135c80) line 614
nsFrameList::DestroyFrames(nsIPresContext * 0x02135c80) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x025548f8, nsIPresContext * 
0x02135c80) line 98
nsFrameList::DestroyFrames(nsIPresContext * 0x02135c80) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x025548bc, nsIPresContext * 
0x02135c80) line 98
nsFrameList::DestroyFrames(nsIPresContext * 0x02135c80) line 36
nsContainerFrame::Destroy(nsContainerFrame * const 0x02554880, nsIPresContext * 
0x02135c80) line 98
ViewportFrame::Destroy(ViewportFrame * const 0x02554880, nsIPresContext * 
0x02135c80) line 140
FrameManager::~FrameManager() line 343
FrameManager::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
FrameManager::Release(FrameManager * const 0x02136cb0) line 328 + 134 bytes
PresShell::~PresShell() line 718 + 36 bytes
PresShell::`scalar deleting destructor'() + 15 bytes
PresShell::Release(PresShell * const 0x02135200) line 658 + 138 bytes
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 435
DocumentViewerImpl::~DocumentViewerImpl() line 381 + 75 bytes
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 0x00000001) + 15 
bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x02134bd0) line 306 + 
134 bytes
nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 
0x00000000) line 417
nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 
788
nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 527
nsWebShell::Destroy(nsWebShell * const 0x020dc710) line 3667
nsXULWindow::Destroy(nsXULWindow * const 0x020dd724) line 335
nsWebShellWindow::Close(nsWebShellWindow * const 0x020dd768) line 394
nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f840) line 453
nsWindow::DispatchEvent(nsWindow * const 0x020dcb44, nsGUIEvent * 0x0012f840, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f840) line 514
nsWindow::DispatchStandardEvent(unsigned int 0x00000065) line 534 + 15 bytes
nsWindow::ProcessMessage(unsigned int 0x00000010, unsigned int 0x00000000, long 
0x00000000, long * 0x0012fa88) line 2091
nsWindow::WindowProc(HWND__ * 0x0de70320, unsigned int 0x00000010, unsigned int 
0x00000000, long 0x00000000) line 673 + 27 bytes
USER32! 77e719d0()
USER32! 77e71982()
NTDLL! 77f763a3()
USER32! 77e718d2()
nsWindow::DefaultWindowProc(HWND__ * 0x0de70320, unsigned int 0x00000112, 
unsigned int 0x0000f060, long 0x00330406) line 700
USER32! 77e727fe()
USER32! 77e72889()
nsWindow::WindowProc(HWND__ * 0x0de70320, unsigned int 0x00000112, unsigned int 
0x0000f060, long 0x00330406) line 680 + 31 bytes
USER32! 77e719d0()
USER32! 77e71982()
NTDLL! 77f763a3()
USER32! 77e718d2()
nsWindow::DefaultWindowProc(HWND__ * 0x0de70320, unsigned int 0x000000a1, 
unsigned int 0x00000014, long 0x00330406) line 700
USER32! 77e727fe()
USER32! 77e72889()
nsWindow::WindowProc(HWND__ * 0x0de70320, unsigned int 0x000000a1, unsigned int 
0x00000014, long 0x00330406) line 680 + 31 bytes
USER32! 77e71820()

The pc in ~nsView shows that we're calling window->Destroy(), but it looks like 
we lost a stack frame somewhere:

  if (nsnull != mWindow)
  {
    mWindow->SetClientData(nsnull);
=>    mWindow->Destroy();
    NS_RELEASE(mWindow);
  }
  NS_IF_RELEASE(mDirtyRegion);

I suggest that you start by looking at how Destroy might hang in system code.

Note that I never saw the CPU spin (go to 100%).
If you got wierd colors.. then you did not change it to false.. 
When viewer is in the foreground.. the colors should look perfect.  The
::SelectPallete call to change is the one in the WM_QUERYNEWPALETTE message... 
Also all you have to do is go to fpt://ftp.netscape.com.. then once that loads.. 
quit.  It will lock up..  I tracked it down to the very last close of the 
window.  It will lock up in viewer also.  Can you look once more.. it seems to 
be some sort of thread that is not cleaned up.
Assignee: dcone → warren
I'm positive I tried it with FALSE. I stepped through the call in the debugger.
Sorry, but I can't reproduce this.
Assignee: warren → dcone
Rick, can you look at this.. Warren can't reproduce this.. I know it is some 
sort of threading problem.. if you want I can get on the phone with you and show 
you exactly how and were it locks up (spins in the thread).
Reciepe.

1.)  Change all the SelectPallete(, TRUE) calls to SelectPallete(,FALSE) in
     widget/src/windows/nsWindow.cpp
2.)  Set display to 8 bit (256 color)
3.)  Launch viewer or mozilla.
4.)  Go to ftp://ftp.netscape.com
5.)  quit

it will lock up.  Where it locks up in viewer is the routine 
Webshell/tests/srcnsBrowserWindow::Close()
 the very last "DestroyWidget(mWindow);" right after mThrobber is released.
 You will notice that DestroyWidget is called 4 times before this last call so 
the DestroyWidget is not the culprit.. there is a thread that just stays 
running. Thanks
Assignee: dcone → rpotts
Need ETA Date for fix in Status Whiteboard please.
Whiteboard: [PDT+] → [PDT+] no ETA yet
So, here's what I've found out so far...  

Summary:
--------
It appears that the FTP thread *does* create a window even though it has no 
message pump :-(.  On shutdown, the UI thread does a SendMessage() to this 
window (to notify it of a palette change) and deadlocks because the FTP 
thread pool is blocked in PR_Wait().

Dirty Details:
--------------
The FTP connection thread creates an nsEventQueue - This causes an NSPR Event 
Receiver Window to be created.  For some reason that only God knows, the 
*constructor* in nsEventQueue does an Addref().  This artifically bumps the 
reference count so that when the FTP connection is destroyed, the event queue 
remains - along with its associated NSPR Event Receiver Window.

Unfortunately, it appears that in *some* instance the artificial Addref is 
necessary.  Each time a method on a proxy object is invoked, 
nsEventQueueServiceImpl::PushThreadEventQueue(...) is called.  This ACTUALLY 
CREATES A NEW nsEventQueue and associated NSPR Event Receiver Window!!!!!!
After the method has been invoked, PopThreadEventQueue(...) is called and the 
Event Queue is destroyed (and the NSPR Event Receiver Window)...  So, in this 
case the artificial reference is necessary :-(

It's no wonder that proxy objects are slow - they create/destroy a window on 
each invocation!!!!!

Right now I feel like the Sewer Urchin on the Tick, after wading through all 
this mess...

I have no idea (yet) how to unravel the reference counting problem with the 
nsEventQueue, but I hope that once the extra NSPR Event Receiver Window is 
destroyed on the FTP thread, the App will stop deadlocking on shutdown...
rick, if you pull out the push/pop event code from proxy, does this problem go 
away?  Maybe it was a bad idea to use nested eventQ's: since the eventQ is 
basically just looping, we probably do not need a nested q.  danm, do you see 
any reason to use a nested q here?

It is disturbing that an eventQ push is so expensive.  
If only it were that easy :-)  Unfortunately, the eventQ that is remaining is 
the one that was created by calling CreateThreadEventQueue(...).

The ones created via PushThreadEventQueue() are deleted correctly...  I guess 
that somewhere in PopThreadEventQueue() an *extra* release is being done...

So, the calls to Push/PopThreadEventQueue(...) suck because they end up 
creating/destroying a Window, but I don't think that they are the root of the 
problem...

-- rick
I wrote up a bug to investigate removing nested eventQ from proxy to improve
preformance:

http://bugzilla.mozilla.org/show_bug.cgi?id=29474

Horray!!  I just found a bug in PL_CreateMonitoredEventQueue(...) which creates 
the native window anyways!  We'll probably need to fix this in order to get 
things working correctly :-(

Here's a quick patch:

Index: plevent.c
===================================================================
RCS file: /cvsroot/mozilla/xpcom/threads/plevent.c,v
retrieving revision 1.1
diff -c -r1.1 plevent.c
*** plevent.c   2000/01/25 14:48:51     1.1
--- plevent.c   2000/02/28 04:59:44
***************
*** 172,179 ****
      {
          err = _pl_SetupNativeNotifier(self);
          if (err) goto error;
      }
-     _md_CreateEventQueue( self );
      return self;

    error:
--- 172,179 ----
      {
          err = _pl_SetupNativeNotifier(self);
          if (err) goto error;
+         _md_CreateEventQueue( self );
      }
      return self;

    error:


it looks like we need to do a couple of things to fix this bug correctly.

1. Change nsEventQueueService::CreateThreadEventQueue() to take an argument 
indicating whether the thread is a UI or worker thread.  In the case of a UI 
thread a Native PLEventQ (along with a Window) should be created.  However, for 
worker threads a Monitored PLEventQ should be created.  
These semantics should also apply to Push/PopThreadEventQueue(...).  On a worker 
thread PushThreadEventQueue should create a new Monitored PLEventQ.

2. NSPR should be fixed so that creating a Monitored PLEventQ does *not* create 
a native window.  It would be good to have the native window shared among all of 
the event queues that are pushed on a given thread.  This would eliminate the 
need to create/destroy a window each time Push/PopThreadEventQueue is called.

3. It would be nice to fix the reference counting problem where EventQueues 
created via CreateThreadEventQueue() are *never* destroyed.  If 1 & 2 are done 
though, leaking the extra event queue is not fatal...

-- rick
if I'm reading this correctly. we're creating a window for every event push 
(ouch!). also, this new window could potentially capture (and not process) OS 
level events, causing events to get dropped.
Dan, I'm reassigning this one to you, since you're the closest thing to an owner 
that nsEventQueue has got :-)
Assignee: rpotts → danm
Dan: Do the comments from rpotts give you enough info to get this resolved? 
Rpotts will be on sabbatical starting Thursday, and hence it is critical that 
you get any additional info today (Wednesday).
I *think* the list of items are well enough defined that it should be possible 
to schedule this... and then of course it would be great to get that on the 
status whiteboard.
Thanks,
Jim
  No way do I want to rehash everything that Rick has already figured out, but I 
do have to start somewhere. Correct me if I'm wrong, but, I'm only able to 
reproduce this problem if I change nsWindow.cpp to ::SetPalette(...,false). Since 
that file is checked in ...true, there's no hang.
  Is the situation that we want to be better citizens, and this hang is 
preventing us from doing that? Or is it that some people consistently see the 
hang, and changing nsWindow is just a way of making everyone see it? I'm happy to 
fix the potential problem, I'm just trying to understand whether it's a current 
problem or a potential one.
  Regarding Rick's comments above that reference counting on event queues is all 
messed up, I see it being a little squirrely, but basically sound. It nearly 
works. But the last event queue (and its window) are leaked for a variety of 
reasons. One of them is, as far as I can tell, the event queue service thread 
descriptor is never deleted under any circumstances.
  That stuff wants to be figured out, but involves touching several distinct 
areas in the code. For now, I agree with Rick that some of our threads can be 
made "monitored," rather than native. This is one of them, and doing so will fix 
the hang. But I think there are problems with making all event queues not on the 
primordial thread, monitored, which in itself is a pretty scary problem. Why does 
this stuff work, anyway?
Status: NEW → ASSIGNED
Whiteboard: [PDT+] no ETA yet → [PDT+] 3/3
Whiteboard: [PDT+] 3/3 → [PDT+] fix coded, awaiting review and approval
Whiteboard: [PDT+] fix coded, awaiting review and approval → [PDT+] fix approved but holding off for testing anomaly
A fix is ready to go in, but I'm holding off because bug 30634 shows symptoms 
that one could expect if something had gone wrong with the intended fix for this 
bug. That makes it hard to have any confidence in this fix, though it seems to 
have no effect on that other bug.
Depends on: 30634
Whiteboard: [PDT+] fix approved but holding off for testing anomaly → [PDT+] fix approved but holding off. see comment 5 Mar
It is unfortunate that this bug has morphed from several ugly (but cosmetic) 
problems with palettes (which even 4.72 hasn't nailed) into several more 
problems with event queues/threads. There seems to be some question what the 
steps to reproduce are (changing the code does _not_ count), and whether there 
is a crash or not.  If anyone thinks they understand it, could you please update 
the Summary, specify the steps to reproduce, the expected results, and the 
actual results?  The 'fix' that is ready to go in sounds very iffy, especially 
since we don't seem to understand why this code works at all.
I'm removing the PDT+, since that was added before the bug morphed, and in any 
case the bug needs reconsideration in light of the murky problem and fix.
Whiteboard: [PDT+] fix approved but holding off. see comment 5 Mar → Fix approved but holding off. see comment 5 Mar
I'm not sure that the original bug has morphed. The problem is the fix for the
pallette problem apparently causes all sorts of other problems (that are beyond me).

The pallette problems are yes, cosmetic, but bad enough to make you not want to
use Seamonkey. I've actually changed my resolution down to 1024x768 so I can get
16-bit color and avoid the 256 color problem.

However, at this stage, I would say a release note may be in order, unless
development has suddenly developed more confidence in the fix.

I can reproduce this by simply switching to 256 color mode and resizing the
browser window on both my win98 machine at work and my win95 machine at home.
Toolbars turn purple, buttons turn orange, images get real ugly. It does not
appear to happen on all windows machines.

The threatened fix isn't bad or scary. It's just difficult to tell whether there 
was a problem with it because of bugs 30634 and 30635. In fact, it looks like 
valeski's impending fix for those bugs will catch this one, too.
Whiteboard: Fix approved but holding off. see comment 5 Mar → fix is coming, not to worry
jar to go by and talk with danm regarding this...
Whiteboard: fix is coming, not to worry → [NEED INFO] fix is coming, not to worry
Dan indicated that valeski's removal of a message pump (planned to clean up some
ftp hanging problem) will as a side effect, repair this bug.  Worst case, if
Valeski's fix does not perform the expected resolution (as a side effect), then
Dan could land the changes that he had contemplated (based on rpotts suggestions).

valeski's fix for 30634 also fixed this problem.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Whiteboard: [NEED INFO] fix is coming, not to worry
Okay, I think someone still needs to change ::SelectPalette to a value of FALSE
" ::SelectPalette(hDC,(HPALETTE)palInfo.palette,FALSE)" line 2456 in 
mozilla/widget/src/windows/nsWindow.cpp
to fix the original bug, as my machine is still ugly running in 256 color mode.

Re-opening bug and replacing the PDT+ which got mysteriously removed. I will 
assign this to dcone who is hopefully around, but I think anyone can check this 
in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [PDT+]
Giving back to dcone
Assignee: danm → dcone
Status: REOPENED → NEW
The event queue hang that prevented dcone's suggested palette fix has itself been 
fixed. I'd go fix the problem originally reported, but in my opinion (on my 
machine), it behaves fine as it is, and the suggested change to SelectPalette 
only makes a tolerable situation kind of bad. Hopefully someone else can fix 
Paul's problem without messing up machines like mine (not that I ever normally 
run in 8-bit mode.)

This was originally voted a PDT+ bug because it was hanging the Navigator when
trying to exit. That bug has been fixed.
This bug has now morphed to some flavor of "uglification" of a 256 mode screen.
I'm taking off the PDT+ anotation to get a re-review of the bug.
I would suggest PDT-
If I'm misunderstanding, and the situation is much worse (like there is no way
to clean up your screen, and you are forced to re-boot, etc.), please comment.
Thanks,
Jim
Whiteboard: [PDT+]
Incorrect, jar. If you look at the comments dated 2/02 you'll see that this  bug 
was marked pdt+ because of the original bug reported - the pallette changes that 
occur when you resize or load pages when in 256 color mode on some windows 
machines cause the browser to be extremely painful to use on a daily basis. 

There is no data loss, crash, or anything of the sort, it is purely cosmetic, 
but you really would not want to use the browser in this state. Feel free to 
come by my cube and surf away to decide for yourself :-)


I can fix the palette bug by changing one word, a TRUE to a FALSE in the 
nsWindow.cpp file.  If this is a PDT+ bug I will do that today... it will not 
hurt anything if the problem with the shutdown with threading is fixed.  This 
should also fix about 3 other bugs I have..
I will check email all day.. and can be reached either at work or home..
call anytime before midnight..
Status: NEW → ASSIGNED
Putting on PDT+ radar for beta1 for one word fix only.  Put on trunk first, then 
you can put on the branch.
Whiteboard: [PDT+]
Whiteboard: [PDT+] → [PDT+] tiny fix in hand
The fix has been checked in to the tip; waiting to land on branch once PaulMac 
has confirmed. 
current tip builds on windows are hanging on start-up, will verify when good
builds come out

still no tip builds available...

Don, we finally got a tip build that launches today. Unfortunately, I see no
difference in my pallette problems. I still see buttons, images, menus, etc.,
changing to random colors when I switch between seamonkey and other apps when in
256 color mode. Darn. To reproduce easily (on my win98 256 color machine):

1. Launch seamonkey and maximize
2. Launch 4.x
3. Click back on seamonkey

Results: Seamonkey UI changes to seemingly random colors, which only change back
to correct pallette when you resize or mouse over affected areas.

Note: If I close all my applications and just run seamonkey, I don't see any
problems in pallette switches.

On my system I switch, then when I switch back everything updates just fine.  I 
use Adobe photoshop also which completely messes up the palette, then when I 
switch back everything is fine.  I even have a palette application that I can 
watch the palettes switch in and out.  Is there another machine.. or could it 
have something to do with your machine? I am at a lose here!
I think this bug will not make it for beta then.  From all my tests it works on 
my WinNT and Win95 machine and Win98. I did duplicate it on a maching here 
(win98), it seems the palette is ok, but there is some update problem.  If I 
resize the window, the colors become ok.  I will look into this.
Summary: Problems on windows running in 256 color mode → Problems on windows running in 256 color mode win98
Okay sounds good. Yes, I can definitely get the problem to go away by doing a
careful resize, but I don't want to resize every time I switch windows :-)

I'll change the PDT+ to PDT- to keep the hounds off :-)
Whiteboard: [PDT+] tiny fix in hand → [PDT-] tiny fix in hand
I don't think it's specific to my machine, I just went to jrgm's win98 machine
next door and switched him back to 256 colors and was able to see this quite easily.

I'm adding him to the cc: list and removing all the necko people, since their
problem is gone apparently.

Don, I'll try to work with QA down in San Diego to find you a machine where this
can be reproduced easier.
Target Milestone: M14 → M15
Target Milestone: M15 → M16
Summary: Problems on windows running in 256 color mode win98 → Win98 has poor color in 256 color mode
qa to petersen
QA Contact: paulmac → petersen
*** Bug 26796 has been marked as a duplicate of this bug. ***
*** Bug 28366 has been marked as a duplicate of this bug. ***
*** Bug 28367 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT-] tiny fix in hand → [PDT-]
Target Milestone: M16 → M17
Have a fix for this.. in my tree.
Whiteboard: [PDT-] → [PDT-]Have Fix in Tree
This fix effects one file, nsRenderingContextWin.cpp.  It changes about 20 lines 
of code and this code will only be called when in 256 color mode.
Whiteboard: [PDT-]Have Fix in Tree → [PDT-]fix in tree
Nominating nsbeta2, recc. nsbeta2+ 6/22. dcone has a fix in his tree, let's let 
him check it in and close this. Clearing [PDT-] to trigger re-evaluation.
Keywords: nsbeta2
Whiteboard: [PDT-]fix in tree → fix in tree
Putting on [nsbeta2+][w/b minus on 6/15] radar.
Whiteboard: fix in tree → [nsbeta2+][w/b minus on 6/15]fix in tree
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
I'm dont see the original problem described in the June 19th build (2000061908). 
Marking Verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.