I really like the WYSIWYG compose window on a mobile browser: once activated, the whole mobile phone screen is used: lots of space to compose and re-read, no distraction.
On a computer it is not so: the simple text window takes two thirds of the screen height (in 100% zoom, i use rather 90%; while half-width, full-height would be preferable), the WYSIWYG window is actually even thinner (6 paragraph lines ~ 10 lines in one paragraph). The other drafts do not need to be displayed while composing a mail, these could be hidden for the moment.
It is not so but could be: the compose window could occupy the full available size (or at least height) to allow to display as much of the mail being composed, and possibly even the mail being answered.
This answer could start something like “I really hate the WYSIWYG compose window on a mobile browser.” Since Tuesday’s release the compose window occupies only a part of the viewport. This is – at least on a mobile – uncomfortable and impracticable. Below is a screenshot from rb7:
The update also brought a feature that recognized that a link is in the clipboard. On a smartphone (FF, Android, Sony) upon pasting a “link” button appears. The link is then pasted in a pop-up, OK button, back to the compose screen. This is longer, from my user’s perspective does not bring any advantage, and is accompanied by erratic motions as the small screen refocuses on the location where the link button appears.
@Dave, btw, the new compose window also does not allow the built-in spellchecker function in Firefox (under Win10). [I have to write in three languages in equal share and rely on spellchecker quite a bit - errors and typos] Not sure how was it before Feb 12th?
Not really other than checking the dictionary is properly installed.
I didn’t do anything special. I just started Firefox in Windows 10, checked I had a dictionary installed and opened a compose window in Runbox 7. Deliberately mistyped a word and it was underlined as a spelling error.
@Dave What you describe is what does not work for me, but I should have been more specific: it was in reply to a thread on the topic of tinyMCE hijacking the right-click context menu. It concerns the rich text formatting (words not underlined, right-click context menu not accessible which drives me mad when using many MS products):
In non-HTML text the spellchecker (and the right-click context menu) work as expected:
@Dave, pls let me emphasize that this thread collected three more issues (tinyMCE hijacking the paste mechanism on an android phone, decrease in writing area size on a phone, small area size on a computer). As these seemed to be result of a choice and not a bug, i did not dare to submit an issue in github.
Sorry about the delay in getting back to you. Let me check them out tomorrow again and I’ll get back to you. There is no harm in opening them as GitHub issues as we can then identify duplicate issues if they already exist. I haven’t created any issues for this yet.
I’ve gone through some of the comments you made and have the following comments.
You can drag the window so that it fills more of the screen.
This might depend on whether the app is running full screen or not in the first place. It looks full screen to me when I am using the app in full screen mode (i.e. as a Progressive Web App).
Is this related to the tinyMCE hijacking the right-click context menu/paste option that you mentioned?
I’ll create an issue for this as I think this is the same issue that affects the paste function and the spell checking that you’ve mentioned.
Not that I am aware of.
I need to do a bit more digging but I think that tinyMCE issue needs looking at.
Feel free to open GitHub issues for anything I haven’t addressed to your satisfaction as that is the best place for us to collect them. Thank you and sorry for the delay in getting back to you on these.
@Dave, i did not dare to open an issue for the above as i did not want to be too pushy, rather wanted to discuss first as it could have been a matter of choice.
As you wrote, all of the above somehow relates to TinyMCE.
Concerning the full-screen, on a mobile phone the textarea expanded to the whole screen once started to write into it. This was gone with one of the updates, as described above.
The size of the textarea on large screen of a computer, the space available is much larger. In such a situation the textarea could also expand to take the maximum of the space,not for comfort on a tiny screen but to show also the text i’m answering, instead of just few lines of it. When composing the other drafts should be hidden to let us concentrate on the only task of writing the current one and to allow to maximize the textarea to display maximum of the text of the text being replied or forwarded.
Slightly related to the compose window size on a desktop/laptop: I don’t like the small screen size either, I use drag to increase the size already but the option I really would like is a something similar to Gmail.
In Gmail I can choose to have the compose window to “pop out” as a separate window within a window (sorry, not sure about the correct technological terminology). This would keep the Runbox 7 environment as is, and put the compose window in a separate box. This is hugely beneficial because when I respond to long emails I like to have both the original email open as well as the compose window. Currently I have to keep scrolling up and down which is really counter-productive. Sorry if I have explained this poorly, but hope this can be looked at.
Since Tuesday’s release the compose window occupies only a part of the viewport. This is – at least on a mobile – uncomfortable and impracticable. Below is a screenshot from rb7:
