Closed Bug 143174 Opened 22 years ago Closed 22 years ago

use windows color option under preferences not dynamic in browser window {Cou

Categories

(Core Graveyard :: Embedding: APIs, defect, P1)

Product:
Core Graveyard
Component:
Embedding: APIs
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: winnie, Assigned: kmcclusk)

References

Details

(Keywords: topembed+, Whiteboard: [adt3 RTM] [fix checked into the trunk] Needs a/adt for branch)

Attachments

(1 file, 2 obsolete files)

Only enumerate windows on the current thread + comments suggested by roc
10.80 KB, patch
rods
: review+
roc
: superreview+
jud
: approval+
Details | Diff | Splinter Review 
Tested on Win98.

1) Open today's MFCEmbed build. Go to www.yahoo.com. Notice browser window is white.
2) right-click on Windows Desktop to invoke contextual menu; select option
"Properties"
3) under the "Appearance" tab, click on the arrow on the "Item:" combo box;
scroll down and select Window; change color to Red
4) click OK to save changes
5) Go to MFCEmbed browser window, where www.yahoo.com is up.

Expected result:
Browser window background is red.

Actual result:
Browser window background is white.

Also tested with Netscape build 2002050306.  Same test results as above.

Internal bug reference: http://bugscape.mcom.com/show_bug.cgi?id=14734
Also tried restarting the MFCEmbed and Netscape browsers.  Still same test
results.  Background remained white.
Keywords: topembed+
QA Contact: imajes-qa → bmartin
Why is this my Bug?
Assignee: rods → Matti
QA Contact: bmartin → imajes-qa
-> Embedding
Assignee: Matti → adamlock
Component: Browser-General → Embedding: APIs
QA Contact: imajes-qa → mdunn
Sorry, the internal bug reference should be:
http://bugzilla.mozilla.org/show_bug.cgi?id=14374, not the one noted earlier. 
14374 was assigned to rods.  Reassigning back to rods.
Assignee: adamlock → rods
Jud, Terri
I am not sure this is specificly an embedding issue. Please help to find the
correct QA and Dev owners.
QA Contact: mdunn → tpreston
This problem also happens in Mozilla. If you change the background color for the
system windows Mozilla displays www.yahoo.com with a white background instead of
using the system window color. Perhaps, we need to specify a the system window
color as the default <body> color in ua.css? 

Alex can you take a look it this one?
Assignee: rods → alexsavulov
You need to set the preference: browser.display.use_system_colors to true. the
default is false.

In Mozilla if you go edit-preferences-appearances-colors and click on the "use
system colors" check box it works correctly.
Resolving as INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Reopening: the pref *is* honored, but the color change is not dynamic.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: use windows color option under preferences not functional in browser window {Cou → use windows color option under preferences not dynamic in browser window {Cou
Taking
Assignee: alexsavulov → kmcclusk
Status: REOPENED → NEW
A similar problem also happens in Chimera.  When you change the "Highlight
Color" option for selected text and lists in System Preferences in OS X, the URL
bar highlight color changes, but not in the browser window.  See Chimera bug
filed in Mozdev.org:
http://mozdev.org/bugs/show_bug.cgi?id=998

        Attachment #84987 -
        Attachment is obsolete: true

    
  
Priority: -- → P1
Whiteboard: Needs r/sr
Target Milestone: --- → mozilla1.0.1

    
    

    
  
The Mac specific work is covered in bug 148856
OS: All → Windows XP
Hardware: All → PC

    
    

    
  
Comment on attachment 86091 [details] [diff] [review]
Dispatch and handle a new cross platform message NS_SYSCOLORCHANGE

r=rods

        Attachment #86091 -
        Flags: review+

    
    

    
  
One question:

When you EnumWindows(), won't you pick up windows that belong to other Mozilla
processes? What stops you from trying to ::CallWindowProc on the window of some
other Mozilla process and (I presume) dying?

One comment:

You should add a comment somewhere that it is the toolkit's responsibility to
repaint all windows after SysColorsChanged() has been called. And you should add
a comment in windows/nsToolkit that Windows does, in fact, paint all windows
after the WM_SYSCOLORCHANGE has been dispatched.

    
    

    
  


  
Good catch!.  I changed the patch to only enumerate windows in the current
thread. I also added the comments you suggested. Thanks.

    
  

        Attachment #86091 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 86149 [details] [diff] [review]
Only enumerate windows on the current thread + comments suggested by roc

sr=roc+moz

        Attachment #86149 -
        Flags: superreview+

    
    

    
  
Comment on attachment 86149 [details] [diff] [review]
Only enumerate windows on the current thread + comments suggested by roc

r=rods

        Attachment #86149 -
        Flags: review+

    
    

    
  
Fix checked into the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: adt1.0.1
Resolution: --- → FIXED
Whiteboard: Needs r/sr → [fix checked into the trunk] Needs a/adt for branch

    
    

    
  
ADT: This is a low risk fix. The new code added in this patch is executed only
when the user has changed their system colors through the WIN32 control panel. 

    
  
Keywords: approval

    
    

    
  
IMO, this is not fixed, all combo boxes, text boxes are changed to red but not
the actual background as in other apps

    
    

    
  
I was wrong, Kevin cleared it up for me, thanks!!! Verifying fixed win XP trunk
build 2002060508 and win Me trunk build 2002060508
Status: RESOLVED → VERIFIED

    
  
Keywords: mozilla1.0.1
Whiteboard: [fix checked into the trunk] Needs a/adt for branch → [adt3 RTM] [fix checked into the trunk] Needs a/adt for branch

    
    

    
  
please checkin to the 1.0.1 branch. once there remove the "mozilla1.0.1+"
keyword and add the fixed1.0.1 keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+

    
  

        Attachment #86149 -
        Flags: approval+

    
    

    
  
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls chekc
this in asap, then add the "fixed1.0.1" keyword. thanks!
Blocks: 143047
Keywords: adt1.0.1 → adt1.0.1+

    
    

    
  
Checked into the 1.0 branch
Keywords: mozilla1.0.1+ → fixed1.0.1

    
    

    
  
verified mfc embed branch build 2002082209
Keywords: fixed1.0.1 → verified1.0.1

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: