Opened 3 years ago
Last modified 3 years ago
#16642 new bug
[regression] BTextControl: broken horizontal scroll when text don't fit text field
| Reported by: | X512 | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Kits/Interface Kit | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
This is hrev54752.
This is regression caused by hrev54549.
Steps to reproduce:
- Open some application with BTextControl.
- Type someting that don't fit to text control space.
- Hold left allow key until caret will be at first character.
- Text will be still scrolled horizontally so text beginning will be at center.
- When scrolling by pressing and holding mouse button, text can be scrolled to the right so it became not visible at all.
Bug is also present in Tracker file name edit field.
Attachments (3)
Change History (13)
by , 3 years ago
| Attachment: | BTextControl scroll.png added |
|---|
comment:1 by , 3 years ago
| Description: | modified (diff) |
|---|
by , 3 years ago
| Attachment: | Tracker name edit.png added |
|---|
comment:2 by , 3 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 3 years ago
comment:4 by , 3 years ago
I don't understand why we want empty space in any case.
When the text fits in the view, it should alway be aligned to the left/right/center as specified by the view.
When the text does not fit, try to keep the cursor close to the right side of the view (when typing), maybe with 1 or 2 characters right of it also visible to make it clear that you are not at the end of the text. Try to keep the cursor next to the left side of the view when scrolling left with the arrow keys, maybe, but not when you use backspace - you want to see what you're erasing. Try to not jump instantly between these two.
I think Vision tries to do this (scrolling the text 1 char at a time as you type), but then it also gets the half "extra space" added in now, and it doesn't work (your cursor is stuck at the middle of the view, and the text scrolls to the left as you type).
I think the previous behavior in Vision was fine, and could be integrated directly in BTextView?
comment:5 by , 3 years ago
Vision doesn't do anything special with it's text view from what I can see. We could make extraSpace 0, that would fix the issue here, and then come up with some other way to scroll over on overflow because I can't figure out a better way to make that work.
comment:6 by , 3 years ago
The current behavior is really broken. I am currently trying to edit some tags in ArmyKnife, and the text (sometimes) erratically jumps around, and sometimes parts aren't even visible. Can we revert all those changes, and only apply them once they are ready for consumption?
comment:7 by , 3 years ago
Proposed fix is https://review.haiku-os.org/c/haiku/+/3642
Extra space is gone, it didn't solve the problem properly and there were some other issues.
We could potentially revert but it's not reasonable to expect a bug free experience between betas. I realize that BTextView bugs can be super annoying, my apologies. It took me a while to figure out a proper fix to this problem so that scrolling would work the way it should. Rest assured that scrolling text views was subtly broken even before my recent changes.
by , 3 years ago
| Attachment: | Beezer BTextView bug.png added |
|---|
I found another broken program Beezer. Note that BTextControl content is scrolled vertically so it is almost not visible.
comment:8 by , 3 years ago
Beezer bug worked around in https://review.haiku-os.org/c/haiku/+/3642 PatchSet 5.
comment:9 by , 3 years ago
Is it possible to revert the behavior back in the latest nightlies until the behavior works better and gets merged back in? The current behavior seems like a major regression to the way it was previously working.
comment:10 by , 3 years ago
jscipione is working on fixing it and we plan to include his work, or revert the changes, in beta3.
You decided to use the nightlies which are the place where developers make and test changes. You have to live with the consequences of this choice.
We will not revert changes in nightlies because that is where we test them and make sure they work well before we ship a release.
This is not a bug, this behavior was added intentionally, let me try to explain.
The behavior described in this ticket is here: https://git.haiku-os.org/haiku/tree/src/kits/interface/TextView.cpp#n2172
When the text in the text view is wide enough that it does not fit in the text view box an extra 1/2 text view of space is added on. You are allowed to scroll the text horizontally to both positive (after the end) and negative (before the beginning) values. This was done so that when you type more characters then will fit in the box, you may scroll the text while still seeing some of the previous text.
Before this change when you added more text than would fit in the box it would hide all of the previous text from view and create a new "page" of text not allowing you to see any of the text in the previous page.
What you are showing in this ticket as a bug is that you are allowed to scroll past the beginning of the text when it doesn't fit. This might look odd, but this was done so that you have some extra space to scroll in allowing at least some of the text to remain on screen.
If some corrective change to this behavior is desired, the way to do it is to alter the extraSpace variable. If extraSpace is set to 0 then the text view will allow you to scroll to the beginning and end of the text only, but, that will also hide all previously entered text when you overflow.
Perhaps reducing from 1/2 width to 1/4 width would make the extra scrolling space appear more reasonable.
The mouse button scrolling part might still be a bug though.