732812 - Thunderbird Not Maximized When Launched

Status: UNCONFIRMED

(Thunderbird :: Mail Window Front End, defect)

Description

[ppr]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Iceweasel/10.0.2
Build ID: 20120217174734

Steps to reproduce:

I open thunderbird (for me icedove on debian) and I maximize the window by dragging it to the top (gnome-shell). Then I close thunderbird.


Actual results:

When I start again thunderbird, it does not start in a maximized size but only covers 75% of my screen (like at the first start).


Expected results:

Thunderbird should remember and starts with a maximized window. This problem occurs also when I maximize with the button (if I add a maximized button to windows in gnome-shell with gnome-tweak-tool).

Comment 1

[Hashem Masoud]

(In reply to ppr from comment #0)
See solution here: http://kb.mozillazine.org/Localstore.rdf

Comment 2

[ppr]

Thanks
To force creation of a new file localstore.rdf with:

mv ~/.icedove/XXXXX(profile)/localstore.rdf ~/.icedove/XXXXX(profile)/localstore-old.rdf 

(put .thunderbird instead of .icedove if you are not using debian)

seems to work. At the first startup of thunderbird/icedove I maximized the window and closed with CTRL+Q and the window starts maximized after that.

Comment 3

[ppr]

In fact, the solution of comment #2 only works if I close thunderbird with Ctrl+Q. If I close it with Alt+F4 with the X button, thunderbird will start not-maximized.

Comment 4

[Hashem Masoud]

(In reply to ppr from comment #3)
> In fact, the solution of comment #2 only works if I close thunderbird with
> Ctrl+Q. If I close it with Alt+F4 with the X button, thunderbird will start
> not-maximized.

So can we consider your issue solved?

Comment 5

[ppr]

delete ~/.icedove/XXXXX(profile)/localstore.rdf is a workaround and I don't know what was the problem in this file at the first time.

Comment 6

[Ludovic Hirlimann [:Usul]]

want to attach the file to the bug ?

Comment 7

[ppr]

Attachment: file localstore.rdf

Comment 8

[ppr]

File attached, could someone try to recreate the bug with this file?

Comment 9

[Hashem Masoud]

(In reply to ppr from comment #8)
> File attached, could someone try to recreate the bug with this file?

I tried it and with a monitor resolution of 1366*768 it starts occupying around 75% of the screen.
User Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
Application Build ID: 20120216022139

Comment 10

[najoll]

I have this problem, in 2018, with Thunderbird 60.2.1 on Linux Mint. Recreating localstore.rdf did not help.

Comment 11

[najoll]

I have found a workaround for the problem.

The workaround may suggest where the problem lies.

The workaround is: disable drawing on tabs in titlebar; maximise the main window; close Thunderbird; re-enable drawing of tabs in titlebar. Result: Thunderbird will now open maximised.

Comment 12

[Ryan Lee Sipes]

I had this problem, disabling drawing tabs in titlebar did work. I know this isn't supported ootb for Thunderbird, but we should consider addressing this.

Comment 13

[Ryan Lee Sipes]

I'm not able to reproduce this problem in Nightly. I believe this has been addressed. Going to get some others to test.

Comment 14

[Ryan Lee Sipes]

Addressed in bug: 1593578. Looks like this is fixed.

Comment 15

[signupemail]

@Ryan Sipes: have others in fact now tested the ostensible fix? I feel that this bug report - and indeed mine (#1593578), which at present remains open - should be closed only if there has been a fair amount of testing. (I hesitate myself to test. Here is why. When I have installed nightly versions of Thunderbird it has caused problems with my main Thunderbird installation. Yet perhaps that happened only on Windows. If so I could try a nightly version of Thunderbird at least if I could get it as an appImage or similar.)

Comment 16

[Magnus Melin [:mkmelin]]

Bug 1593578 is still unconfirmed.

Anyway, we use WORKSFORME when there was no know patch to resolve the issue.

Comment 17

[signupemail]

Anyway, we use WORKSFORME when there was no know[n] patch to resolve the issue.

That means: we declare that something works for us when we do not how to fix the problem. That seems a strange usage. Compare: I have a problem getting out of my car, and I can't think of a way to solve the problem. So (!), being stuck in my car 'works for me'! But perhaps I misunderstand. After all, the comment contains a typo.

Also, if 'WORKFORME' does imply that there is some kind of problem, then how is that compatible with the following?

Bug 1593578 is still unconfirmed.

I suppose that report 1593578 is a different report to this one.

Comment 18

[Magnus Melin [:mkmelin]]

Let's reopen if you prefer. But without more steps to reproduce, it's unlikely to get any action.

Comment 19

[william.garber]

please help. I seem to be having same bug with thunderbird 102.10.0 on fedora 38.