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

Bug 352572

Summary:

[Client] Java script error pages outside of requests only in "developer" mode

Product:

[RT] RAP

Reporter:

Sabine Neubauer <neubauer>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

enhancement

Priority:

CC:

tbuschto

Version:

1.4

Target Milestone:

1.5 M6

Hardware:

All

OS:

All

Whiteboard:

sr142

Attachments:

Description	Flags
patch for 1.4 branch	none
revised patch for 1.4 branch	tbuschto: review?

Description Sabine Neubauer

2011-07-20 08:55:51 EDT

Build Identifier: 

Since fix of issue 334758 (RAP 1.4 M6) java script errors outside of the request are also caught and an error page is displayed. On the one hand we see that several errors are found now which in parts exist a long time. This surely improves the quality. On the other hand in a productive environment this is very annoying because the user has to reload the page and in our case he must login again.

In our application the reason for the errors are cell tooltips, disposed tables, ...

I think it would be great to have a possiblity to deactivate the error pages which are shown caused by errors outside the requests. For example, the error pages are shown in debug (developer) mode, but not in standard (productive) mode. Hence, it would be possible to recognize the java script errors while testing but the end user does not see an error page as frequently.

Newsgroup entry about reverting the behavior: http://www.eclipse.org/forums/index.php/t/220370/

Reproducible: Always

Comment 1 Tim Buschtoens

2011-11-08 09:30:41 EST

Created attachment 206595 [details]
patch for 1.4 branch

We decidid to introduce this behavior for RAP 1.4.2. In standard mode, the error will be logged to the javascript console if present, and otherwise ignored. In the debug-variant it still crashes the entire client application. Errors within a server-response are also still crashing, as the server has to rely on the client being in sync.

As argued by the reporter, total crashes are very enduser-unfriendly. Often these out-of-request errors are non-critical issues, like a failed DOM access while rendering a hover-effect. In addition, if such an error did not occour during developlent, its likely that they may only appear on a very specific configuration, like a certain browser-version with a plugin/addon of a certain version.

Comment 2 Tim Buschtoens

2011-11-09 04:50:55 EST

Created attachment 206656 [details]
revised patch for 1.4 branch

Revised patch using typeof to check for console.

Comment 3 Ralf Sternberg

2011-11-09 05:07:16 EST

I agree with Tim. Since this kind of DOM errors is mostly beyond our control and mostly less critical, letting the entire application crash is too aggressive for production mode. As requested, the change only affects errors that occur outside of requests.

Committed the second patch to 1.4 maintenance branch, so the fix will be part of 1.4.2.
I think we should do the same for HEAD.

Comment 4 Sabine Neubauer

2011-11-17 04:34:55 EST

(In reply to comment #3)
> Committed the second patch to 1.4 maintenance branch, so the fix will be part
> of 1.4.2.
> I think we should do the same for HEAD.

First, thanks for solving this issue for RAP 1.4.2. Now I don't have to generate the client.js by myself anymore.

I agree with Ralf and think this should be introduced on HEAD, too.

Comment 5 Tim Buschtoens

2012-02-28 07:12:25 EST

Commited changs to CVS HEAD.

Also made some small improvements to the printed message itself. (Prints stack if browser supports it).