| Summary: | CodeEdit: Reload Issue when using CodeEdit-Widget from Angular2. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | libing wang <libingw> | ||||
| Component: | Editor | Assignee: | Michael Rennie <Michael_Rennie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P2 | CC: | balzer814_dev, pahnke.sebastian, Silenio_Quarti, steve_northover | ||||
| Version: | 15.0 | ||||||
| Target Milestone: | 16.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| See Also: | https://github.com/eclipse/orion.client/pull/202 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
libing wang
Some further comments from Sebastian. Thanks Sebastian! I am having similar issues but using the Aurelia SPA framework, so I think SPA frameworks in general are affected. I didn’t have much time to analyse it, but here is what I have found so far. Maybe it helps tracking this down. Note that I’m using the CodeEditWidget successfully in the SPA setting with a version prior to the first bad commit I found below. git bisect: first bad commit is commit 2bf1ab574d900f603f6e6a0891b11e31b04a57a7 Author: Mike Rennie <Michael_Rennie@ca.ibm.com> Date: Thu Mar 2 09:55:11 2017 -0500 Bug 512847 - Race condition getting computed environment Further Analysis: - TernServer is not restarted after a navigation took place - TernProjectManager.loadTernProjectOptions is not called - should be coming from refresh - which in turn should be coming from onModified or onInputChanged (if I analysed correctly) - When setting a breakpoint in the first line of onModified it seems to trigger a race condition, which actually leads to the server being restarted. But this is not reproducible every time. To clarify: In my case the editor itself loads after navigation, the tooling does not. This seems to be different from Philipp's case where the editor itself does not seem to load. (So maybe we need separate bug reports?) I attached a bundled example with the Orion editor from September, 4th. Just unzip and start a webserver in the folder. The first time the tooling loads fine, after navigation not anymore. Created attachment 270330 [details]
Bundled SPA using Aurelia
(In reply to Sebastian Pahnke from comment #2) > To clarify: In my case the editor itself loads after navigation, the tooling > does not. This seems to be different from Philipp's case where the editor > itself does not seem to load. (So maybe we need separate bug reports?) > > I attached a bundled example with the Orion editor from September, 4th. Just > unzip and start a webserver in the folder. The first time the tooling loads > fine, after navigation not anymore. I have been testing this on orion.eclipse.org and using our codeEdit demo, and cannot reproduce - the tern project is always loaded after nav / refresh. I'll try next using the attached example. Are there any entries in the log? (In reply to Michael Rennie from comment #4) > (In reply to Sebastian Pahnke from comment #2) > > To clarify: In my case the editor itself loads after navigation, the tooling > > does not. This seems to be different from Philipp's case where the editor > > itself does not seem to load. (So maybe we need separate bug reports?) > > > > I attached a bundled example with the Orion editor from September, 4th. Just > > unzip and start a webserver in the folder. The first time the tooling loads > > fine, after navigation not anymore. > > I have been testing this on orion.eclipse.org and using our codeEdit demo, > and cannot reproduce - the tern project is always loaded after nav / refresh. > > I'll try next using the attached example. > > Are there any entries in the log? Just testing now - starting a server using 'http-server' from node - I also get the tools loading properly every navigation and refresh. Do you have any additional steps I can try? Is there a special way you are running your server perhaps? The tooling always works for me after a refresh, but not after a SPA navigation. I tested this with http-server directly, the Aurelia CLI spinning up a server and in an ASP.NET MVC application running on IIS. All with the same result. Browsers used: latest Chrome, latest Safari, IE 11, Firefox 55 Here are the steps to reproduce: 1. Start the web server and navigate to the page 2. Notice the blue squiggly in the editor; also content assist works 3. Click on "Diff editor" in the navigation bar 4. Click on "Code editor" in the navigation bar (or use the back button) 5. Notice that the blue squiggly is not there anymore; also content assist does not work 6. Refresh the page 7. Tooling works again As I said earlier, this worked fine with an earlier version of the CodeEditWidget. I reproduced the bug described in https://github.com/meyerpp/orion-codeedit-example/issues/1 also when i replaced the Orion CodeEdit-Widget with release 11 form http://download.eclipse.org/orion/ which was released at in early 2016 The problem also seems to be that the tooling is not loading. (In reply to Sebastian Pahnke from comment #6) > The tooling always works for me after a refresh, but not after a SPA > navigation. I tested this with http-server directly, the Aurelia CLI > spinning up a server and in an ASP.NET MVC application running on IIS. All > with the same result. > > Browsers used: latest Chrome, latest Safari, IE 11, Firefox 55 > > Here are the steps to reproduce: > 1. Start the web server and navigate to the page > 2. Notice the blue squiggly in the editor; also content assist works > 3. Click on "Diff editor" in the navigation bar > 4. Click on "Code editor" in the navigation bar (or use the back button) > 5. Notice that the blue squiggly is not there anymore; also content assist > does not work > 6. Refresh the page > 7. Tooling works again > > As I said earlier, this worked fine with an earlier version of the > CodeEditWidget. Reproduced the problem. The problem is that the changes from around that commit (and forward) changed how we reset the tern worker - it is all based on if the project context changes vs. just if the input changes (to avoid resetting too often). However, if the input changes to an "important file" and a modification is made, the server will also reset (this case is what happens in the onInputChanged handler). The tooling will never fire out a projectChanged event after the first time, because the widget only has one "project" context that does not change. That being said, it seems like navigating to /diff and back to /edit again is resetting the 'ternready' flag in the js plugin, so all messages are being queued in the plugin and never get sent. The worker is still running, and the tooling is trying to work (sending requests), but the state is saying the worker has become "not ready". Investigating further... Yes, this matches my observations. Queued requests that never get handled. Found bug 525238 while investigating. Seems that after the nav, we process onModified for the creation of the .tern-project file (when the widget starts up), which sets the state to 'not ready', but since the project context does not change and we were never in the editor for the .tern-project file, we do not properly reset the flag. GitHub Pull Request 202 created by [mrennie] https://github.com/eclipse/orion.client/pull/202 Merged. |