Closed Bug 1580420 Opened 1 year ago Closed 1 year ago

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

Categories

(Thunderbird :: Message Reader UI, defect)

defect
Not set
normal

Tracking

(thunderbird_esr6870+ fixed, thunderbird71 fixed)

RESOLVED FIXED
Thunderbird 71.0
Tracking Status
thunderbird_esr68 70+ fixed
thunderbird71 --- fixed

People

(Reporter: jm_sz, Assigned: darktrojan)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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

See Also: → 1580414, 1570753
See Also: 1580414
Duplicate of this bug: 1580414
Duplicate of this bug: 1584193
Duplicate of this bug: 1584486

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

Flags: needinfo?(richard.marti)
Flags: needinfo?(mkmelin+mozilla)
Duplicate of this bug: 1584480

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.

Flags: needinfo?(richard.marti)
Duplicate of this bug: 1585826

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.

Flags: needinfo?(mkmelin+mozilla)

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

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

And also support postings

Status: UNCONFIRMED → NEW
Ever confirmed: true

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

Regressed by: 1497656

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.

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(acelists)

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).

Flags: needinfo?(acelists)

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.

Flags: needinfo?(mkmelin+mozilla)

(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.

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

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

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

Bill

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

(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

(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?

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(geoff)

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

Bill

(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.

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

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

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

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.

(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.

Flags: needinfo?(mkmelin+mozilla)

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.)

Assignee: nobody → geoff
Status: NEW → ASSIGNED
Flags: needinfo?(geoff)
Attachment #9102868 - Flags: review?(mkmelin+mozilla)

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 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
Attachment #9102868 - Flags: review?(mkmelin+mozilla) → review?(jorgk)
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.
Attachment #9102868 - Flags: review?(jorgk)
Attachment #9102868 - Flags: review+
Attachment #9102868 - Flags: feedback?(richard.marti)
Comment on attachment 9102868 [details] [diff] [review]
1580420-window-size-1.diff

Let's not forget this.
Attachment #9102868 - Flags: approval-comm-esr68?
Target Milestone: --- → Thunderbird 72.0
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.
Attachment #9102868 - Flags: feedback?(richard.marti)
Attachment #9102868 - Flags: feedback+
Attachment #9102868 - Flags: approval-comm-esr68?
Attachment #9102868 - Flags: approval-comm-esr68+
Target Milestone: Thunderbird 72.0 → Thunderbird 71.0

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

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Keywords: checkin-needed
Resolution: --- → FIXED

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

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

Thanks,
Bill

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

Yes, for TB, ESR is the release channel.

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

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

Thanks,
Bill

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.

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.

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

Bill

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

(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

See Also: → 1605663

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.)

Flags: needinfo?(vseerror)

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

Flags: needinfo?(vseerror) → needinfo?(richard.marti)

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.

Flags: needinfo?(richard.marti)

Opened 1608401 for comment 45.

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

(In reply to wrhenshaw99 from comment #54)

Thanks for telling me.
Marked mine as dup.

Duplicate of this bug: 1570753
You need to log in before you can comment on or make changes to this bug.