It's not a bug, it's a feature!
It's not a bug, it's a feature!
I've noticed a small issue with my email client for quite some time now where composing a new email will have several blank lines by default.
It's not too much of an issue to simply delete them but hey, maybe no one had pointed this out before! So I filed a bug report only to get this response... basically it's not a bug, its a feature!
Proton is rebuilding their android app from the ground up. They're not going to fix something like this in the old app. You can join the beta here. https://proton.me/support/mail-android-beta
Thank you! The stupid thing is I'm literally enrolled in the beta program through the Google Play store... apparently that's the fake beta and you have to know this link for the real beta. I can confirm this issue does not exist on the "real" beta. You just saved me a lot of time.
The Google Play beta is the beta version for the existing app (aka edge version), not the rebuilt one (which isn't released yet, except as beta)
For context, this is the "feature":
literally unusable
but if they ever change it, it'll break a number of fortune 500 companies who rely on this behaviour 🤣
Not the end of the world if they trim messages before sending them?
It means you can click a line and type there, no need to press enter a few times first.
Not email, but if I'm taking notes in a text editor I will hold down enter at the start to ensure I can just click and type anywhere.
Now, if that pointless whitespace is being sent, I can imagine it annoying people in long email chains.
I'm not sure why you would need to start an email from halfway down the page? I'm not sure I'm understanding you but I feel like I'm on the verge of having my mind blown about how the other half write emails 🤣 Please explain further, I'm genuinely curious!
For me, I write things from top to bottom. If I want to do a later paragraph then I will simply write it in, then go back to the top and hit enter to create a new line
IMO, that's a clear acknowledgment that this is a specification bug.
And that it has a low priority.
IMO call a bug a bug. Even if they were to say "yes this is a known issue, we're aware of it but don't know when we will be able to work on it" would be 100x better. The client is open source and I wouldn't mind taking a look at it myself and potentially submitting a pull request.
However, saying "yes this is the expected behaviour" coupled with one closed pull request where someone implemented a "mark all as read" button (clearly a non-trivial amount of work) but closed the request months later with this comment doesn't make me too eager:
There's another where someone literally took the vector image that they use for their icon and created a PR to support Android 13 themed icons. After half a year someone rejected it due to only the design team being allowed to make design changes.
"Expected behavior" doesn't mean "intended behavior." It just means that it's a bug they know how to fix but don't have the bandwidth to fix yet. So it's not a feature, it's just a defect that isn't important enough to remove yet.
Most likely, next time they have cause to open the file that's causing the bug, they'll fix this too. Fixing bugs by attrition is one of many ways to keep dev costs low. Well, lower.
Seems to readily impact 50% of the entire function of an email app (to write emails).
Seems like a weird hill for Proton to not want to climb down, considering their position within the email client marketplace. I would absolutely make UX a high priority.
This is how our company would word it. I see no problem with their response. Limited resources means focusing on top priority issues first.
Why would anyone want that?
It means you can click a line and type there, no need to press enter a few times first.
Not email, but if I'm taking notes in a text editor I will hold down enter at the start to ensure I can just click and type anywhere.
Now, if that pointless whitespace is being sent, I can imagine it annoying people in long email chains.
Well, this screenshot is the mobile version. Tapping anywhere in a textbox should bring the focus and start typing. All having extra lines does is make it more likely that the starting insertion point is a line or two below the start.
Even on desktop, I'm not aware of any text box behavior where you need to click on the correct line to bring the focus to the box.
This seems like a quick temporary pseudo-solution that removed an obstacle towards implementing some behaviour. Being temporary, it’s likely to outlive the feature it unblocked.
I have a free account and can’t turn off the mobile signature, which has two blank lines before it. I wonder if turning that setting off just deletes that string, but not the lines.
I have both signature settings turned off and there's several blank lines.
Yeah, it’s like they removed the signature text, but not the blank lines.
It's not a bug just because the software doesn't conform to your personal preferences. You're asking for what would be considered an enhancement - not a bug fix.
But
why would several blank lines be the default behavior
I don't know the reason. I think not having the extra blank lines would be better, but it works just fine as is - even the post admits this much. That's why it's an enhancement. It's possible for software to be functional and consistent and still have room for improvement - that doesn't mean there is a bug.
It's not about preference. It's about what every single other email client does, including their own on different platforms, and this is even fixed in their upcoming beta of this same app.
My point is that someone made the decision for it to do that and that the software works just fine as is. It's not a bug, it's just a weird quirk. The fact that they made the enhancement you requested doesn't make the old behavior buggy. Your post title said "it's not a bug, it's a feature!", but the behavior you reported is not accurately classified as a bug.