Window title bar flickers between unified and non-unified toolbar

RESOLVED FIXED in mozilla2.0b10

Status

()

Core
Widget: Cocoa
--
major
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: stephen@ju-ju.com, Assigned: mstange)

Tracking

({regression, relnote})

unspecified
mozilla2.0b10
x86
Mac OS X
regression, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [4b9], [hardblocker], URL)

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101228 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101228 Firefox/4.0b9pre

When displaying some pages, the window title/toolbar area flickers between unified and non-unified toolbar.

Reproducible: Sometimes

Steps to Reproduce:
1. Load the Facebook page above.
2. Observe the window title/toolbar when the page is loading.
Actual Results:  
The title/toolbar flickers. It switches between unified and non-unified  OS X toolbar.

Expected Results:  
The title/toolbar remains in unified toolbar appearance.

This happens with both tabs-on-top on and off.

Comment 1

7 years ago
I can confirm this with the 20101227 nightly thunderbird build (10.6.5). Upon launch, there is a border between the titlebar and the toolbar and the whole titlebar flickers. If I click outside the window the title bar becomes unified and the flicker disappears. Moving focus back to the window seems to keep the unified look for a while, but the issue reappears after I've switched between a couple of tabs or when the password prompt have appeared.

Thinking of it, I have seen this in a seamonkey nightly for a while ago, but I couldn't reproduce it in the next nightly so I thought it was a one-time issue. I have never seen this in my own seamonkey debug builds, though (64-bit only).
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

7 years ago
Duplicate of this bug: 621926
(Assignee)

Updated

7 years ago
blocking2.0: --- → ?
Keywords: regression, regressionwindow-wanted
(Assignee)

Comment 3

7 years ago
My guess is that this was caused by bug 615870, which added empty layer transactions for which no display lists are constructed. Our unified toolbar resetting code (last changed in bug 579250) always expects a display list construction during -[ChildView drawRect:], so if that doesn't happen the unified toolbar will be reset.
We probably need to move the begin/endMaybeResetUnifiedToolbar calls out of drawRect and to the place where we know that display list construction is going to happen.
Blocks: 615870
Keywords: regressionwindow-wanted
blocking2.0: ? → betaN+
FWIW, it seems that a temporary workaround for this bug is to install a Persona, e.g. from getpersonas.com.

Comment 5

