Closed
Bug 592182
Opened 14 years ago
Closed 14 years ago
Aero glass fills entire window
Categories
(Core :: Widget: Win32, defect)
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.
Reporter | ||
Comment 1•14 years ago
|
||
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
Reporter | ||
Comment 2•14 years ago
|
||
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
Reporter | ||
Comment 3•14 years ago
|
||
Reporter | ||
Comment 4•14 years ago
|
||
Reporter | ||
Comment 5•14 years ago
|
||
Reporter | ||
Comment 6•14 years ago
|
||
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.
Updated•14 years ago
|
Blocks: 554982
Severity: blocker → normal
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
Comment 7•14 years ago
|
||
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.
Comment 8•14 years ago
|
||
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.
Description
•