540180 - When exiting Firefox from full-screen mode title bar buttons missing after restart

Status: RESOLVED DUPLICATE of bug 517379

(Firefox :: Toolbars and Customization, defect)

Description

[hb2001]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2pre) Gecko/20100113 Ubuntu/9.04 (jaunty) Namoroka/3.6pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2pre) Gecko/20100113 Ubuntu/9.04 (jaunty) Namoroka/3.6pre

In Jaunty 32 bit, its the  only program (including Shireteko) with missing m/m/c option on top bar.

Reproducible: Always

Steps to Reproduce:
1. is the normal state
2.
3.
Actual Results:  
n/a

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Which theme you have installed in Ubuntu? Can you please attach a screenshot.

Comment 2

[Pascal Chevrel:pascalc]

I can reproduce this in 3.6RC2 on Karmic with the following steps:

1/ click on F11 to go to full screen mode
2/ close firefox from the close widget button
3/ reopen Firefox

expected result:
firefox opens in non-full-screen mode

actual result:
Firefox opens in non-fulls-screen mode but the window bar is missing

It also happens on trunk, 3.5.7 is not affected so this is a regression.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Pascal, would you have time to check older beta releases of Firefox 3.6 or even nightly builds so we have a regression range?

Comment 4

[hb2001]

Attachment: screenshot of bug

Note. This is happening on an eee pc 900a netbook. 

Unlike ff3.5, the 3.6 window also does behave properly, as it covers the Jaunty main menu bar at the top of the screen, rather than to snugly sit beneath it.

Comment 5

[Pascal Chevrel:pascalc]

Henrik, not sure I will have time because since you need to close the application to reproduce the bug with the steps I found, I can't use regression.py...

Comment 6

[hb2001]

(In reply to comment #1)
> Which theme you have installed in Ubuntu? Can you please attach a screenshot.

The default human theme is in use. A screenshot of 3.6 bug has been submitted. Note that, in addition, it also covers the main menubar, with no option to access the bar other than going to file--->quit to shut down 3.6.

NOTE: This is not a Compiz problem, as I disabled the desktop and no difference was noted.

Also, when the menubar is set to "hide," it fails to pop over 3.6 when the cursor is put to the top of the screen.

Comment 7

[hb2001]

(In reply to comment #4)
> Correction (edit)... the sentence should read:

> Unlike ff3.5, the 3.6 window itself also misbehaves, as it covers the Jaunty
> main menu bar at the top of the screen, rather than to snugly sit beneath it.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

(In reply to comment #5)
> Henrik, not sure I will have time because since you need to close the
> application to reproduce the bug with the steps I found, I can't use
> regression.py...

No need for the regression.py. Just download all of our 3.6 beta releases and test those. Once we know between which releases the regression has been started, it's easier to find the reason.

Comment 9

[Pascal Chevrel:pascalc]

here is the regression range on Trunk:

GOOD:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091110 Minefield/3.7a1pre
Built from http://hg.mozilla.org/mozilla-central/rev/f4ef40336cc6

BAD:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre
Built from http://hg.mozilla.org/mozilla-central/rev/b00b441c641f

Comment 10

[Pascal Chevrel:pascalc]

wild guess, looking at the patches that day, this one looks related to windows:
http://hg.mozilla.org/mozilla-central/rev/dc39e856ea45

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Wow, that's fast. Thanks Pascal!

For reference here the check-ins:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4ef40336cc6&tochange=b00b441c641f

I really suspect that this is a regression from bug 527615.

Comment 12

[Karl Tomlinson (:karlt)]

Is this the same as bug 517379?
i.e. is the window the size of the screen? (rather than the last non-fullscreen size)

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

I don't think so. We have different regression ranges here.

Comment 14

[Karl Tomlinson (:karlt)]

This is the history in chronological order as I know it:

Before the fix for bug 510546 landed, fullscreen state was not saved.
After bug 510546 was fixed, fullscreen state was saved but browser.js was not
  set up to deal with that (leading to bug 517379).
The patch that landed in bug 509278 exposed bug 527615.
  I'm guessing that bug 527615 temporarily masked bug 517379 until bug 527615
  was fixed.

If the symptoms are the same (they seem the same on my system), then it is really another report of the same bug.
There may be a question as to whether restoring the fullscreen state is desirable or whether browser.js should be fixed.  Bug 517379 seems an appropriate place to discuss that though.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Looks like a complex dependency. Given that and you can better handle it in your already filed bug 517379, we can dupe it. Thanks!