236100 - No Full-screen mode on next startup when browser is switched in full-screen mode when exiting

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Pavel Salac]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.6) Gecko/20040206 Firefox/0.8

not sure wheteher its intentional, but Firefox (tested on Firebird 0.6 and
Firefox 0.8) does not launch in full-screen mode, when switched to this mode
prior to its shutdown, it alway launched in windowed mode and has to be switched
to full-screen mode manually.

Reproducible: Always
Steps to Reproduce:
1. launch Firefox. let it open and load initial webpage
2. switch to Full-screen mode by pressing (F11) key or via View/Full-screen menu.
3. close browser via (Alt-F4) or via GUI element, while still in full-screen mode.
4. re-launch Firefox. it starts in windowed mode

Actual Results:  
Firefox starts in windowed mode no matter what was his state when closing it.

Expected Results:  
I should start in the same mode it was when closing this app.

Comment 1

[Rene Pronk]

Confirming with Firefox 0.8 under WinXP for now.

There are however several near duplicates floating around (132371, 62329, 32148)
but they all seem to apply to the suite and not to Firefox and have comments
stating they are WFM. Can't test it right now with the suite.

Comment 2

[Ben Fowler]

If the behaviour you are requesting (your expected result) is what people
want, then fair enough; but it is not what I would want. I would never want
an application to come up after a restart without a menubar (unless it was
some form of carefully configured kiosk application).

Ben

Comment 3

[Peraxel]

I hava a similar bug.
When I use "Full Screen" mode and then gets a load error for my web applocation
(I develop in Flash MX and must test all possible connection states) when I turn
off the webserver I can not restore Full Screen with F11 again. The Browser does
not respond at all. Must close it with Alt-F4. I also gets the Status Bar in
full screen mode which I does not expect.

Comment 4

[Asa Dotzler [:asa]]

*** Bug 240619 has been marked as a duplicate of this bug. ***

Comment 5

[Mathias Wittlock]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

Since Bug 240619 was marked a duplicate of this one I will add it here (although
I think these two bugs are adressing slightly different things). This bug
suggests that when exiting the browser in full-screen (F11) mode it doesn't
remember that when restarting, whereas Bug 240619 mentioned the fact that the
window size used before maximizing and then full-screening was forgotten. I've
noticed a similar problem as to what Bug 126730 mentions where the same problem
appears, without browser being restarted.

Steps to reproduce:
1. Open up Firefox in Windowed mode, preferably less then 90% of your screen size.
2. Maximize Firefox.
3. Enter full-screen (F11)
4. Exit full-screen (F11)
5. Restore Firefox.

Result:
Firefox has a size that fills the whole screen.

Expected result:
Firefox remembering the windowed size had in step 1.

Reproducible: Always.

This is a slightly different issue then what this bug describes, but as I said,
since Bug 240619 which I felt adressed this was marked as a duplicate of this
one I thought I'd post it here. I suggest either exploring if these two bugs
originate from the same problem, if not, then Bug 240619 maybe should be re-opened.

While I'm at it I can confirm this bug behaviour as described in the first post
and I also expect the browser to remain in the same state as I left it, be it
full-screen, maximized or Windowed, but even if it were to be left in a
non-full-screen mode then I at least want it to remember my window-size used
before entering full-screen and give me that, this also holds if full-screen is
what I get when I restart, but that is most likely connected to what "my
version" of this bug report adresses.

Comment 6

[Asa Dotzler [:asa]]

I believe that windows and Linux have different code here so this is a
pre-emptive "please don't add linux comments here" post.

There are two issues here, the persistence after restart and the going to
maximized then fullscreen then restored loses the users's restored settings
(instead making a nearly fullscreen window).  I think that the restart
persistence often leads to the bad restored state so they're inter-related
enough that we should probably tackle them together unless a developer says they
need separate patches.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

*** Bug 320867 has been marked as a duplicate of this bug. ***

Comment 8

[Mathias Wittlock]

Both bugs are still present in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

What's it gonna take to get this bug accepted?

Comment 9

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051224 Firefox/1.6a1

(In reply to comment #8)
> [ snip ]
> 
> What's it gonna take to get this bug accepted?

If that is meant as a serious question, then just two things: A patch and its review.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html has the negative 
advice: "No pointless comments", but not the positive that you were asking 
about.

Comment 10

[Mathias Wittlock]

And with a fresh profile, no extensions, both bugs are also present in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

(In reply to comment #9)
> > What's it gonna take to get this bug accepted?
> 
> If that is meant as a serious question, then just two things: A patch and its
> review.
> 
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html has the negative 
> advice: "No pointless comments", but not the positive that you were asking 
> about.

Well, that comment came out a bit wrong, I posted a bit too late in the day. What I was wondering what it'd take for the bug to be accepted as a bug, I confused the option "accept" with the one that changes a bug from "unconfirmed" to "new" (and that "new" meant "unconfirmed"). Now that I remember "new" means that bug is accepted, that comment is out of place.

And it was a side comment in a reply that otherwise pointed out that the bug was still present in a much newer version (just like this one), so it wasn't all pointless.

Comment 11

[Ben Fowler]

(In reply to comment #10)
> [ snip ]
> What I was wondering what it'd take for the bug to be accepted as a bug, I
> confused the option "accept" with the one that changes a bug from 
> "unconfirmed" to "new" (and that "new" meant "unconfirmed"). Now that I 
> remember "new" means that bug is accepted, ...

Quite right. See http://www.mozilla.org/bugs/ for more info, though that page 
isn't very crisp; also http://deuce.doc.wustl.edu/bugzilla/queryhelp.cgi and 
perhaps http://sucs.org/~sits/mozilla/unco/ . I still feel that the next thing
that this bug needs is a patch!

Comment 12

[Phil Ringnalda (:philor)]

*** Bug 358959 has been marked as a duplicate of this bug. ***

Comment 15

[ragerino]

Happens also for Firefox 9.0 (beta channel).

Comment 16

[Dan Jacobson]

Still seen in 66.0.1 (64-bit) Linux.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 18

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.