Closed Bug 610201 Opened 10 years ago Closed 10 years ago
Window's Control Button(min/max/close)is wrong shape in Aero Basic
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
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
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.
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+
Status: NEW → RESOLVED
Closed: 10 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.
Status: RESOLVED → REOPENED
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 - http://firstname.lastname@example.org/ 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.
Attachment #489181 - Flags: review?(roc) → review+
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.