Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 421385

Summary:	frequently losing scroll position in editor with Orion Node server
Product:	[ECD] Orion	Reporter:	Manu Sridharan <m.sridharan>
Component:	Node	Assignee:	Mark Macdonald <mamacdon>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	mamacdon
Version:	5.0
Target Milestone:	5.0 M1
Hardware:	PC
OS:	Mac OS X
Whiteboard:

Description Manu Sridharan

2013-11-08 22:39:38 EST

I'm using the Orion Node server, and I'm finding that when editing a JavaScript file, the editor frequently scrolls to the top for no apparent reason.  It seems like the behavior one would expect when the file has been edited by some other program, but no other program is touching the file.  I never noticed this behavior with the Java server, so I suspect it may be the Node server causing the problem.  This is on the latest orion.client from git, with the server invoked via 'node server.js -w ~/git-repos'.  The refresh sometimes occurs when switching back to the browser after switching to another program, but it also happens in the middle of editing.  

Sorry for the lack of a detailed test case to reproduce.  If someone has a tip on how I could make such a thing, please let me know.  For me, this bug makes it very difficult to use Orion as my primary JS editor.

Comment 1 Mark Macdonald

2013-11-08 22:50:13 EST

This could be caused by autoload. When there's a change detected on the server, IIRC the editor scrolls back to the top as the file's new contents is reloaded (which is probably a bug in itself, but regardless)... Perhaps the Node server logic for detecting changes in the file is generating false positives.

It'd be helpful to have a network log open when this is happening and see if the occurrence of scroll-to-top corresponds to a network request -- that would implicate autoload.

Comment 2 Manu Sridharan

2013-11-08 23:31:35 EST

Ok, I'll keep the network log open and see if there's a request right before the unwanted scroll.

Comment 3 Manu Sridharan

2013-11-08 23:43:05 EST

Ok, I figured out how to reproduce.  Steps:

1. Start up Node server.
2. Open up multi-line JavaScript file in the browser (choose a file that takes more than one screen to see the problem more clearly).  I'm using Chrome on Mac.
3. Add a character to the end of the file.
4. Command-S to save.
5. Command-Tab to another application.
6. Command-Tab back to the browser.  You should observe the cursor position go back to the top of the file, in spite of there being no edit from another application.

I usually do steps 5 and 6 fairly quickly, but I still observed the problem even when waiting 5-10 seconds after step 4 or step 5.  

Let me know if this doesn't work to reproduce.

Comment 4 Mark Macdonald

2013-11-20 17:15:29 EST

I can reproduce it. The ETag returned upon saving the file is wrong. When you refocus the window, the editor checks and receives a different ETag (the correct one). The change of ETags makes the editor believe the file has changed on disk, so it reloads.

Comment 5 Mark Macdonald

2013-11-20 23:32:26 EST

This is fixed in master.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=483e870

While writing tests for it, I found some separate issues that caused requests to hang when a client provided a JSON Content-Type header, and fail if an empty patch was provided. These are also fixed.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a035c0d

Comment 6 Manu Sridharan

2013-11-20 23:36:23 EST

Works for me now.  Thanks!!