Unpredictable jumps after search
Hello
Since some releases of PHPStorm I experience a weird jump behaviour after deleting a search text.
How you can reproduce it:
- Enter something you are searching for in PHPStorm, f.e.: "function" -> first occurence with "function" is found
- Delete the text "function" in the searchbox by pressing the "x" button right in that box
-> PHPStorm now jumps to some unpredictable position in the document instead of staying where it currently is. This is so annoying I wanted to report it. I don't know why this behaviour was implemented and how I can disable it.
Regards
Please sign in to leave a comment.
Hi there,
This one? https://youtrack.jetbrains.com/issue/IDEA-190270
or perhaps this: https://youtrack.jetbrains.com/issue/IDEA-190594 ?
Pretty similar to both but worse:
Concrete example:
1. Cursor stays at line 100 of a document with like 500 lines of a Javascript file
2. I enter "aaa" on line 100, cursor still there
3. I enter "div" in the search field (by clicking on it or by CTRL+F) and click the arrow-down a few times to iterate some lines with the word "div"
4. I enter "bbb" on a line where "div" is found
5. I delete "div" in the search field by clicking the "X"
The cursor jumps now to line 46. There is something I have entered/changed for like 1 month ago (while I have done many other changes in between at other positions). I have no idea why PHPStorm jumps to that line and f.e. not to line 100 (see 2.) or the last entered line (see 4.)
Expected behaviour:
After clearing the search field the cursors stays at the last found "div".
Version of PHP Storm:
PhpStorm 2018.1.5
Build #PS-181.5281.19, built on June 7, 2018
Licensed to Farai Aschwanden
Subscription is active until December 7, 2018
JRE: 1.8.0_152-release-1136-b39 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.5
This problem exists for like half a year and happened from one version to the next (I can't remember when that was but before it worked as described in expected behaviour).
Regards
It looks like https://youtrack.jetbrains.com/issue/IDEA-190270 for me.
@Tayger Does Navigate | Back work fine in that case (like return you back to line 100)?
Navigate/Back: It depends:
If the search field is still filled ('div') then Navigate/back brings me back to the previous change, line 100 in this case.
If I empty the search box (step 5 based on explanation)) it jumps to any unpredictable line (as already described). If I then go to Navigate back it brings me back to line 100 to the line where 'div' was found and where I have done some changes (step 4 based on previous explanation).
Regards
Updated to the latest PHPStorm (2018.1.6), problem still exits :(
Latest is 2018.2.1 - please try that build.
> PHPStorm now jumps to some unpredictable position in the document
It should jump back to where the caret was when the search invoked.
This is still broken in PhpStorm 2018.2.5 which is build #PS-182.4892.16 which was released October 11, 2018 and it's incredibly annoying.
Please fix this ASAP!
I have to agree to Arnold, Devin. It's still not working. Is this such a big issue to fix? Furthermore and weird: If you enter/type something in the search field and then press CTRL+Z it removes the entered letter. What sense does that make?
Right now, pressing Escape and clicking the X button don't scroll you back to where you started, as requested here: https://youtrack.jetbrains.com/issue/IDEA-190270
But manual wiping characters will do that, as it's been made by request too: https://youtrack.jetbrains.com/issue/IDEA-117967
Not sure I got you here. Why does it not make sense? It's always annoying when you can't undo your typing in an input field, isn't it?
I'm working with the Mac version, maybe that differs:
Based on https://youtrack.jetbrains.com/issue/IDEA-190270 the behaviour I have/see is different:
What is the expected result?
The cursor stays in the matched position, Line 100
Why? -> Because I put the cursor at line 100 manually and this should not be affected by completely clearing the search field (neither by marking it completely and then pressing delete key OR by just clicking the delete icon (x) next to the search field)
When would/should the editor jump back to line 5? -> When I don't leave the search field and clear it by completely clearing it (manually or by clicking the delete icon (x)
What happens instead?
The cursor jumps back to some kinda random line 827
--------------------------------------------------------
Concerning the pretty new case of CTRL+Z, to make it clear:
What is the expected result?
The editor jumps to line 100 and starts removing the last entered code (as it would behave when the editor window was focussed while pressing CTRL+Z)
-> The UNDO/REDO functionality should not affect any entered search text in the search field. It only should be related to entered code in the code window. This is just annoying when doing several UNDOs and some searches are in between that needs to be UNDOed as well.
What happens instead?
The editor removes the "n" from the entered word function in the search field
Your answer: "Why does it not make sense? It's always annoying when you can't undo your typing in an input field, isn't it?"
-> I never ever press CTRL+Z while typing in an input field and want to remove the last entered char. I just press the the Backspace key . Or for longer text I just press CTRL+A and Backspace to delete the whole text in the input field.
Concerning: "But manual wiping characters will do that, as it's been made by request too: https://youtrack.jetbrains.com/issue/IDEA-117967"
-> The described behaviour (that should be fixed now) is also not the behaviour I experience in the current installed release:
PhpStorm 2018.2.5
Build #PS-182.4892.16, built on October 11, 2018
JRE: 1.8.0_152-release-1248-b8 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6
How it behaves on my side (differences to IDEA-117967 vs my experience in bold):
Expected behaviour:
-> Should return to position it had before starting the search (exact same behaviour as when pressing the delete icon (x) beside the search field).
I hope I could make that clear (again).
Regards
OK, I see where I messed up now - it's only fixed in 2018.3: http://prntscr.com/lbyrbf
It's specified on the bug page, but I didn't mention that fact in my reply, and feel bad for making you write this detailed report. Please check how it goes in EAP for you: https://www.jetbrains.com/phpstorm/eap/
What about you pasting text into the search field? You might wanna get the previous query back. You can use History, but Undo feels a more natural way of doing that.
Really, Google supports Undo in the search field - why would we not?
Although I agree that undoing input by character is really inconvenient, the experience should be similar to what we have in Editor.
Could you please submit the request? https://youtrack.jetbrains.com/newIssue?project=WI
Concerning your "I messed it up..." that is corrected now:
My bad I didn't realise I'm working with a 2018.2 version. 2018.3 feels like the third quarter of year while we are in the fourth one. But yeah, to be honest I'd rather would like to spend my time on the project than explaining things here.
You said: "What about you pasting text into the search field? You might wanna get the previous query back. You can use History, but Undo feels a more natural way of doing that."
-> You mean I open a separate text editor where I store my search texts and paste them back into PHPStorms search field? :o) Funny workaround... I don't know how other programmers are working. I never had an issue like "Uuuh, what did I search half an hour ago? I need that so bad now!" Sure, it would be a nice feature to enter text in the search field and would see an autocomplete pulldown of previous search texts. But honestly: When I search for text I KNOW what I'm searching for (even when I searched the same 5 minutes ago).
You said: "Really, Google supports Undo in the search field - why would we not?"
-> Google is big, I assume you mean Google Search (www.google.com). First of all not everything that a "big" company is producing is great as well. I've tested it out and yeah, CTRL+Z does remove the whole entered text in the search field! Thinking about it: Thats nice! It takes less than mark it all and delete it. Thats nice and does make sense (of which I didn't know till you told me and I'm sure many others don't use it that way, just because it's not the behaviour we worked for years).
BUT: The Google search page is not a code editor! There is a single enter field on google.com and that's it, no additional window and the KEY (focus) there is to find stuff and nothing else. The purpose of a code editor is way different and the KEY of it is to code and find/change/add stuff. Everything should turn around the code and by saying this I mean that UNDO/REDO is focused only on CODE and not entered search text (or anyhting else). I don't know any other code editor with this behaviour. It's for me the same as you would store the position of the editor on the screen into the UNDO/REDO history and when it was moved and I do the UNDO the editor would be repositioned as it was before. Completely nonsense to me (imho). There is no other meaning to UNDO/REDO than that it is related to the code only. As I said: Nice feature of having a pulldown menu attached to the search field (if Google is the big goal to follow: Google has that too ;) ) for autocompletion but seriously I personally wouldn't use it that much.
You said: "Although I agree that undoing input by character is really inconvenient, the experience should be similar to what we have in Editor.Could you please submit the request? https://youtrack.jetbrains.com/newIssue?project=WI "
-> Sure it would be nice but since I'm not working that way I don't feel affected. Furthermore the ESC key does the same, so a (better) alternative is given.
Regards
I'm not experiencing this issue though I'm on version 2018.3.2.