579421 - Title bar(window without body) appears at the upper left corner of monitor screen

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Gary [:streetwolf52]]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre
Build Identifier: 20100716080508

A mini title bar (min, max/restore, close buttons) appears briefly at Fx startup when the Fx menu is hidden and the Fx button isn't displayed.  I see a white rectangle when the Fx button is displayed.



Reproducible: Always




Appears to have been introduced by https://bugzilla.mozilla.org/show_bug.cgi?id=574690 which looks like it fixes the problem.

I had this same problem awhile ago (maybe Beta 1) but it went away at some point. Today's nightly reintroduced it.

Comment 1

[Gary [:streetwolf52]]

Seems to be caused by many add-ons to one degree or another.  Some add-ons will produce the mini title bar very, very fast while others will keep them on the screen longer so you notice it. 

One add-on that keeps it on the screen the longest is LastPass 1.69.1. This might be because LP logs into it's server.  Also Adblock Plus shows the mini title bar but not as long. 

IMO all add-ons might cause this behavior.  Some you might not notice because it happens so fast, others you do.

Comment 2

[Gary [:streetwolf52]]

btw... happens to maximized or non-maximized windows.  It's easier to see when the window isn't maxed and the upper left corner of the screen is clear.

Comment 3

[[not reading bugmail]]

Do you have a screenshot showing this?

Comment 4

[Gary [:streetwolf52]]

Happens to fast to take a ss.  It is just a window with the buttons on it.  About the size of the Fx menu button.

Comment 5

[Gary [:streetwolf52]]

Attachment: Simulation of what it looks like

Comment 6

[[not reading bugmail]]

