Closed Bug 770058 Opened 11 years ago Closed 10 years ago

Switching main window between active and inactive doesn't update the title bar active state if disabled MenuBar in Window7Classic Style

Categories

(Core :: Layout, defect)

16 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla18

People

(Reporter: alice0775, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/d9d61d199b11
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120701030537

This maybe happens in Windows7 Classic style only.

Steps to Reproduce:
1. Make sure "Windows7 Classic Style" is selected
2. Start Firefox with clean profile (MenuBar is disabled)
3-1. Switch to another application (Alt+Tab)
    -- Observe TitleBar Color
3-2. Switch to Nightly again (Alt+Tab)
    -- Observe TitleBar Color

Actual Results:
 The TitleBar color does not change

Expected Results:
 The TitleBar should change .


Mouse over Window Control Buttons(Minimum/Maximize/Close) helps.

Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/0d9f7fb55226
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629192951
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/cd6d52bdf2d8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120629200651
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0d9f7fb55226&tochange=cd6d52bdf2d8

Suspected: Bug 539356
It's probably this change to PresShell::DocumentStatesChanged:

-  if (aStateMask.HasState(NS_DOCUMENT_STATE_WINDOW_INACTIVE)) {
-    nsIFrame* root = mFrameConstructor->GetRootFrame();
-    if (root) {
-      root->InvalidateFrameSubtree();
-    }
-  }
+  ScheduleViewManagerFlush();

We still need to do that InvalidateFrameSubtree to invalidate frames that have native-theme backgrounds that have changed.
Assignee: nobody → roc
Attachment #638256 - Flags: review?(matt.woodrow)
Attached patch part 2 v2 (obsolete) — Splinter Review
Only call GetChildLists, not GetCrossDocChildLists, because this gets called on every document anyway.
Attachment #638257 - Attachment is obsolete: true
Attachment #638257 - Flags: review?(matt.woodrow)
Attachment #638258 - Flags: review?(matt.woodrow)
FWIW (not much), those don't seem to fix the not-yet-marked-dupe bug 770081 on OS X.
Hmm, maybe that uses nsILookAndFeel colors or something?
I sure hope this fixes it. I don't have any bigger sledgehammers.
Attachment #638258 - Attachment is obsolete: true
Attachment #638258 - Flags: review?(matt.woodrow)
Attachment #638268 - Flags: review?(matt.woodrow)
Attachment #638268 - Flags: review?(matt.woodrow) → review+
Attachment #638256 - Flags: review?(matt.woodrow) → review+
OS: Windows 7 → All
Hardware: x86 → All
I'm not sure which All this one is, but it's All minus OS X, which is bug 770056.
https://hg.mozilla.org/mozilla-central/rev/071d6332729b
https://hg.mozilla.org/mozilla-central/rev/6266a1336e2d
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Depends on: 770575
Depends on: 770642
Backed out as part of DLBI:

https://hg.mozilla.org/mozilla-central/rev/6266a1336e2d
https://hg.mozilla.org/mozilla-central/rev/071d6332729b
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
https://hg.mozilla.org/mozilla-central/rev/5f4c8635e87e
https://hg.mozilla.org/mozilla-central/rev/9366a70acb1d
Status: REOPENED → RESOLVED
Closed: 11 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: mozilla16 → mozilla18
You need to log in before you can comment on or make changes to this bug.