TB68 message reader window has variable size each time it is opened
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(thunderbird_esr6870+ fixed, thunderbird71 fixed)
People
(Reporter: jm_sz, Assigned: darktrojan)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
66.17 KB,
image/jpeg
|
Details | |
1.35 KB,
patch
|
jorgk-bmo
:
review+
jorgk-bmo
:
feedback+
jorgk-bmo
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
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
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Time for some action here, duplicates are rolling in :-(
Comment 6•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
It seems there are several regression between TB60 and TB68.
STR:
- Open a message in window and remember its size. And close the message window
- 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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
(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.
Reporter | ||
Comment 16•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
Sorry, I was wrong. Upon further testing, Manually Sort Folders does NOT cause the problem. Folder Account does cause the problem.
Bill
Comment 19•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
(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.
Assignee | ||
Comment 29•5 years ago
|
||
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 | ||
Comment 30•5 years ago
|
||
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.
Comment 31•5 years ago
|
||
Comment 32•5 years ago
|
||
Comment 33•5 years ago
|
||
Updated•5 years ago
|
Comment 35•5 years ago
|
||
Updated•5 years ago
|
Comment 36•5 years ago
|
||
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
Comment 37•5 years ago
|
||
Comment 38•5 years ago
|
||
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•5 years ago
|
||
I see, I missed comment 37 about it being in 68.2.0.
Thanks,
Bill
Comment 40•5 years ago
|
||
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•5 years ago
|
||
Yes, for TB, ESR is the release channel.
Comment 42•5 years ago
|
||
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•5 years ago
|
||
Thanks everybody. I just got updated to 68.2.0 and the problem seems to be fixed.
Thanks,
Bill
Comment 44•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
I see the same problem. I'm on Windows 10 1903 and TB 62.2.1.
Bill
Comment 47•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
I don't know - others can decide re comment 49
Comment 51•5 years ago
|
||
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•5 years ago
|
||
Opened 1608401 for comment 45.
Comment hidden (obsolete) |
Comment 54•5 years ago
|
||
I meant I believe a bug was already opened, see bug 1605676.
Comment 55•5 years ago
|
||
(In reply to wrhenshaw99 from comment #54)
Thanks for telling me.
Marked mine as dup.
Description
•