(In reply to comment #5)
> Created attachment 457937 [details]
> Simulation of what it looks like

That looks familiar, and sort of what I tried to comment about here:
bug 574690 comment 6.

Comment 7

[Gary [:streetwolf52]]

This all started when 574690 landed on the nightly this morning.  

I hide the new Fx Menu Button.  When I have it showing the title bar box is completely white.  When the Fx window displays I see what looks like the same white rectangle over the Nav bar.

Also if I have no titlebar at all I get the white box.

Almost seems this is some other task produced by add-ons or Fx which until the nightly wasn't seen.

Comment 8

[Jim Mathies [:jimm]]

(In reply to comment #1)
> Seems to be caused by many add-ons to one degree or another.  Some add-ons will
> produce the mini title bar very, very fast while others will keep them on the
> screen longer so you notice it. 
> 
> One add-on that keeps it on the screen the longest is LastPass 1.69.1. This
> might be because LP logs into it's server.  Also Adblock Plus shows the mini
> title bar but not as long. 
> 
> IMO all add-ons might cause this behavior.  Some you might not notice because
> it happens so fast, others you do.

I'm not sure add-ons have an effect. I installed both last pass and add block and enabled both, still unable to reproduce on win 7, aero, aero basic, and classic mode.

Comment 9

[Gary [:streetwolf52]]

Might depend on how many sites you have defined in each add-on.  A first time install of each will probably have very little data.

Comment 10

[Gary [:streetwolf52]]

No problem: http://hg.mozilla.org/mozilla-central/rev/b141a304ad08

Problem:    http://hg.mozilla.org/mozilla-central/rev/7124132f0506

I also see a thin white rectangle that appear briefly under the real title bar on the very left side.  Wonder if it's the Fx Menu Bar.

Comment 11

[Jim Mathies [:jimm]]

(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 457937 [details] [details]
> > Simulation of what it looks like
> 
> That looks familiar, and sort of what I tried to comment about here:
> bug 574690 comment 6.

Dale, are you seeing the window in the upper left corner at all?

Comment 12

[[not reading bugmail]]

(In reply to comment #11)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Created attachment 457937 [details] [details] [details]
> > > Simulation of what it looks like
> > 
> > That looks familiar, and sort of what I tried to comment about here:
> > bug 574690 comment 6.
> 
> Dale, are you seeing the window in the upper left corner at all?

I haven't seen it all again since the changes happened yesterday and i have several add-ons installed right now.

Comment 13

[[not reading bugmail]]

(In reply to comment #11)
> Dale, are you seeing the window in the upper left corner at all?

No.  I don't know what triggers it.  But before it was obvious.  Testing Win7 32bit, any chance its a 64 bit bug?

Comment 14

[[not reading bugmail]]

Um, well, I just did a test on a brand new profile with the most recent build.  I had the window minimized before starting the browser up with a brand new profile, maybe I see it now, as it seems I see the white square before it resizes, but I don't see this on my older profile anymore.

Comment 15

[Gary [:streetwolf52]]

Seems that this setting in prefs.js is the cause.  

user_pref("nglayout.initialpaint.delay", 0);

I deleted it and took the default of 250ms and I don't see the mini title bar.  Having a fast connection I always had it set to 0 and had no problem until bug 574690

Comment 16

[[not reading bugmail]]

The content area seems to paint much quicker by adjusting that preference lower, but I'm not able to reproduce attachment 457937 [details]

Comment 17

[Jim Mathies [:jimm]]

(In reply to comment #15)
> Seems that this setting in prefs.js is the cause.  
> 
> user_pref("nglayout.initialpaint.delay", 0);
> 
> I deleted it and took the default of 250ms and I don't see the mini title bar. 
> Having a fast connection I always had it set to 0 and had no problem until bug
> 574690

Bingo! I'm seeing this now with this pref set! Will try and track down the cause.

Comment 18

[Gary [:streetwolf52]]

0 - 21 triggers the problem for me.

Comment 19

[Gary [:streetwolf52]]

Make that 0-20.  21 and up is fine.

Comment 20

[[not reading bugmail]]

You might also find bug 180241 comments interesting.

Comment 21

[Gary [:streetwolf52]]

FYI... I also get the mini title bar after installing/updating an addon even with a high delay number.  Usually takes two restarts of Fx to get rid of it.

Comment 22

[[not reading bugmail]]

Any particular add-on?

Comment 23

[Gary [:streetwolf52]]

I just got an adblock update and i needed two restarts to get rid of mini title bar.

Comment 24

[[not reading bugmail]]

(In reply to comment #13)
> (In reply to comment #11)
> > Dale, are you seeing the window in the upper left corner at all?
> 
> No.  

Now I do, after I installed LastPass 1.69.1 for sure I see it and I already had latest ABP running, and just updated it with todays update.

Adding LastPass seems to reproduce it for me, I have the pref set to 0, have the menubar enabled, made my browser window smaller than the whole screen, so I can see the upper left corner of my desktop, now I see attachment 457937 [details] flash quickly as mentioned in comment 1.  :)

Comment 25

[[not reading bugmail]]

(In reply to comment #15)
> Seems that this setting in prefs.js is the cause.  
> 
> user_pref("nglayout.initialpaint.delay", 0);
> 
> I deleted it and took the default of 250ms and I don't see the mini title bar. 

Confirming.

Comment 26

[Gary [:streetwolf52]]

also installing an hourly, and presumably a nightly. also produces the mini title bar until I restart 2 times.

Comment 28

[Darren Burnhill]

With regard to Bug 579693, the window is persistent, once it appears it is there until I restart FF. Plus it isn't present on a normal start up and only appears when I launch a link from with an application (Dreamweaver) with the link to the exe specified. Launching a link that merely calls the default browser doesn't produce the additional window.

Comment 29

[Jim Mathies [:jimm]]

(In reply to comment #28)
> With regard to Bug 579693, the window is persistent, once it appears it is
> there until I restart FF. Plus it isn't present on a normal start up and only
> appears when I launch a link from with an application (Dreamweaver) with the
> link to the exe specified. Launching a link that merely calls the default
> browser doesn't produce the additional window.

I'm not sure how it could stick around, I believe it's the firefox window before it fully loads. That or we are dealing with the hidden message window, but I don't think document viewer ever calls Show on that. (I think there's a flag to make sure it doesn't.)

Comment 30

[Darren Burnhill]

It would seem that a second instance is initiated (it can be seen in Task Manager), hence the window loading, but that instance doesn't disappear until I close the actual tab created by the application call.

Comment 31

[Ken]

I also have been seeing this (Title bar upper left hand side of screen), when starting Minefield for some time.

I also started Minefield in safe mode (no add-ons should be loaded), same thing happens (small title bar appears in upper left side of screen), only it does not stay on the screen as long.

Using current build:
Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100726 Minefield/4.0b3pre ( .NET CLR 3.5.30729) Firefox/3.6.6 ID:20100726040625

Comment 32

[Jim Mathies [:jimm]]

Attachment: setvisibility patch v.1

Comment 33

[Jim Mathies [:jimm]]

Comment on attachment 461032 [details] [diff] [review]
setvisibility patch v.1

This revisits what we were trying to do in bug 574690. The approach is slightly different in that it turns our nxXULWindow's SetVisibility already supported delayed showing, so I'm using that instead. I think this will fix any remaining bugs related to document viewer calling show prematurely on top level widgets. (In the specific case of the delayed paint timer set to zero, the window show is delayed.)

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+      if (treeItem) {
+      nsCOMPtr<nsIDocShellTreeOwner> owner;
+      treeItem->GetTreeOwner(getter_AddRefs(owner));

Fix indent

Instead of using a 'handled' boolean, I suggest using a helper function SetVisibilityOnXULWindow(nsIDocShellTreeItem*) which returns true if it succeeded and false if it failed.

But won't this go wrong if nsXULWindow::mShowAfterLoad is false in the XUL window, or if nsXULWindow::OnChromeLoaded has already been called? Seems like we need that nsXULWindow::WillShowWidgetAfterLoad method that we talked about before.

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We need this patch to fix acceleration of fullscreen video playback on Windows.

Currently this bug causes the fullscreen video to be initialized before the window finishes loading, so the fullscreen video is set up before the window is marked for acceleration, which confuses things.

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

jmathies, ping?

Comment 37

[Jim Mathies [:jimm]]

(In reply to comment #34)
> +      if (treeItem) {
> +      nsCOMPtr<nsIDocShellTreeOwner> owner;
> +      treeItem->GetTreeOwner(getter_AddRefs(owner));
> 
> Fix indent
> 
> Instead of using a 'handled' boolean, I suggest using a helper function
> SetVisibilityOnXULWindow(nsIDocShellTreeItem*) which returns true if it
> succeeded and false if it failed.

Will update here in a day or so, wrapped up in something that's blocking betaN. 
 
> 
> But won't this go wrong if nsXULWindow::mShowAfterLoad is false in the XUL
> window, or if nsXULWindow::OnChromeLoaded has already been called? Seems like
> we need that nsXULWindow::WillShowWidgetAfterLoad method that we talked about
> before.

Hmm, doesn't look like it. mShowAfterLoad is set to the visible state in SetVisibility if mChromeLoaded is false. Otherwise the window is shown directly with a call to the widget.

Comment 38

[Markus Stange [:mstange]]

(In reply to comment #37)
> Otherwise the window is shown directly with a call to the widget.

... and then we'd have the case of showing a toplevel window inside a reflow, which we're trying to avoid in bug 577208, no?
The question is, can the case mChromeLoaded == true + widget still hidden happen at this point in practice?

Comment 39

[Jim Mathies [:jimm]]

(In reply to comment #38)
> (In reply to comment #37)
> > Otherwise the window is shown directly with a call to the widget.
> 
> ... and then we'd have the case of showing a toplevel window inside a reflow,
> which we're trying to avoid in bug 577208, no?

I don't believe so. This patch should fix bug 577208, since the the first Show on the actual widget is delayed until the chrome is loaded. The Show stack in bug 577208 would never happen, the display of the window is delayed. But this only happens if document viewer has requested the window be shown. This is the way things worked before the child widget removal code landed AFAICT.

> The question is, can the case mChromeLoaded == true + widget still hidden
> happen at this point in practice?

Sure, you can create a hidden window that loads chrome, then display the window. But how is a call to xulwindow->setvisibility() different from widget->show() in in this case?

Comment 40

[Jim Mathies [:jimm]]

Attachment: rev 2

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 462496 [details] [diff] [review]
rev 2

+    nsCOMPtr<nsIXULWindow> xulWin;
+    nsCOMPtr<nsIBaseWindow> baseWin;
+    xulWin = do_GetInterface(owner);
+    baseWin = do_GetInterface(xulWin);

does nsCOMPtr<nsIXULWindow> xulWin = do_GetInterface(owner) not work?

+  NS_WARNING("Doc viewer attached to a parent that isn't a xul winodw??");

typo

Let's get this in!!!

Comment 42

[Jim Mathies [:jimm]]

(In reply to comment #41)
> Comment on attachment 462496 [details] [diff] [review]
> rev 2
> 
> +    nsCOMPtr<nsIXULWindow> xulWin;
> +    nsCOMPtr<nsIBaseWindow> baseWin;
> +    xulWin = do_GetInterface(owner);
> +    baseWin = do_GetInterface(xulWin);
> 
> does nsCOMPtr<nsIXULWindow> xulWin = do_GetInterface(owner) not work?
> 

Yes, was spelling things out while debugging. updated.

> +  NS_WARNING("Doc viewer attached to a parent that isn't a xul winodw??");
> 
> typo

fixed.

> 
> Let's get this in!!!

Tree's closed for the b3 freeze. :/ Does the accelerated video problem warrant pushing for b3 or can it wait until after the tree re-opens?

Comment 43

[Jim Mathies [:jimm]]

Attachment: updated patch

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If we could land this for beta3, that would be really great. Try to get permission?

Comment 45

[Bas Schouten (:bas.schouten)]

(In reply to comment #42)
> (In reply to comment #41)
> > Comment on attachment 462496 [details] [diff] [review] [details]
> > rev 2
> > 
> > +    nsCOMPtr<nsIXULWindow> xulWin;
> > +    nsCOMPtr<nsIBaseWindow> baseWin;
> > +    xulWin = do_GetInterface(owner);
> > +    baseWin = do_GetInterface(xulWin);
> > 
> > does nsCOMPtr<nsIXULWindow> xulWin = do_GetInterface(owner) not work?
> > 
> 
> Yes, was spelling things out while debugging. updated.
> 
> > +  NS_WARNING("Doc viewer attached to a parent that isn't a xul winodw??");
> > 
> > typo
> 
> fixed.
> 
> > 
> > Let's get this in!!!
> 
> Tree's closed for the b3 freeze. :/ Does the accelerated video problem warrant
> pushing for b3 or can it wait until after the tree re-opens?

It should. This is blocking 583012 which is a pretty bad full-screen video bug.

Comment 46

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/9bad7aab73d8

Comment 48

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336