Open Bug 586233 Opened 16 years ago Updated 3 years ago

Top window border not painted on Classic desktops with custom active/inactive window colors

Categories

(Core :: Widget: Win32, defect)

x86
Windows XP
defect

Tracking

()

Tracking Status
blocking2.0 --- -

People

(Reporter: stanio, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: polish)

Attachments

(6 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 SeaMonkey/1.1.19 (Spidey; Mnenhy 0.7.6) Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre With the introduction of the title-bar drawn appmenu-button the top window border doesn't seem painted with the corresponding active or inactive color anymore - using Classic style theme. To see this, explicitly configure the "Active Window Border" and "Inactive Window Border" colors to something distinguishable. Reproducible: Always
This could be related with Bug 586228.
If the general intention is to let Personas draw over the window borders, all borders should be drawn when no persona has been applied, at least. But I guess the given case of Personas drawn over the top border is just unwanted effect?
This appears to happen only with browser windows which have the app-menu button shown. When I permanently show the menu bar and the app-menu button disappears the top border starts to paint all right (Personas not painting over, too).
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
Version: unspecified → Trunk
Blocks: 574454
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #7) > If the general intention is to let Personas draw over the window borders, all > borders should be drawn when no persona has been applied, at least. But I > guess the given case of Personas drawn over the top border is just unwanted > effect? With the default color scheme, the titlebar obscures the persona, which is desired. Setting these custom active border values causes the upper border painting to skip, so the persona shows up. Not sure why but this shouldn't be hard to track down. http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsNativeThemeWin.cpp#3190
Hmm, looks like DrawFrameControl and DrawEdge are lacking for this. We might have to put this edge together manually.
(In reply to comment #6) > Created attachment 464771 [details] > XP-style theme - top border not painted with Personas image Stanimir, what's the issue here on XP?
Summary: Top window border not painted → Top window border not painted on Classic desktops with custom active/inactive window colors
>> Created attachment 464771 [details] [details] >> XP-style theme - top border not painted with Personas image > > Stanimir, what's the issue here on XP? No issue/problem - just for comparison.
This should probably block, our classic rendering isn't right when user's customize through advanced ui prefs.
blocking2.0: --- → ?
I don't really think this blocks. I'd take the patch, but it feels like this would be a bug that falls off the back of the bus.
blocking2.0: ? → -
Keywords: polish
Attached patch attempt v.1 — — Splinter Review
This patch addresses this, although there's a bug where the highlighted border sometimes is offset one pixel too high on the window, depending on the border width. I haven't been able to track that last problem down. If someone feels passionately about this feel free to take this up. I'll try to get back to this before the release or shortly after.
(note that patch is built on top of the patches in bug 610643)
Depends on: 610643
Still seen using: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre
Depends on: 636264

Thunderbird v60/v68

Win 7 x86
Classic theme

Top Active-Window-Border is missing in the main window:

(It's OK when mail.tabs.autoHide=True.)

(Other windows are OK.)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: