Closed Bug 143174 Opened 23 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
(deleted), 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: 23 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: 23 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: