GNOME Bugzilla – Bug 778025
Conversation message body height is unreliable
Last modified: 2018-10-14 01:04:36 UTC
There's still some weirdness with the preferred height for web views after both the GTK/WK2 ports landed. Here's all the cases I know of right now: - Conversation message body is sometimes way too big - Conversation message body doesn't contract when content shrinks (e.g. when an image is loaded and it turns out to be smaller than the HTML thought) - May still being getting crashes for very long messages See also Bug 778024.
Just pushed commit d6ed3e to master that will help if not fix completely the problem.
I haven't seen any further issues with the content height since pushing that, so closing this as fixed.
Ugh, so of course as soon as I close this I get a "short message with way too big a height" showing up...
*** Bug 792295 has been marked as a duplicate of this bug. ***
Created attachment 367011 [details] last line of message is hidden and you must scroll I find sometimes the opposite issue (it's a minor issue): a single-message conversation which has a short body not filling the whole window height is not displayed entireley, i.e. you have to scroll a bit down in the message to see it completely, even if there's a lot of space and therefore no reason to hide the content. The amount of hidden content is always very tiny, about a line of text.
Well, the issue described in comment #5 is reproduced only on my desktop, where I'm using a slightly earlier version _compiled with Cmake_. Can't check the exact version now. I cannot see the issue on my laptop, where I have installed a binary compiled via Meson. git HEAD is at 8th of January.
The issue I had in mind here is a bit racy, in that sometimes it will appear but mostly will not, and that if it does happen, then selecting a different conversation and going back to the one with the problem will usually resolve it. If there's an instance where you can 99% reliably reproduce it, please do mention it.
Yes, I can reproduce it 100% of times, but only on my dekstop computer, where I have installed version master~g3606bade (compiled with Cmake). I may try compiling the latest master using Meson and see if the behaviour changes. My laptop and desktop run on the same OS (Fedora 27).
I can still reproduce it on my desktop after building latest master using Meson. So more likely to be a database issue? (my desktop PC has an older database than my laptop, where I started from scratch about a month ago)
If the databases are significantly different in sizes, that could make a difference, but probably not their age. Since they are doing different things, there must be some tangible different between the run time environments or physical configuration of the two machines - Do they have different version of GTKK+/WebKitGTK+/etc? Are their workloads (e.g. size of the database) different? Does one have only one or two CPU cores or a smaller amount of memory, while the other las a larger number? That sort of thing.
Gtk+/WebKitGTK+ should be the same, as both machines are updated. Database size is probably much different. Let me write down some details of my laptop current configuration: 1 account, 216MB database $ nproc --all 4 $ pkg-config --modversion gtk+-3.0 3.22.26 $ dnf info webkitgtk4 | grep Version Version : 2.18.5
On my desktop: 2 accounts account 1 (same as above): 546M database account 2: 583M database $ nproc --all 4 $ pkg-config --modversion gtk+-3.0 3.22.26 $ dnf info webkitgtk4 | grep Version Version : 2.18.5 So the only difference seems database size. The age is also different, but you said it probably doesn't matter. Let me know if you need other information.
I am also affected by the bug described in comment #5 both on my laptop and desktop (3 accounts on each). I can provide logs if needed.
This should be fixed on master by https://gitlab.gnome.org/GNOME/geary/merge_requests/57 - at least I'm having trouble reproducing it on that branch. Will cherry-pick it to 0.12 if possible.