7 years ago
(In reply to comment #1)
> I have never seen this in my own seamonkey debug builds, though (64-bit only).

Forget that - I now see it.
Assignee: nobody → mstange
Whiteboard: [hardblocker]

Comment 6

7 years ago
I have the same issue but also affects the tabs. If I have many tabs open it causes them to disappear when scrolling for up to 1 second if I have hardware acceleration on or up to 4 seconds with it off. This issue is not just the titlebar
(Assignee)

Comment 7

7 years ago
Created attachment 502358 [details] [diff] [review]
v1

Instead of notifying the theme one-by-one for every widget and having nsChildView expect the notifications during painting, let nsDisplayListBuilder::LeavePresShell notify the widget with an array of all themed widgets at the same time.

I'm not sure if LeavePresShell is a good place for this.
Attachment #502358 - Flags: review?(roc)
(Assignee)

Updated

7 years ago
Status: NEW → ASSIGNED

Comment 8

7 years ago
Created attachment 502363 [details]
Screenshot of broken tabs

This shows the tabs disappearing after being scrolled.
(Assignee)

Comment 9

7 years ago
jfftck, what you're seeing is bug 623852, not this one.
(Assignee)

Comment 10

7 years ago
Created attachment 502366 [details] [diff] [review]
v2
Attachment #502358 - Attachment is obsolete: true
Attachment #502363 - Attachment is obsolete: true
Attachment #502366 - Flags: review?(roc)
Attachment #502358 - Flags: review?(roc)
Comment on attachment 502366 [details] [diff] [review]
v2

This is really great. A few nits:

+   * Unused. This is only here because the interface is frozen for 2.0.

Add an XXX here

+    nsIFrame* displayRoot = nsLayoutUtils::GetDisplayRootFrame(aReferenceFrame);

You should be able to just use mReferenceFrame.

+    nsAutoTArray<ThemeGeometry,8> mThemeGeometries;

We normally wouldn't have 8 toolbars in the Firefox window so wouldn't 2 or 3 be a better value? Doesn't matter much.

+    virtual void UpdateThemeGeometries(nsTArray<ThemeGeometry>& aThemeGeometries) = 0;

const nsTArray&

r+ with that
Attachment #502366 - Flags: review?(roc) → review+
Would it make more sense to put the LeavePresShell bit in nsLayoutUtils::PaintFrame? That's where we do the transparency stuff for aero.

Comment 13

7 years ago
I am not having problems with the web sites flickering, just the titlebar. So, that bug is not the same issue and I am not seeing the same issues that are reported in that bug.
(Assignee)

Comment 14

7 years ago
Created attachment 502437 [details] [diff] [review]
for checkin
Attachment #502366 - Attachment is obsolete: true
(Assignee)

Comment 15

7 years ago
Created attachment 502633 [details] [diff] [review]
for checkin

One "const" was missing in the last patch so it didn't compile. This one does.
Attachment #502437 - Attachment is obsolete: true
(Assignee)

Comment 16

7 years ago
http://hg.mozilla.org/mozilla-central/rev/6cfffe34531c
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
(In reply to comment #11)
> Comment on attachment 502366 [details] [diff] [review]
> v2
> 
> This is really great. A few nits:
> 
> +   * Unused. This is only here because the interface is frozen for 2.0.
> 
> Add an XXX here

And file a bug, blocked on bug 610267, pretty please?
(Assignee)

Updated

7 years ago
Depends on: 624748
(Assignee)

Comment 18

7 years ago
Done.

Comment 19

7 years ago
Kinda sucks, that's it not going to be included in Beta9, it makes Firefox unusable on OSX. It will cause me to stick with Beta8 until Beta10 is released and skip Beta 9 completely.

This will be a big turn off, for the people on OSX testing the beta milestones.
They will either stick with Beta8 until Beta10 is released or move to a recent nightly containing the fix.
(Assignee)

Updated

7 years ago
Duplicate of this bug: 624918
(Assignee)

Updated

7 years ago
Duplicate of this bug: 624912

Updated

7 years ago
Whiteboard: [hardblocker] → [4b9], [hardblocker]

Updated

7 years ago
Keywords: relnote
Depends on: 625247
Comment on attachment 502633 [details] [diff] [review]
for checkin

+  // If we're finished building display list items for painting of the outermost
+  // pres shell, notify the widget about any toolbars we've encountered.
+  if (mIsPaintingToWindow && mPresShellStates.Length() == 1) {
+    nsIWidget* widget = aReferenceFrame->GetNearestWidget();
+    if (widget) {
+      nsIWidget_MOZILLA_2_0_BRANCH* widget2 =
+        static_cast<nsIWidget_MOZILLA_2_0_BRANCH*>(widget);
+      widget2->UpdateThemeGeometries(CurrentPresShellState()->mThemeGeometries);
+    }
+  }
+
   // Unmark and pop off the frames marked for display in this pres shell.
   PRUint32 firstFrameForShell = CurrentPresShellState()->mFirstFrameMarkedForDisplay;
   for (PRUint32 i = firstFrameForShell;
        i < mFramesMarkedForDisplay.Length(); ++i) {
     UnmarkFrameForDisplay(mFramesMarkedForDisplay[i]);
   }
   mFramesMarkedForDisplay.SetLength(firstFrameForShell);
   mPresShellStates.SetLength(mPresShellStates.Length() - 1);
@@ -710,59 +721,48 @@ PRBool nsDisplayItem::RecomputeVisibilit
 
 void nsDisplaySolidColor::Paint(nsDisplayListBuilder* aBuilder,
                                 nsIRenderingContext* aCtx) {
   aCtx->SetColor(mColor);
   aCtx->FillRect(mVisibleRect);
 }
 
 static void
-RegisterThemeWidgetGeometry(nsIFrame* aFrame)
+RegisterThemeGeometry(nsDisplayListBuilder* aBuilder, nsIFrame* aFrame)
 {
-  nsPresContext* presContext = aFrame->PresContext();
-  nsITheme* theme = presContext->GetTheme();
-  if (!theme)
-    return;
-
   nsIFrame* displayRoot = nsLayoutUtils::GetDisplayRootFrame(aFrame);
-  nsIWidget* widget = displayRoot->GetNearestWidget();
-  // If the display root doesn't have a widget, just bail. Something
-  // weird is going on, maybe we're printing?
-  if (!widget)
-    return;
 
   for (nsIFrame* f = aFrame; f; f = f->GetParent()) {
     // Bail out if we're in a transformed subtree
     if (f->IsTransformed())
       return;
     // Bail out if we're not in the displayRoot's document
     if (!f->GetParent() && f != displayRoot)
       return;
   }
 
   nsRect borderBox(aFrame->GetOffsetTo(displayRoot), aFrame->GetSize());
-  theme->RegisterWidgetGeometry(widget,
-      aFrame->GetStyleDisplay()->mAppearance,
-      borderBox.ToNearestPixels(presContext->AppUnitsPerDevPixel()));
+  aBuilder->RegisterThemeGeometry(aFrame->GetStyleDisplay()->mAppearance,
+      borderBox.ToNearestPixels(aFrame->PresContext()->AppUnitsPerDevPixel()));
 }

Isn't aReferenceFrame in LeavePresShell is going to be different from displayRoot in RegisterThemeGeometry if aFrame is in a popup? Does that matter for the situations this is used?
(Assignee)

Updated

7 years ago
Duplicate of this bug: 625915
I downloaded the latest MineField release (1/15) on Mac OS X, the title bar seems to be hosed. I can type an address but it doesn't seem to show up in the title-bar, tried restarting, force quitting etc, same issue.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 25

7 years ago
This is affecting me on ff4b9, ff4b8 was okay on the same platform.

Possibly related to my missing UI elements, bug 626090?

If anybody wants to see this bug in action, here's a short video: http://www.youtube.com/watch?v=MARwpBmW6dk

I'm on Leopard, x86, nothing fancy
This bug didn't get fixed in time for beta 9. If you want to test you can either wait for the next beta or download a nightly build.

Comment 27

7 years ago
(In reply to comment #25)
> This is affecting me on ff4b9, ff4b8 was okay on the same platform.
> 
> Possibly related to my missing UI elements, bug 626090?
> 
> If anybody wants to see this bug in action, here's a short video:
> http://www.youtube.com/watch?v=MARwpBmW6dk
> 
> I'm on Leopard, x86, nothing fancy

FWIW this bug is in the release notes as a known issue for beta9...

Comment 28

7 years ago
I'm seeing this is in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 on 

Model Name:	Mac Pro
  Model Identifier:	MacPro3,1
  Processor Name:	Quad-Core Intel Xeon
  Processor Speed:	3 GHz
  Number Of Processors:	2
  Total Number Of Cores:	8
  L2 Cache (per processor):	12 MB
  Memory:	4 GB
  Bus Speed:	1.6 GHz
  Boot ROM Version:	MP31.006C.B05
  SMC Version (system):	1.25f4
(Assignee)

Updated

7 years ago
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Duplicate of this bug: 626410
Duplicate of this bug: 625294
You need to log in before you can comment on or make changes to this bug.