UIDL response is corrupted when a system error occurs on the server side

[mshabarov]

• Description of the bug

When an exception is throws on the server side in a portlet, the DefaultPortletErrorHandler intercepts it and generates a response with JSON containing error information. Then, at some point something is trimming the JSON so as it looks like follows: for(;;);[{"changes":{},"resources": As a result, the error message is not shown in the portlet area.

Another problem is that the error box is not shown at all, but instead the error message div is added to the page DOM, instead of portlet shadow DOM.

• Minimal reproducible example

  1. To reproduce the issue, use the liferay-test branch, and this test: https://github.com/vaadin/portlet/tree/liferay-test/vaadin-portlet-liferay-integration-tests/liferay-tests-generic/src/main/java/com/vaadin/flow/portal/liferay/errorhandling
  2. Build the project and deploy error handling portlet as well as vaadin-portlet-static portlet into Liferay container.
  3. Add the error handling portlet to the page and click on the "Click me!" button.

• Expected and actual behavior Expected: the red message box showing the original error text within the portlet content area. Actual: message added to the end of the page with unrelated text:

  

• Versions:

  • Vaadin Portlet version 1.0.0.beta4
  • Flow version 2.8.3
  • Portal (Pluto) version Liferay 7.4.3.5-ga5
  • Java version 11
  • OS version Mac OS
  • Browser version (if applicable) Chrome 99

[mshabarov]

I've compared the way how the Pluto and Liferay generate the JSON with error information. They do it in the same way:

1. PortletUidlRequestHandler handles RPC via getRpcHandler(session).handleRpc(uI, request.getReader(), request);
2. The exception being throws is caught then with DefaultPortletErrorHandler and the following JSON is generated:

   for(;;);[{"changes":{},"resources":{},"locales":{},"meta":{"appError":{"caption":"RuntimeException","url":null,"message":"Exception!","details":"Caused by: N/A","querySelector":"[data-portlet-id='_errorhandling_WAR_liferaytestsgeneric_INSTANCE_oshz_']"}},"syncId":-1}]

   and written into the response.

3. Then the writeUidl(uI, stringWriter, false); generates for(;;);[{"syncId":3,"clientId":3}] JSON and writes it to the response.
4. Finally, the uidl request handler sets the response content length as "35", which is the length of the string in (4).
5. The difference between Pluto and Liferay is that the Liferay consider length "35" strictly and trims the string from (2) to the 35 characters. This doesn't happen with Pluto, it's content length in the response is still 261.

The solution I see so far is to take this specific behaviour for Liferay and do not set the smaller that actual length.