notuptoyou Reporter
	Description • 14 years ago

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

Firefox is minimized to tray showing the "Tab Groups". The content of the window will be empty if you open a link in firefox from a external programm like skype or Word...

Reproducible: Always

Steps to Reproduce:
1. Verify Firefox is default Browser
2. Open new Firefox Window (Session)
3. Create second Tab
4. Click "Grouping Tabs"
5. Minimize View
6. Open a link from external (e.g. Skype conversation)
Actual Results:  
Firefox showing up without content.

Expected Results:  
Firefox showing up and opens the link in new tab

-

	Abhishek
	Comment 2 • 14 years ago

I am observing the same problem. Windows 7, 32 bit. FF4b9

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 3 • 14 years ago

FWIW, this doesn't happen on Mac.

Marking confirmed based on comment 2.

Can someone check Linux?

Nominating for softblocker status.

	Tim Taubert [:ttaubert] (inactive)
	Comment 4 • 14 years ago

Cannot reproduce on linux.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 5 • 14 years ago

In retrospect, what was I thinking? Un-nominating blocker status. Would be nice to have, but we can definitely ship without this.

	Dão Gottwald [:dao]
	Comment 6 • 14 years ago

(In reply to comment #5)
> In retrospect, what was I thinking?

"Massive fail when executing a standard browser operation is bad"?

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 7 • 14 years ago

(In reply to comment #6)
> (In reply to comment #5)
> > In retrospect, what was I thinking?
> 
> "Massive fail when executing a standard browser operation is bad"?

Oh wait, massive fail indeed. My apologies, I think I confused this with another bug. :(

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 8 • 14 years ago

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre

I just tried to reproduce this, and am unable to. I tried it both with minimizing the window (I assume that means minimizing it and putting it in the taskbar) and not, but it's the same... it works for me.

	Dão Gottwald [:dao]
	Comment 9 • 14 years ago

Can you reproduce with beta9?

Can the reporter reproduce with a recent nightly?

	Dão Gottwald [:dao]
	Comment 10 • 14 years ago

Please don't add "good first bug" to bugs with unknown scope.

	Abhishek
	Comment 11 • 14 years ago

I checked on 4.0b10pre 1/23 windows 7 32 bit. Seems fixed.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 12 • 14 years ago

Can we close this then?

	notuptoyou Reporter
	Comment 14 • 14 years ago

The Problem is not solved in Beta 10. But I have to extend the Steps to reproduce as follows:

Steps to Reproduce:
1. Verify Firefox is default Browser
2. Open new Firefox Window (Session)
--> 4.1 Maxmize Window <--
3. Create second Tab
4. Click "Grouping Tabs"
5. Minimize View
6. Open a link from external (e.g. Skype conversation)
Actual Results:  
Firefox showing up without content (Screenshot attached).

Expected Results:  
Firefox showing up and opens the link in new tab

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 15 • 14 years ago

(In reply to comment #13)
> Created attachment 507827 [details]
> Reopened Window after open a link from external

Is that an ubuntu persona you're using, or is that your wallpaper?

	notuptoyou Reporter
	Comment 16 • 14 years ago

(In reply to comment #15)
> (In reply to comment #13)
> > Created attachment 507827 [details]
> > Reopened Window after open a link from external
> Is that an ubuntu persona you're using, or is that your wallpaper?

it's an Ubuntu persona, not my Wallpaper. I will try it without using it, but i din't think that solves the Problem...

	Raymond Lee [:raymondlee]
	Comment 17 • 14 years ago

I've run the STR in comment 14 on ubuntu, windows XP and mac (4.012pre 2011-02-08) and I couldn't reproduce it.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 18 • 14 years ago

It's possible then that this is really limited to win7?

	Raymond Lee [:raymondlee]
	Comment 19 • 14 years ago

(In reply to comment #18)
> It's possible then that this is really limited to win7?

Can anyone with win7 verify that please?

	Raymond Lee [:raymondlee]
	Comment 20 • 14 years ago

I've managed to get a pc with Vista and tested it.  I can reproduce the STR in comment 0 if the menu bar is hidden the orange app menu is displayed).  If the menu bar is visible, the problem doesn't exist.

Do we do things differently when the menu bar is hidden?

	Raymond Lee [:raymondlee]
	Comment 21 • 14 years ago

I've used the DOM inspector to view the DOM and I've noticed that when Firefox is showing empty content, the titlebar has margin-bottom is bigger than 30000px.  It's probably something to do with code which set the margin-bottom for titlebar.

	Tim Taubert [:ttaubert] (inactive)
	Comment 22 • 14 years ago

(In reply to comment #21)
> I've used the DOM inspector to view the DOM and I've noticed that when Firefox
> is showing empty content, the titlebar has margin-bottom is bigger than
> 30000px.  It's probably something to do with code which set the margin-bottom
> for titlebar.

Yep, somehow the bottom margin is not correctly calculated (probably because panorama is not taken into account). Verifying this on Win7.

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#5089

	Tim Taubert [:ttaubert] (inactive)
	Comment 23 • 14 years ago

Is there any way we can test this automatically? I verified this solution on my win 7 VM.

	Tim Taubert [:ttaubert] (inactive)
	Comment 24 • 14 years ago

Passed try. Works on Windows 7.

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=6be97d800dd9

	Ian Gilman [:iangilman]
	Comment 25 • 14 years ago

Comment on attachment 512190 [details] [diff] [review]
patch v1

I don't know how you simulate an external link in a test. Perhaps this is a job for litmus?

	Dão Gottwald [:dao]
	Comment 26 • 14 years ago

Has anyone sorted out what exactly is going on here? What exactly is the setTimeout waiting for and why is it a reliable solution?

	Tim Taubert [:ttaubert] (inactive)
	Comment 27 • 14 years ago

(In reply to comment #26)
> Has anyone sorted out what exactly is going on here? What exactly is the
> setTimeout waiting for and why is it a reliable solution?

Thanks for probing into, Dão. While searching for a good explanation I came up with a more reliable solution:

The problem is: when the browser windows is minimized we get window.screenX/Y = -30000px. So when minimized we'll have to wait until the browser window got activated again and trigger the calculation afterwards.

	Tim Taubert [:ttaubert] (inactive)
	Comment 28 • 14 years ago

Test added. Sent to try with and without fix to verify the test is working as expected.

	Ian Gilman [:iangilman]
	Comment 29 • 14 years ago

Comment on attachment 512755 [details] [diff] [review]
patch v3 (with test)

Looks good to me; thanks for digging in deeper!

	Tim Taubert [:ttaubert] (inactive)
	Comment 30 • 14 years ago

Try run with test and fix:

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=cddeb88f95b1

Try run with test (but without fix):

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=f80f8c5738df

	Ian Gilman [:iangilman]
	Comment 31 • 14 years ago

Comment on attachment 513905 [details] [diff] [review]
patch v4

>+  registerCleanupFunction(function () {
>+    window.restore();
>+    window.restore();
>+  });

Do we really need both of these restores?

>+  window.maximize();
>+  window.minimize();

Can you explain how this simulates the STR for this bug? I would think you would minimize and then restore, just based on the description of the bug.

	Tim Taubert [:ttaubert] (inactive)
	Comment 32 • 14 years ago

(In reply to comment #31)
> Do we really need both of these restores?

The first restores the maximized state. The second the normal state.

> Can you explain how this simulates the STR for this bug? I would think you
> would minimize and then restore, just based on the description of the bug.

The test window is in normal state. So we first need to maximize it (tabs are drawn to the titlebar only in maximized state). After that we need to minimize it.

	Dão Gottwald [:dao]
	Comment 33 • 14 years ago

I think this should probably fixed in TabsInTitlebar in browser.js. It checks the sizemode attribute, but it looks like it should check window.windowState instead.

	Ian Gilman [:iangilman]
	Comment 34 • 14 years ago

(In reply to comment #32)
> (In reply to comment #31)
> > Do we really need both of these restores?
> 
> The first restores the maximized state. The second the normal state.
> 
> > Can you explain how this simulates the STR for this bug? I would think you
> > would minimize and then restore, just based on the description of the bug.
> 
> The test window is in normal state. So we first need to maximize it (tabs are
> drawn to the titlebar only in maximized state). After that we need to minimize
> it.

Cool, thanks for explaining. 

Please address Dao's comment.

	Tim Taubert [:ttaubert] (inactive)
	Comment 35 • 14 years ago

(In reply to comment #33)
> I think this should probably fixed in TabsInTitlebar in browser.js. It checks
> the sizemode attribute, but it looks like it should check window.windowState
> instead.

Done. Passed try:

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=c72c5c85cfbd

	Dão Gottwald [:dao]
	Comment 36 • 14 years ago

Comment on attachment 514446 [details] [diff] [review]
patch v5

>-    // Don't trust the initial value of the sizemode attribute; wait for the resize event.
>+    // Don't trust the initial value of windowState; wait for the resize event.
>+    this.allowedBy("maximized", false);

Did you check if this is still necessary?

>   _update: function () {
>-    if (!this._initialized || window.fullScreen)
>+    if (!this._initialized)
>       return;

This doesn't regress bug 624123?

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 37 • 14 years ago

[bugspam: betaN -> final]

My instinct is to punt on this, but Dāo would have a better idea of whether we could land this post-betaN. Dāo, can you weigh in here? Should we punt at this time?

	Tim Taubert [:ttaubert] (inactive)
	Comment 38 • 14 years ago

(In reply to comment #36)
> Did you check if this is still necessary?

Removed it and still passes.

> This doesn't regress bug 624123?

No, added a test for this bug.

(In reply to comment #37)
> My instinct is to punt on this, but Dāo would have a better idea of whether we
> could land this post-betaN. Dāo, can you weigh in here? Should we punt at this
> time?

I don't know if we get approval for this but I have a patch (still waiting for try) that I will attach later that fixes this and also bug 633816. It includes tests for both of them and a test for bug 624123. And the patch itself is rather small - I think we should give it a try...

	Tim Taubert [:ttaubert] (inactive)
	Comment 39 • 14 years ago

This also fixes bug 633816. Includes tests for bug 633816, bug 624123 and of course this bug.

Passed try:

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=3e6b9f9e3f23

	Dão Gottwald [:dao]
	Comment 40 • 14 years ago

Comment on attachment 514615 [details] [diff] [review]
patch v6

>-    // Don't trust the initial value of the sizemode attribute; wait for the resize event.
>-    this.allowedBy("sizemode", false);

>+    window.addEventListener("resize", function () {
>+      TabsInTitlebar.allowedBy("maximized",
>+                               window.windowState == window.STATE_MAXIMIZED);
>     }, false);

I think you need to call either TabsInTitlebar.allowedBy("maximized", false); or TabsInTitlebar.allowedBy("maximized", window.WindowState == ...); immediately, otherwise this effectively allows tabs in the titlebar until the resize event occurs the first time.

	Tim Taubert [:ttaubert] (inactive)
	Comment 41 • 14 years ago

(In reply to comment #40)
> I think you need to call either TabsInTitlebar.allowedBy("maximized", false);
> or TabsInTitlebar.allowedBy("maximized", window.WindowState == ...);
> immediately, otherwise this effectively allows tabs in the titlebar until the
> resize event occurs the first time.

Fixed. Passed try, too :)

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=70484aae1dbf

	Tim Taubert [:ttaubert] (inactive)
	Comment 42 • 14 years ago

Comment on attachment 514637 [details] [diff] [review]
patch v7

Pushed to try to make sure the tests for bug 633816 and this one fail without the fix:

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=3ad63326eea0

	Dão Gottwald [:dao]
	Comment 43 • 14 years ago

Comment on attachment 514637 [details] [diff] [review]
patch v7

>-    window.addEventListener("resize", function (event) {
>-      if (event.target != window)
>-        return;
>+    window.addEventListener("resize", function () {

You need to add a comment here that you're relying on the resize event for content windows for maximized<->fullscreen transitions.

	Dão Gottwald [:dao]
	Comment 44 • 14 years ago

Comment on attachment 514637 [details] [diff] [review]
patch v7

> var TabsInTitlebar = {
>   init: function () {
> #ifdef CAN_DRAW_IN_TITLEBAR
>     this._readPref();
>     Services.prefs.addObserver(this._prefName, this, false);
> 
>-    // Don't trust the initial value of the sizemode attribute; wait for the resize event.
>-    this.allowedBy("sizemode", false);
>-    window.addEventListener("resize", function (event) {
>-      if (event.target != window)
>-        return;
>-      let sizemode = document.documentElement.getAttribute("sizemode");
>-      TabsInTitlebar.allowedBy("sizemode",
>-                               sizemode == "maximized" || sizemode == "fullscreen");
>+    this.allowedBy("maximized", window.windowState == window.STATE_MAXIMIZED);
>+    window.addEventListener("resize", function () {
>+      TabsInTitlebar.allowedBy("maximized",
>+                               window.windowState == window.STATE_MAXIMIZED);
>     }, false);
> 
>     this._initialized = true;

Oh, and you need to set this._initialized before calling this.allowedBy("maximized", window.windowState == window.STATE_MAXIMIZED).

	Tim Taubert [:ttaubert] (inactive)
	Comment 45 • 14 years ago

Passed try:

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tim.taubert@gmx.de&rev=836054423677

Thanks Dão for your reviews!

Note to approvers:

Very lightweight patch that fixes TabsOnTop display bugs for windows users. It includes two tests (for this bug and bug 633816). It includes a third test to make sure we don't regress bug 624123.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 46 • 14 years ago

Comment on attachment 515141 [details] [diff] [review]
patch v8

We can evaluate an approval after we ship, but for now any touching browser.js makes me nervous.

	Dão Gottwald [:dao]
	Comment 47 • 14 years ago

Comment on attachment 515141 [details] [diff] [review]
patch v8

>+    // this will also handle maximized <-> fullscreen transitions
>+    window.addEventListener("resize", function () {

The comment should be inside of the handler and mention how and why this handles maximized<->fullscreen.

	Tim Taubert [:ttaubert] (inactive)
	Comment 48 • 14 years ago

(In reply to comment #47)
> The comment should be inside of the handler and mention how and why this
> handles maximized<->fullscreen.

Done.

	Dão Gottwald [:dao]
	Comment 49 • 14 years ago

(In reply to comment #48)
> Created attachment 516300 [details] [diff] [review]
> patch v9
> 
> (In reply to comment #47)
> > The comment should be inside of the handler and mention how and why this
> > handles maximized<->fullscreen.
> 
> Done.

Nope... You're still not saying what exactly is going on there. Specifically, when going from maximized to fullscreen, the event isn't dispatched to the global window, it merely bubbles up to it. This only works because you removed the (event.target != window) check.

	sensemann.jb
	Comment 51 • 14 years ago

I've a similar problem / effect, and I can give you an alternate way to reproduce.

I used FirefoxPortableTest_4.0_RC_1_English.paf from http://portableapps.com/
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
OS: Windows XP SP3 professional, German.
Should I file a new Bug, because it's a different OS?

Reproducible: Always

Steps to Reproduce:
1. Verify Firefox is default Browser.
2. Start only one and new Firefox process (with or without -safe-mode don't makes differences).
3. Have only one tab open (Firefox default welcome site).
4. Hide Menu bar so you only have the new small orange Firefox menu button.
5. Disable "always show the tab bar" in options -> tabs.
5. Minimize Firefox window to task bar.
6. Open a link from external (e.g. Skype conversation, Thunderbird) 
Actual Results:  
Firefox showing up without content.

Expected Results:  
Firefox showing up and opens the link in new tab.

Differences to here shown Win7 screenshot: My Firefox window is not transparent it has complete grey background.
see screenshot WindowsXP_empty_window.png

PS:

	Kevin Hanes
	Comment 52 • 14 years ago

bugspam

	Tim Taubert [:ttaubert] (inactive)
	Comment 54 • 14 years ago

bugspam

	Tim Taubert [:ttaubert] (inactive)
	Comment 55 • 14 years ago

bugspam

	Tim Taubert [:ttaubert] (inactive)
	Comment 56 • 13 years ago

bugspam

(Fx7 was branched, removing open bugs from Fx7 meta bug, we won't create new meta bugs for upcoming Fx versions)

	u279076
	Comment 57 • 11 years ago

Is this still an issue for anyone?

	sensemann.jb
	Comment 58 • 11 years ago

Comment on attachment 520172 [details]
Empty Firefox window after opening url from external application

No longer problems with version 22.0 (and some previous too).

	u279076
	Comment 59 • 11 years ago

Thanks sensemann, resolving WORKSFORME based on comment 58.