1580420 - TB68 message reader window has variable size each time it is opened

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect)

Description

[Marcin]

Attachment: Main window, reader window and taskbar - first and next opening of reader window

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

I opened the message to read (in separate window, as usual)

Actual results:

Reader's window gets taller and wider (a bit) each time you open it and is placed next to bottom of the screen..

It does not happen AFAIK, when message's window and/or main window is not placed next to bottom of the screen

Expected results:

Message window should keep last size and position

Comment 4

[Jorg K (CEST = GMT+2)]

Time for some action here, duplicates are rolling in :-(

Comment 6

[Richard Marti (:Paenglab)]

I see this mostly on all profiles. I think this is nothing I can do with my skills.

Probably it has to do something how the window size is calculated. Saved are the outer window dimensions including the window borders but when opening the window it uses the values as innerWindow sizes. FX doesn't have this problem, maybe they do something different.

Comment 8

[Magnus Melin [:mkmelin]]

Someone would have to debug, I haven't see this. The code for the main window is here: https://searchfox.org/comm-central/rev/20271ff62daee7aadb72cfff5a1bfcaa58d258be/mail/base/content/msgMail3PaneWindow.js#505-522 and for the standalone window here: https://searchfox.org/comm-central/rev/20271ff62daee7aadb72cfff5a1bfcaa58d258be/mail/base/content/messageWindow.js#371-386
I think it's saved just by having the persist attribute on the window.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Jorg K (GMT+2) from comment #4)

Time for some action here, duplicates are rolling in :-(

And also support postings

Comment 10

[Alice0775 White]

It seems there are several regression between TB60 and TB68.
STR:

1. Open a message in window and remember its size. And close the message window
2. Open the same message in window

Actual results:
The height is bigger than the previous.

1st recognizable regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=22016492fb10c5d1b4175047c095d935c19de151&tochange=e2b203306dad4554844efa16f2c43cba60cee85e
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2d7836b93f9ad88ef27388df27be1e6510bcdb8&tochange=067a1c08f91d13f9ad8b7c73b40b2a9065d24c0e

Regressed by: e2b203306dad4554844efa16f2c43cba60cee85e Magnus Melin — Bug 1497656 - set up Thunderbird custom elements on DOMWindowCreated, to make them work also in the stand-alone message window. r=aceman

Comment 11

[Jorg K (CEST = GMT+2)]

Thanks, Alice, good to make a start here.

What other of the "several" regressions did you notice. Not only the stand-alone window grows, also the main window and compose windows, although it's harder to reproduce for those.

NI for the people who caused the first regression.

Comment 12

[:aceman]

I can't really reproduce this on Linux. The message window is most often restored on top of the screen, even though the previous position was lower (touching the screen bottom as in the report).

Comment 13

[Alice0775 White]

And if enabled all header view.(Alt > View > Headers > All)

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=3213fa235aef00d065affbe563a05a4469f2e96d&tochange=4d7274e18df2de8216378e52a605e00135c14
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8063b0c54b888fe1f98774b71e1870cc2267f33f&tochange=7b40283bf1c7a2a3e6a8a5d00156a2f506ff465b

Comment 14

[Magnus Melin [:mkmelin]]

From the regression windows it looks like custom elements or xbl changes were involved.
I can't reproduce on linux. But could someone seeing this try to remove the elements on by one and see if we can figure out which is the cause. In the range from comment 13 there is toolbarbutton so maybe it's that. So comment out https://searchfox.org/mozilla-central/rev/171109434c6f2fe086af3b2322839b346a112a99/toolkit/content/customElements.js#785 . Things would be broken of course, but you can see if it changes the resizing behaviour.

Comment 15

[Richard Marti (:Paenglab)]

(In reply to Magnus Melin [:mkmelin] from comment #14)

From the regression windows it looks like custom elements or xbl changes were involved.
I can't reproduce on linux. But could someone seeing this try to remove the elements on by one and see if we can figure out which is the cause. In the range from comment 13 there is toolbarbutton so maybe it's that. So comment out https://searchfox.org/mozilla-central/rev/171109434c6f2fe086af3b2322839b346a112a99/toolkit/content/customElements.js#785 . Things would be broken of course, but you can see if it changes the resizing behaviour.

Removing this line doesn't help. But in a distress I disabled Lightning, the only extension in my trunk build profile, et voilà the window stopped to grow. Enable it again and the window grows again.

The same happens to the DevTools Inspector. With disabled Lightning no growing and with it enabled, growing.

Comment 16

[Marcin]

Removing this line doesn't help. But in a distress I disabled Lightning, the only extension in my trunk build profile, et voilà the window stopped to grow. Enable it again and the window grows again.

The same happens to the DevTools Inspector. With disabled Lightning no growing and with it enabled, growing.

Allow HTML Temp also causes this problem. Three others extensions (ConfigDate, Manually Sort Folders, No Message Pane Sorting by Mouse) don't

Comment 17

[wrhenshaw99]

Don't know if this will help, but for me Manually Sort Folders DOES cause the problem as does gContactSync. Disable DragAndDrop and Folder Account do not cause the problem.

Bill

Comment 18

[wrhenshaw99]

Sorry, I was wrong. Upon further testing, Manually Sort Folders does NOT cause the problem. Folder Account does cause the problem.

Bill

Comment 19

[wrhenshaw99]

Sorry again. After further use it appears to have nothing to do with the extensions I have enabled. I disabled all my extensions and it still has the problem. For me at least, it is not related to extensions.

Bill

Comment 20

[BS]

(In reply to Richard Marti (:Paenglab) from comment #15)

With disabled Lightning no growing and with it enabled, growing.

Confirmed here.
Thunderbird 68.1.2

Comment 21

[Richard Marti (:Paenglab)]

(In reply to BS from comment #20)

(In reply to Richard Marti (:Paenglab) from comment #15)

With disabled Lightning no growing and with it enabled, growing.

Confirmed here.
Thunderbird 68.1.2

Could this come from overlay loader?

Comment 22

[wrhenshaw99]

Just so you know, I do not use Lightning and never have had it installed, but I am having the same problem.

Bill

Comment 23

[Richard Marti (:Paenglab)]

(In reply to wrhenshaw99 from comment #22)

Just so you know, I do not use Lightning and never have had it installed, but I am having the same problem.

But another extension or absolutely none? Please check in in Tools/Add-ons. Lightning is installed by default.

Comment 24

[wrhenshaw99]

I don't know. It does not show in my Add-ons. If it was installed by default I must have uninstalled it years ago.

At the moment I have 4 extensions installed but they are all disabled. I have tried enabling them one at a time to see if I could figure out which might be causing the problem. In my earlier posts I thought I had found a pattern, but I can't pin anything down yet. It seems to happen sometimes for Folder Account and Manually Sort Folders. gContactSync seems to always cause the problem. Disable DragAndDrop never causes the problem. Yesterday I had the problem even with all 4 disabled.

Bill

Comment 25

[wrhenshaw99]

Just now I tested and the problem is occurring with only Folder Account or gContactSync enabled. It is not happening with only Manually Sort Folders or Disable DragAndDrop enabled. I will try combinations to see if that makes any difference.

Bill

Comment 26

[Geoff Wood]

I removed the Lightning extension, and the 'reading-window-growth(to bottom of screen)' thing disappeared.

I still get the 'whole-expanded-thread-collapses-when-first-message-opened' thing though …..

geoff

Comment 27

[Duncan Moore]

I have a similar problem, but it's the main window that gets bigger vertically, not the reader window.
It only happens when "Phoenity Buttons" is installed and enabled, and happens every time I start Thunderbird, or switch profiles.
TB 68 64-bit Windows 10.

Comment 28

[Magnus Melin [:mkmelin]]

(In reply to Richard Marti (:Paenglab) from comment #21)

Could this come from overlay loader?

I don't see Overlays.jsm doing anything that would cause it directly. But from the comments it does appear to be add-on related. Or it's just some weird kind of timing issue that is aggravated by loading loading add-ons.

Comment 29

[Geoff Lankow (:darktrojan)]

Attachment: 1580420-window-size-1.diff

I think this fixes the problem. The overlay loader reapplies the window dimension attributes to any window with an overlay, and does so with out accounting for inner/outer dimension differences. (I guess this happens before the attribute values are used to set the size of the window, because doing the same thing later has no effect.)

Comment 30

[Geoff Lankow (:darktrojan)]

Here's a build with the above patch applied. Windows 64-bit. Anyone who wants to try it should do so with a new profile.

https://queue.taskcluster.net/v1/task/FPzrUWfNT7eJIBLIxxeTWw/runs/0/artifacts/public/build/install/sea/target.installer.exe

Comment 31

[Magnus Melin [:mkmelin]]

Comment on attachment 9102868 [details] [diff] [review]
1580420-window-size-1.diff

Review of attachment 9102868 [details] [diff] [review]:
-----------------------------------------------------------------

Passing this over to Jörg since he can reproduce and test it. Looks reasonable to me

Comment 32

[Jorg K (CEST = GMT+2)]

Comment on attachment 9102868 [details] [diff] [review]
1580420-window-size-1.diff

Looks reasonable. I didn't say I could reproduce the issue, I said that my compose window occasionally gets bigger but I haven't found a way to reproduce this. I use ThunderHTMLedit, so a legacy XUL add-on which the O/L loader will load for me.

I'm sure Richard can try it out.

Comment 33

[Jorg K (CEST = GMT+2)]

Comment on attachment 9102868 [details] [diff] [review]
1580420-window-size-1.diff

Let's not forget this.

Comment 34

[Geoff Lankow (:darktrojan)]

And this.

Comment 35

[Jorg K (CEST = GMT+2)]

Comment on attachment 9102868 [details] [diff] [review]
1580420-window-size-1.diff

Wow, main window now maintains its size, that's a must have for TB 68. I also checked a stand-alone message window. Hopefully the compose window issue will be fixed, too.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/caa4039d835a
Don't apply persisted dimensions to windows in the overlay loader. r=jorgk DONTBUILD

Comment 37

[Jorg K (CEST = GMT+2)]

TB 68.2.0 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/80f0fdbb307af37a52ac5f550d284c462c0a3a21

Comment 38

[wrhenshaw99]

Sounds like you may have found a solution for this. Will you be releasing a fix for 68? Will we have to wait for a later release to see a fix?

Thanks,
Bill

Comment 39

[wrhenshaw99]

I see, I missed comment 37 about it being in 68.2.0.

Thanks,
Bill

Comment 40

[wrhenshaw99]

Another question. I found this:

"Mozilla Thunderbird
Extended Support Release
A community-led project that allows organizations to benefit from the speed, flexibility and security of Thunderbird while getting the support they need.
The Thunderbird Extended Support Releases (ESR) are mainstream releases, operating similarly to Mozilla Firefox ESR. They are stable for approximately one year before receiving feature updates."

This doesn't sound like the Release Channel version that I am on. Does anyone know when the fix would get rolled out to the Release Channel? Does that happen at the same time it goes to ESR?

Thanks,
Bill

Comment 41

[Jorg K (CEST = GMT+2)]

Yes, for TB, ESR is the release channel.

Comment 42

[wrhenshaw99]

Thanks Jorg. Sounds like someone should change the wording on the website https://www.thunderbird.net/en-US/organizations/ to better reflect what the ESR is. From reading the web site I thought it was for businesses only.

Thanks,
Bill

Comment 43

[wrhenshaw99]

Thanks everybody. I just got updated to 68.2.0 and the problem seems to be fixed.

Thanks,
Bill

Comment 44

[Jorg K (CEST = GMT+2)]

Yes, the main window certainly keeps its size now. I had an issue with the compose windows (bug 1570753) and it seems that it also doesn't grow any more. Hard to tell since sometimes one makes it bigger unconsciously.

Comment 45

[BS]

I notice that the annoying same issue on the "Customize Toolbar" window is also fixed.

But, the 2 windows below now have a "reversed" issue:
Account Settings
Subscribe (for IMAP folders)

Open, close, reopen either of them.
The window goes smaller. Each time:
Width - 8px
Height - 28px
(The pace is apparently according to the window border size including the title on my OS.)

Open it,
Switch focus to another app,
Close it,
reopen it.
The size does not change.

Not sure if this new issue begins just after this fix.
But in my memory v60 didn't have the issue on the 2 windows.

Comment 46

[wrhenshaw99]

I see the same problem. I'm on Windows 10 1903 and TB 62.2.1.

Bill

Comment 47

[wrhenshaw99]

I notice that this issue is now listed as closed. The problem reported in comment 45 is still occurring in TB 6.2.2 64-bit. Has it been moved to another bug?

Thanks,
Bill

Comment 48

[Wayne Mery (:wsmwk)]

(In reply to wrhenshaw99 from comment #46)

I see the same problem. I'm on Windows 10 1903 and TB 62.2.1.

Bill

see bug 1605663

Comment 49

[BS]

I think @wrhenshaw99 refers to Comment 45.

Should I file Comment 45 as a new bug (if this thread will not reopen for it)?
(I think they are somehow relevant, because the fix also fixed the "Customize Toolbar" window size as I mentioned in Comment 45, and the behaviors are alike and clear.)

Comment 50

[Wayne Mery (:wsmwk)]

I don't know - others can decide re comment 49

Comment 51

[Richard Marti (:Paenglab)]

On Daily I don't see the issue of comment 45 but on TB 68. I don't know why this can happen, maybe Geoff can help.

Yes, open a new bug.

Comment 52

[BS]

Opened 1608401 for comment 45.

Comment 53

[wrhenshaw99]

A believe a bug was already opened for this. See Bug 16056760.

Comment 54

[wrhenshaw99]

I meant I believe a bug was already opened, see bug 1605676.

Comment 55

[BS]

(In reply to wrhenshaw99 from comment #54)

Thanks for telling me.
Marked mine as dup.