Closed
Bug 610201
Opened 14 years ago
Closed 14 years ago
Window's Control Button(min/max/close)is wrong shape in Aero Basic
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: alice0775, Assigned: jimm)
References
Details
(Keywords: regression)
Attachments
(2 files, 2 obsolete files)
9.84 KB,
image/png
|
Details | |
8.34 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre ID:20101106042135
Window's Control Button(min/max/close)is wrong shape in Aero Basic.
*When I right-clicked the title bar, it becomes the right shape temporarily.
*Enabled menubar fix the issue.
Reproducible: Always
Steps to Reproduce:
1. Start Minefield with new profile
Actual Results:
Window's Control Button(min/max/close)is wrong shape
Expected Results:
It should be right shape
Regression window:
works
http://hg.mozilla.org/mozilla-central/rev/a1705bc179e4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre ID:20101105044308
fails:
http://hg.mozilla.org/mozilla-central/rev/c5c5fbdb20d1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre ID:20101105090653
pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a1705bc179e4&tochange=c5c5fbdb20d1
Updated•14 years ago
|
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
![]() |
Assignee | |
Updated•14 years ago
|
Assignee: nobody → jmathies
![]() |
Assignee | |
Comment 1•14 years ago
|
||
![]() |
Assignee | |
Comment 2•14 years ago
|
||
I need to retest the quake issue with this in a release build before seeking reviews.
note to drivers, this bug should block.
![]() |
Assignee | |
Comment 3•14 years ago
|
||
Apparently layered windows that aren't activated don't trigger the theme metrics calculations we need for the button data. So create a normal window and display it minimized so it doesn't show up on the desktop.
Attachment #488761 -
Attachment is obsolete: true
Attachment #488764 -
Flags: review?(roc)
blocking2.0: ? → final+
Comment on attachment 488764 [details] [diff] [review]
use a normal window in UpdateTitlebarInfo v.1
+ // Create a minimized, descendent of the window passed in. This
While you're here, lose the command and spell 'descendant' correctly ;-)
Attachment #488764 -
Flags: review?(roc) → review+
![]() |
Assignee | |
Comment 5•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
![]() |
Assignee | |
Comment 6•14 years ago
|
||
This still isn't fixed yet. The timing for release opt builds was different, the temp window didn't provide the correct metrics.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
![]() |
Assignee | |
Updated•14 years ago
|
Attachment #488764 -
Attachment is obsolete: true
![]() |
Assignee | |
Comment 7•14 years ago
|
||
New fix. I'm reverting back to the use of SW_SHOW since that's the only state that seems to work reliably. To get around the full screen game problem I'm caching these values on startup and only refreshing them when the theme changed event is received, vs. the composition changed event.
I'm going to throw this at try and test an opt build first before seeking another round of reviews.
![]() |
Assignee | |
Comment 8•14 years ago
|
||
Comment on attachment 489181 [details] [diff] [review]
cache once on startup v.1
Release opt builds here -
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-5c8d3f871213/
This appears to have fixed both the quake problem and the buttons problem.
Attachment #489181 -
Flags: review?(roc)
Don't we still need some NOACTIVE stuff here?
![]() |
Assignee | |
Comment 10•14 years ago
|
||
(In reply to comment #9)
> Don't we still need some NOACTIVE stuff here?
ShowWindow(hWnd, SW_SHOW) will activate the window it creates. There doesn't appear to be a way around that. The original quake fix was to use SW_SHOWNOACTIVE, but that delayed the population of the button values for the window.
I then went with SW_SHOWMINNOACTIVE, but it turned out that just worked because I was testing in a debug build. SW_SHOW seems to be the only way to insure the values are populated before we ask for them.
Since the window is layered, it's invisible and since its associated with fx, it doesn't take a spot on the taskbar. Plus with this fix, we only create this window on initial startup, and when someone changes their theme.
If you have any theories on how this might break something (or any ideas on how to do this some other way!) I'd love to hear them. This is a total pita.
Attachment #489181 -
Flags: review?(roc) → review+
![]() |
Assignee | |
Comment 11•14 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•