Steps to reproduce
It’s pretty random right now:
- If you wanna go one line up or down and the line above/below is at least as long as the current line, it works as expected, moves the cursor correctly.
- If you wanna go one line up and the line above is shorter than the current line (i.e. there’s no character there), the cursor goes to the beginning of the current line and gets stuck. The expected behavior is to revert to the last character of the previous line.
2.1. Now if you press the up arrow (even repeatedly), nothing happens.
2.2. If you press the down arrow, it will keep jumping 2 lines down, at the first character.
2.3. If you press left or right arrow, it goes back to normal.
- If you wanna go one line down and the line below is shorter than the current line…
3.1. If there’s at least 2 additions lines, it goes 2 lines down, to the 1st character. Every repeated down presses will make 2 line jumps.
3.2. If there’s only 1 line left, it will correctly reposition the cursor to its last character.
There may be other incorrect behaviors, these are the ones I catched so far.
Comments and activity
Microsoft Edge 34.14295.1000.0
Microsoft EdgeHTML 14.14295
- Microsoft Edge Team
Changed Assigned To to “Sermet I.”
Changed Assigned To to “Amit J.”
Thank you for the feedback on Edge. This is a known issue that we are tracking internally. We are marking this issue as a duplicate of the internal bug for tracking purposes. We look forward to additional feedback you man have on how we can improve Microsoft Edge.
All the best,
The Microsoft Edge Team
We have an in-browser code editor based on , and this bug makes it pretty much unusable in Edge. The moment you move from a longer line to a shorter one, your caret either gets stuck or goes off into an unexpected place.
The “LDT” editor works in the same way, and has an online demo here: https://kueblc.github.io/LDT/examples/generic.html - imagine trying to edit code using that in Edge. It would drive you mad.
Please fix this - we don’t have the resources to put a lot of effort into engineering a workaround for this bug, but we don’t want to tell our users that our product doesn’t work in Edge and they should use a different browser.
Could you comment on when the fix for this bug will be in a released version of Edge? (I have tested Edge on an up-to-date Windows 10 installation on 7/27/2016, and the bug is still there.)
Things like this are extremely important and should be fixed ASAP.
I’m a software developer and I recently started using Edge. A colleague of mine came over today and was typing something into a text box and noticed the issue. He thought there was something wrong with my computer. I told him it was an Edge bug. He turned around and said "That’s why I don’t use Edge/IE".
If you are going to have ridiculous bugs like this (which has been reported in April and still not fixed!) then how are you going to convince people to use your browser? I mean Microsoft are supposed to be the best in software development, and the whole point of Edge was to win back trust… don’t you have UI Tests in place for this kind of basic stuff?
Sorry for my last post. I’ve just noticed my version of Edge is out of date (most likely due to corporate windows updates rollout being incredibly delayed)
Would it be possible for you to clarify what you mean by this bug being marked "Fixed"? As far as I can tell, the bug still is present in MS Edge on Windows 10 with the most recent update installed. Has it been fixed in a preview release available to the public?