After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749802 - Still-loading Rec'd Message Pushes Compose Window Out of Sight
Still-loading Rec'd Message Pushes Compose Window Out of Sight
Status: RESOLVED DUPLICATE of bug 795219
Product: geary
Classification: Other
Component: composer
0.10.x
Other Linux
: Normal normal
: ---
Assigned To: Geary Maintainers
Geary Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-24 18:46 UTC by Johny Why
Modified: 2018-04-13 03:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Johny Why 2015-05-24 18:46:27 UTC
Hi

when i click reply on a message that's still loading images, then my reply window gets pushed down, out of sight.

this is because you open reply window in threaded mode, UNDER the message being replied to.

plz open new compose windows in detach mode. that will prevent this problem.

detach mode is a more natural, comfortable mode for composing new mails anyway. i would prefer that mode even if this problem did not occur.

thx
Comment 1 Johny Why 2015-05-24 19:22:44 UTC
i understand you default to docked mode for new compose window, to indicate that the message is part of the thread, but it's not part of the thread really YET, until i hit send. it's only GOING TO BE part of the thread.

if there was some critical, common, global problem of people forgetting which thread to which they are replying, then i would understand default dock mode. i'm not aware that this is a big, common problem.

there are other indicators to tell user which thread they are replying to:

-- subject line
-- they are looking at thread when they hit reply.
-- they can see thread behind the compose window.
-- TO line.

thx
Comment 2 Johny Why 2015-05-24 19:24:10 UTC
if you won't make detach standard by default, plz make it an OPTION in prefs.

thx
Comment 3 Federico Bruni 2018-01-15 09:03:21 UTC
(In reply to Johny Why from comment #1)
> i understand you default to docked mode for new compose window, to indicate
> that the message is part of the thread, but it's not part of the thread
> really YET, until i hit send. it's only GOING TO BE part of the thread.
> 

Well, this is not true for replies. Currently Geary puts a message in a thread depending on the Message-Id header, so a reply message is already part of a thread.
It is true for new messages. See below.

> if there was some critical, common, global problem of people forgetting
> which thread to which they are replying, then i would understand default
> dock mode. i'm not aware that this is a big, common problem.
> 
> there are other indicators to tell user which thread they are replying to:
> 
> -- subject line
> -- they are looking at thread when they hit reply.
> -- they can see thread behind the compose window.
> -- TO line.
> 

See the discussion in bug 738499.
I think that the main reason for never using detached window by default is "keep it simple". When you have several windows floating around you can easily do mistakes. A compressed window let me focus on the reply I'm writing. I rarely need the detached mode; only when I want to read again some parts of the quoted message.


I would keep this bug open to understand what's the problem with loading the image. But I don't know how to reproduce this, as I've never experienced such a problem:

> when i click reply on a message that's still loading images, then my reply
> window gets pushed down, out of sight.

Remote images from the Internet or attachments?
Comment 4 Johny Why 2018-01-15 09:18:24 UTC
detach mode is a more natural, comfortable mode for composing new mails. 

I really dislike composing in small window. I always expand compose window, especially on small screen. 

I don't recall if images were remote. This is old report. I'm not using Geary at this time, not usable yet.
Comment 5 Michael Gratton 2018-04-13 03:49:47 UTC
This will be fixed by Bug 795219.

*** This bug has been marked as a duplicate of bug 795219 ***