Closed Bug 579421 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: XUL, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: streetwolf52, Assigned: jimm)

References

Details

Attachments

(3 files, 1 obsolete file)

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.
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.
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.
Do you have a screenshot showing this?
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.
Blocks: 513162
(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.
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.
(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.
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.
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.
(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?
(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.
(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?
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.
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
The content area seems to paint much quicker by adjusting that preference lower, but I'm not able to reproduce attachment 457937 [details]
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
0 - 21 triggers the problem for me.
Make that 0-20.  21 and up is fine.
You might also find bug 180241 comments interesting.
Version: unspecified → Trunk
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.
Any particular add-on?
I just got an adblock update and i needed two restarts to get rid of mini title bar.
(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.  :)
(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.
also installing an hourly, and presumably a nightly. also produces the mini title bar until I restart 2 times.
Duplicate of this bug: 579693
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.
(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.)
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.
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
Attached patch setvisibility patch v.1 (obsolete) — Splinter Review
Assignee: nobody → jmathies
Attachment #461032 - Attachment is patch: true
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.)
Attachment #461032 - Flags: review?(bzbarsky)
blocking2.0: --- → ?
+      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.
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.
(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.
(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?
(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?
blocking2.0: ? → final+
Attached patch rev 2Splinter Review
Attachment #461032 - Attachment is obsolete: true
Attachment #462496 - Flags: review?(roc)
Attachment #461032 - Flags: review?(bzbarsky)
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!!!
Attachment #462496 - Flags: review?(roc) → review+
(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?
Attached patch updated patchSplinter Review
If we could land this for beta3, that would be really great. Try to get permission?
(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.
http://hg.mozilla.org/mozilla-central/rev/9bad7aab73d8
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Duplicate of this bug: 585415
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in before you can comment on or make changes to this bug.