Bug 349523

Comment 1 Sabine Neubauer 2011-06-16 03:36:20 EDT

Created attachment 198066 [details]
Project for reproducing the problem

Comment 2 Sabine Neubauer 2011-06-16 03:36:53 EDT

Created attachment 198067 [details]
Screenshot showing the cropped proposals

Comment 3 Ivan Furnadjiev 2011-06-16 03:59:35 EDT

Reproducible with CVS HEAD.

Comment 4 Ivan Furnadjiev 2011-06-16 10:05:25 EDT

The problem was in the private method Table#max. In case of TableItems with the same text length this method leads to wrong measured item, because the actual item text width is not taken into account. The fix is to compare the items by actual text width instead of text length. Not possible to create JUnit test as this method rely on actual text size determination values (not the estimated one). Changes are in CVS HEAD.

Comment 5 Sabine Neubauer 2011-06-16 11:30:47 EDT

I patched the Table#max method in my used RAP bundles based on RAP 1.4 RC2 and retested the issue.

First all seemed to be fine, but if the proposals text contains a sequence of spaces, the behavior is strange. First the proposals are not cropped, than the table get refreshed and the proposals are cropped. The problem only occurs if the spaces are within the text. Leading spaces seem to be no problem.

In order to reproduce this, you have to adapt the SampleView of the attached project. By replacing the line:
    String itemText = "item " + UUID.randomUUID().toString();
with
    String itemText = "item      " + UUID.randomUUID().toString();

I have checked this with InternetExplorer 8 and Firefox 3.6

Comment 6 Ivan Furnadjiev 2011-06-16 12:59:54 EDT

The problem is in TextSizeUtilFacadeImpl#createItemParamFragment method. Here *only* leading and trailing spaces are escaped, before sending the string to the client for actual size measurement. I remember that this was done due to some problems in the past with wrapped text measurement. Ralf, do you remember exactly why the multiple spaces in the middle of the string are not escaped? If this is not a problem anymore we could replace:
---
textToMeasure = EncodingUtil.escapeLeadingTrailingSpaces( textToMeasure );
---
with:
---
textToMeasure = EncodingUtil.replaceWhiteSpaces( textToMeasure );
---

Comment 7 Sabine Neubauer 2011-11-17 04:30:06 EST

(In reply to comment #6)
> If this is not a problem anymore we could replace:
> ---
> textToMeasure = EncodingUtil.escapeLeadingTrailingSpaces( textToMeasure );
> ---
> with:
> ---
> textToMeasure = EncodingUtil.replaceWhiteSpaces( textToMeasure );
> ---

What's the current state of this issue? Will it be possible to fix it for RAP 1.4 SR2?

Comment 8 Ralf Sternberg 2011-11-17 05:01:04 EST

(In reply to comment #6)
> The problem is in TextSizeUtilFacadeImpl#createItemParamFragment method. Here
> *only* leading and trailing spaces are escaped, before sending the string to the
> client for actual size measurement. I remember that this was done due to some
> problems in the past with wrapped text measurement. Ralf, do you remember
> exactly why the multiple spaces in the middle of the string are not escaped?

If we'd escape them, i.e. turning them into nbsp's, then text would not wrap anymore. Years ago we discussed replacing them by a sequence of spaces and nbsp's, so that the browser would not trim the spaces but still is able to wrap texts. But even with this approach, there are issues. At any rate, we should have a specific bug for the TSD issue.

In the context of supporting alternative clients the whitespace replacement will have to go to the client, doesn't it? We should not render   entities to native clients.

Comment 9 Ralf Sternberg 2011-11-17 05:05:14 EST

(In reply to comment #7)
> What's the current state of this issue? Will it be possible to fix it for RAP
> 1.4 SR2?

I'm sorry, but since this is not one of our current priorities, I cannot make any commitments here. If you need a fix quickly, check out our professional support: http://eclipse.org/rap/support/professional-services/

Comment 10 Ivan Furnadjiev 2011-11-17 05:27:57 EST

(In reply to comment #8)
> In the context of supporting alternative clients the whitespace replacement
> will have to go to the client, doesn't it? We should not render   entities
> to native clients.
With the migration of TSD to the protocol all escaping are performed on the client.

Comment 11 Ivan Furnadjiev 2012-02-13 07:42:32 EST

I've opened a separate bug 371360 for the TSD issue. I will close this one as fixed as the initial bug in the Table has been fixed.