Closed Bug 610201 Opened 14 years ago Closed 14 years ago

Window's Control Button(min/max/close)is wrong shape in Aero Basic


(Core :: Widget: Win32, defect)

Windows 7
Not set



Tracking Status
blocking2.0 --- final+


(Reporter: alice0775, Assigned: jimm)



(Keywords: regression)


(2 files, 2 obsolete files)

Attached image screenshot
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:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre ID:20101105044308
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre ID:20101105090653
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
Blocks: 591154
blocking2.0: --- → ?
Assignee: nobody → jmathies
Attached patch windows is goofy patch v.1 (obsolete) — Splinter Review
I need to retest the quake issue with this in a release build before seeking reviews.

note to drivers, this bug should block.
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)
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+
Closed: 14 years ago
Resolution: --- → FIXED
This still isn't fixed yet. The timing for release opt builds was different, the temp window didn't provide the correct metrics.
Resolution: FIXED → ---
Attachment #488764 - Attachment is obsolete: true
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.
Comment on attachment 489181 [details] [diff] [review]
cache once on startup v.1

Release opt builds here -

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?
(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.
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Depends on: 611693
You need to log in before you can comment on or make changes to this bug.