Bugzilla – Full Text Bug Listing
| Summary: | Please keep my context (somehow) when navigation a function within a file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Steve Northover <steve_northover> | ||||
| Component: | JS Tools | Assignee: | Silenio Quarti <Silenio_Quarti> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | Carolyn_MacLeod, curtis.windatt.public, Michael_Rennie, Silenio_Quarti | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 10.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
(In reply to Steve Northover from comment #0) > Any thoughts? Not doing this means that I lose my context. This makes perfect sense, and I think we might even be able to use the same logic that is already used for going back to a particular position in another file (i.e. edit foo.js -> open bar.js, make edits -> hit back button -> takes you back to foo.js where you left off). Implementing this to "just use the back button" would be great. Please take a look at doing this or start the discussion about implementing another mechanism. Assigning to Eric. This has implications for split-screen editing. (i.e. each screen needs to know where to go back?) But also, note that people might want to 'open declaration' in a new screen so that they don't have to go back. (i.e. fred54() would still be visible in the original screen). Any progress on this? Is there a line number argument that we could use in the URL so that going back and forth using the back button can work? Please get basic navigation working before looking at the split editor. (In reply to Steve Northover from comment #4) > Any progress on this? Is there a line number argument that we could use in > the URL so that going back and forth using the back button can work? Please > get basic navigation working before looking at the split editor. If you go from one file to another, the back button will take you back to where you were in the original file. We still have to figure out what to do in the same-file case (open decl jumps you to another location without leaving the current file). It's the same file case I'm asking about. I'm sure I saw a URL parameter that could be used to go to a particular line in a file. If so, could this be used when navigating within the same file? SSQ, is there a line number parameter that could be used? The URL has a start,end parameter we can use. I believe we can change openDeclaration.js to call openEditor with start/end parameter instead of calling setSelection(start, end). (In reply to Silenio Quarti from comment #8) > The URL has a start,end parameter we can use. I believe we can change > openDeclaration.js to call openEditor with start/end parameter instead of > calling setSelection(start, end). Plus if we use openEditor, we would get the 'back' support from the inputChanged, no? (In reply to Michael Rennie from comment #9) > (In reply to Silenio Quarti from comment #8) > > The URL has a start,end parameter we can use. I believe we can change > > openDeclaration.js to call openEditor with start/end parameter instead of > > calling setSelection(start, end). > > Plus if we use openEditor, we would get the 'back' support from the > inputChanged, no? Changing to openEditor does work as we expected. Steps: 1. open hover.js in the JS bundle 2. select _convertTagType on line 66 3. F3 4. notice the URL changes to: web/javascript/hover.js,start=6832,end=6847 (good) 5. hit the back button, nothing happens except that the URL changes back to: web/javascript/hover.js (In reply to Michael Rennie from comment #10) > (In reply to Michael Rennie from comment #9) > > (In reply to Silenio Quarti from comment #8) > > > The URL has a start,end parameter we can use. I believe we can change > > > openDeclaration.js to call openEditor with start/end parameter instead of > > > calling setSelection(start, end). > > > > Plus if we use openEditor, we would get the 'back' support from the > > inputChanged, no? > > Changing to openEditor does work as we expected. Should have read 'does NOT work as we expected'... I pushed the changes to always use openEditor, and I'll figure out what happening no the editor side that prevents us from going back to the original spot after the first open decl. The change URL: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=d3eaa6e85e423950a1574d295d072489903a97f9 Created attachment 255721 [details]
fix for remaining problem
These changes fix the remaining problem. I am not confident they are correct. Loading the previous context in the InputChanging event seems wrong. Need to test further.
Michael, are things working as you expect (ie. you are setting the URL properly) but another problems in the editor or elsewhere is stopping it from working? (In reply to Steve Northover from comment #14) > Michael, are things working as you expect (ie. you are setting the URL > properly) but another problems in the editor or elsewhere is stopping it > from working? Yes, if I open decl across files I can jump back to where I was (good). The command is now calling the new API openEditor(...), which correctly sets the URL (good). But we still cannot jump back to the starting location if the decl is opened in the same file. Sounds like the bug ownership should go to Silenio or a new bug entered with the steps that fail. Please try the latest. Fixed http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=5e0317b2fea9a124fe016c5bb7624e708234fc91 You can jump back on the first open decl (good), but if for some reason you select an element that has the same decl as the previous open decl, and try to open its decl, nothing happens in the editor.
Steps:
1. using the following snippet:
function Con () {
}
Con.prototype = {
prop1: function() {
this.prop2();
},
prop2: function() {
}
};
var c = new Con();
c.prop2();
c.prototype.prop2();
2. select prop2 in c.prototype.prop2 -> open decl
3. jump back (good)
4. do step 2 again, then select prop2 in c.prop2 -> open decl
5. nothing happens. The reason is that the URL is already still pointing to the range we want (ok I guess), but the selection does not happen again.
This happens because the URL hash does not change. Fixed http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=3c77dda9eb31470180067a1595ddc1601196e0fe Found another quirk: 1. use the snippet from comment 18 2. select prop2 and jump to decl 3. select c and jump to decl 4. hit back - notice you are taken back to the decl of prop2, not the position you jumped from Trying again. The only way I can see to keep multiple levels of open decl is to add the current location of the editor to the browser history just before navigating to the new location. Note that the session storage info we store can only remember one location. The session storage info is still needed because we have to show the same editor state if the page is reloaded (or another file is clicked in the navigator and then back). http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=ae937aa353efbd6454c8cb5c0be433624ff1e119 |
1) create a file 2) enter the following: function fred() { x++; } 3) after the closing "}", press return until fred() scrolls off the screen 4) enter the following: function fred54() { fred(); } 5) place the cursor on fred() within fred54() 6) Tools->Open Declaration 7) the cursor correctly moves to the declaration of fred() 8) BUG/FEATURE: I can't get back to fred() within fred54 easily() 9) hitting the back arrow (correctly) takes me somewhere else I realize that this isn't a bug but people need to easily navigate back and forth in their code regardless of where the code is (same file, different file). Any thoughts? Not doing this means that I lose my context.