Bugzilla – Full Text Bug Listing
| Summary: | Error reporting for disconnected and not logged in state | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Maciej Bendkowski <maciej.bendkowski> | ||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | antonm, ken_walker, libingw, maciej.bendkowski, mamacdon, simon_kaegi | ||||
| Version: | unspecified | Flags: | mamacdon:
review+
|
||||
| Target Milestone: | 1.0 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 391470 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
(In reply to comment #0) >Such errors should be somehow decorated or even hidden. I'm all for nicer error messages, such as "could not find github.com" instead of "unknown host", but I would definitely want an error to be reported for this case. Simon mentioned in today's UX call that he would like an error handler for unknown host when you try to save in the editor. I told him I'd look at it. I'll try to put a generic error handler somewhere that we could use for any command that reports unknown host in a nice way (you appear to be disconnected)... If you self host, open a file on the self hosted site and edit it, then stop the self hosted site and try to save. There is a 404 generated in fileImpl.js:318 (In reply to comment #3) > If you self host, open a file on the self hosted site and edit it, then stop > the self hosted site and try to save. There is a 404 generated in > fileImpl.js:318 The 404 is a bit of a different case because the site support generates this. If you unplug your network connection and then try to save an editor change, you never get any kind of error response, it's being swallowed somewhere. I traced it from our fileClient.write to the fileImpl, all the way down into our implementation of xhr. The timeout event is never called on the XHR, there's no error coming out of that call. I'm not really sure where to take this. Talked to Mark. He's going to look at this one. One theory is that the browser's XHR doesn't fire a timeout event when the connection is never opened. I'll also look at other cases. Seems we should handle: - user is truly disconnected - user is connected but host wasn't found - user is connected but not logged in (In reply to comment #5) > Talked to Mark. He's going to look at this one. One theory is that the > browser's XHR doesn't fire a timeout event when the connection is never > opened. Turns out that WebKit doesn't support the XMLHttpRequest.timeout property, which orion/xhr relied on. It is now emulated using setTimeout if necessary: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=2044f9440636f4bb83531b3c52386cd4d2244117 There's still something not right here. I can see the timeout firing now, but we never get to the error handler of the caller. I put a breakpoint on the "then" of the deferred and it is not hit. At first I thought the deferred is already resolved by the time the timeout triggers, but I'm not sure. I can step through the reject code in Deferred but it never makes it back to the caller. Errors should now be reported in the editor status line after the save fails. If the server is down, you see a message saying "No response from server". http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=1241a78239e40fa1640062f6ac750243441a52fb I think we're good here for now. Susan, feel free to open a bug and we can iterate on this in RC2 if there's more to do. > Susan F. Mccourt: you can send that bug back to me, i think we should be using the progress service
> 10:54:17 PM: Susan F. Mccourt: (which will make a more permanent error, and let us put links in it)
I added code to use the progress result reporting (error slideout) to handle the error case, and to include a link to the login page when the server does not respond. Mark, can you review/cherry pick/release? http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=71eb36556b25209108b831f0552a35c7c2112fcd The change includes a change to the message service so that HTML messages get the same styling as their plain text counter parts. When the user is truly disconnected, the login link won't really help, but it's something they can try. We still have a problem that 401/Unauthorized isn't making its way back to the client at all. I'd like to add similar error handling for 401 (link to login page) but need some help figuring out what happened to the error. Mark? The 401 shows up in the network debug tab on chrome, but no exception is received in the xhr code. (In reply to comment #11) > Mark, can you review/cherry pick/release? > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/ > ?id=71eb36556b25209108b831f0552a35c7c2112fcd remote branch is called "disconnectedErrors" (In reply to comment #12) > The 401 shows up in the network debug tab on chrome, but no exception is > received in the xhr code. fileClient passes off the 401 to auth.handleAuthenticationError(), but that call throws an exception because of bug 391470. The 401 is lost due to the exception. Libing is fixing 391470 and I am pushing a fix for fileClient to make it tolerant of auth-code exceptions -- rejected fileService calls should never be swallowed from now on. Thanks, Mark. Okay. That means that we'll get the little "log in" popup again, so there's no need for a login link to appear in the progress bar. I will rework the solution for "disconnected" state so that it doesn't try to link you to login. I'll ping you again when there's something for review. The commit is http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=af45c3402a0ec173a0f5bcd2316561dc39ea5f11 Git Log kept 404'ing when I tried to push this to a remote branch. I tried the original branch and a new branch. I pushed to master in frustration. fixed. |
Created attachment 220833 [details] Java net UnknowHost error I lost internet access while trying to fetch from a remote and I've noticed the error message slideout (see attachment). I think we shouldn't pass the internal java error type in a raw form to the client, like java.net.UnknownHost. Such errors should be somehow decorated or even hidden.