Closed Bug 592182 Opened 14 years ago Closed 14 years ago

Aero glass fills entire window

Categories

(Core :: Widget: Win32, defect)

All
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: techsoftadvanced, Unassigned)

References

Details

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre The Aero glass fills the entire window, including the webpage area. This is considered a poor practice, and leads to greatly decreased performance, lack of a proper, DWM-controlled client region border, and a few other small problems. I believe this may also contribute to drawing delays when resizing the window. Reproducible: Always Steps to Reproduce: 1. Enable DWM composition 2. Use the default theme, which supports Aero glass Actual Results: The DWM-controlled client border is not drawn, as the glass exists "behind" the webpage area. Expected Results: The MARGINS struct passed to DwmExtendFrameIntoClientArea should not contain any negative numbers, unless the entire window is intended to lack a client area. DwmEnableBlurBehindWindow should be used for glass within the client area. This preserves the "standard" client border. Without this border, the window looks "hacked" together. I marked this bug as major because it is a serious flaw in one of Firefox 4's most anticipated features. Countless problems could arise due to this configuration. This is not what the DWM will be expecting for a window that contains a large, rectangular client area, so the results are indeterminate. Fixing this now will prevent a lot of problems later. In addition, this should be fixed *before* the release so that a future correction to this bug does not affects user-made themes.
I would personally consider this a blocking bug, due to its potential for indeterminate errors when the product is deployed in as large a scale as the current stable release of Firefox.
Version: unspecified → Trunk
Looking back at bug #579409, this is actually a regression. Rather than the MARGINS structure being properly calculated, it was simply avoided by setting it to { -1, -1, -1, -1 }. I am voting for blocker--this basically kills the Aero feature, in my eyes, making it look quite clumsy. The client area literally has no border. I will attach a few images for comparison.
Severity: major → blocker
Blocks: 579409
Attached image Current state (REGRESSION) (deleted) —
Attached image Previous state (prior to regression) (deleted) —
Attached image Expected state (deleted) —
This regression worsens bug #579409, in that bug #579409 now applies when "Tabs on top" is disabled. Previously, it was only applicable when "Tabs on top" was disabled.
Blocks: 554982
Severity: blocker → normal
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
This is not regression, it suppose to look like that. Aero borders had to go away, otherweise tabs on bottom without bookmarks bar would look horribly (as we saw before). Look at mockup: https://wiki.mozilla.org/images/1/17/Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%28TabsTop%29.png Voting for INVALID.
We do calculate the margins. However, since the desire is to not have the borders, we shrink our calculated opaque rectangle by 2px on all sides. Thus most of the window is actually opaque to the DWM so we avoid the performance penalty for an all-glass window. The effect should be observationally equivalent to setting the margins to -1 except for performance effects. If you see us setting the margins to -1 with the debugger, please reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: