Bug ID: JDK-8114965 Webview incorrectly uses String constructor when supplementary characters are present.

JDK 7	JDK 8
7u10Fixed	8Fixed

I've opened a separate CR (RT-26105); we can mark this as resolved and move the discussion there.
07-11-2012
> Should I file a new CR for this? Also, is there a CR regarding omitting single characters open? Please do. These two issues are likely to have single reason.
07-11-2012
I see your point, I'm just uncomfortable with the idea that another issue (related or unrelated to current one) might be hiding here. Before we end up with this discussion, please try another (slightly modified) application. Please notice that although WebView renders the character itself nicely when preceded with a latin letter, it still cannot be visible in the reference table (on my system at least). Should I file a new CR for this? Also, is there a CR regarding omitting single characters open? import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.VBox; import javafx.scene.text.Text; import javafx.scene.web.WebView; import javafx.stage.Stage; public class Main extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) { System.setProperty("proxyHost", "www-proxy.ru.oracle.com"); System.setProperty("proxyPort", "80"); System.out.println(com.sun.javafx.runtime.VersionInfo.getRuntimeVersion()); Text t = new Text("\ud800\udf02"); WebView wv = new WebView(); wv.getEngine().loadContent("<!DOCTYPE html><html><body>o 𐌂 </body></html>"); wv.setMaxSize(100, 100); wv.setMinSize(100, 100); wv.setPrefSize(100, 100); WebView wv2 = new WebView(); wv2.getEngine().load("http://en.wikibooks.org/wiki/Unicode/Character_reference/10000-10FFF"); VBox g = new VBox(); g.getChildren().addAll(t, wv, wv2); Scene s = new Scene(g); stage.setScene(s); stage.sizeToScene(); stage.show(); } }
02-11-2012
Tried the test today. On my system both Text and WebView don't render 0x10302 even though Safari does. Text renders a square instead, WebView renders nothing at all. For some reason Webkit swallows the character if it is the only character on a line. Try adding a Latin letter before 𐌂 Otherwise I found no differences between Text and WebView, but Safari rendered more chars than JavaFX indeed. I consider this particular bug fixed. Remember, without the fix, no supplementary characters could be rendered at all. Lombard seems broken at this time.
02-11-2012
I've tried that on my machine; did that with suspicious character 10300-2 (x10302). My test case: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.VBox; import javafx.scene.text.Text; import javafx.scene.web.WebView; import javafx.stage.Stage; public class Main extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) { System.out.println(com.sun.javafx.runtime.VersionInfo.getRuntimeVersion()); Text t = new Text("\ud800\udf02"); WebView wv = new WebView(); wv.getEngine().loadContent("<!DOCTYPE html><html><body> 𐌂 </body></html>"); wv.setMaxSize(100, 100); wv.setMinSize(100, 100); wv.setPrefSize(100, 100); VBox g = new VBox(); g.getChildren().addAll(t, wv); Scene s = new Scene(g); stage.setScene(s); stage.sizeToScene(); stage.show(); } } Text renders the character perfectly, WebNode cannot do that (with both 7u10 b07 and 7u10 b13). Exactly same picture can be observed on Alexander's system (character in WebView cannot be visible); however, on http://en.wikibooks.org/wiki/Unicode/Character_reference/10000-10FFF test page this character is rendered on his system, and is not on mine. I've noticed, by the way, that the set of rendered characters in Lombard is completely different, and the example attached doesn't work at all on both systems.
31-10-2012
Try running Phil's test case from RT-20545, just change the values to the characters that look suspicious. Are there any differences between Text and WebView rendering? Any differences between the two systems?
31-10-2012
The results were acquired from different computers. I've tried it on my system (which I used to evaluate the CR initially), and my results for b13 are same as for b07. This, however, looks even more strange - I don't get it, why is there so much difference between two Win7 systems (both with MingLiu-ExtB font installed)?
30-10-2012
Strange. I don't think there were any fixes in 2.2.4 after this one. Are these different results observed on the same computer?
30-10-2012
So which exactly characters are wrong?
30-10-2012
What Aleksandr meant was that the set of rendered characters has changed since b07, and now different characters are rendered - this means some of previously rendered characters are not anymore, and new characters are now available (please check the ranges that I and Aleksandr have provided in our comments - they are different). E.g., in b07 10300-F has been rendered in b07, but is not now; 10300-2 was not rendered in b07, but is now. We think this might indicate some change in inner mechanics, and maybe even some issue. However, if you think that this is definitely not an issue, please let us know an we will close this CR again.
30-10-2012
Since b07 things changed. Symbols I see with 2.2.4 b12 differs from what Irina saw. Now I see 2-7 for 10300-10310 and 10330-10340, 2-3 for 10320, 0-F for 10400-10440, 0-F for 10C00-10C30, 0-8 for 10C40.
24-10-2012
I can see most of the green symbols (7 to F for 10300, 13010, 10330 and 10340; all symbols from 10400 to 10440) and one set of purple symbols (all symbols from 10C00 to 10C40 rows) with latest 2.2.4 and Lombard bits (2.2.4-ea-b07 and 8.0.0-ea-b56). I guess this is what Peter meant when he was saying some symbols in 1 to F columns should become visible :) I'm closing this as verified.
17-09-2012
Adding to what Peter wrote, on Windows, make sure you have the font MingLiu-ExtB installed. -phil.
12-09-2012
It depends on fonts installed on your system -- they may not have a glyph for the character mentioned in RT-20545. I've used Unicode char sheets from my comment above. Without the fix not a single character from outside Plane 0 can be rendered. After the fix some characters have appeared.
12-09-2012
I would like to verify this. Is it possible to use example from RT-20545 to reproduce the problem and make sure it doesn't exist anymore?
10-09-2012
The reason is, in GlyphPage::fill() we don't expect surrogate pairs in the character buffer. When the characters come from outside the Unicode Plane 0 (aka BMP) they are encoded as surrogates in the [buffer], and [bufferLength] == 2[length], see GlyphPageTreeNode::initializePage(). We currently process only the first [length] characters, and, worse, return high and low surrogates as glyph codes instead of full code points. Fix: http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-24327/1 Summary of changes: GlyphPage::fill() now sends into Java an array of code points rather than chars. On the Java side, no processing is done at all, as we currently use code points as glyph codes. For this reason we cannot use unsigned short for glyph codes, so I had to make the change to Glyph.h. * The [offset] parameter to GlyphPage::fill() is now treated differently, in the same way as in other ports, e.g. Qt. I believe it is always 0, which is why current code does not cause bugs. * I've removed a workaround from WCFontImpl.java that is no longer relevant. For testing I've used Unicode character sheets, e.g. http://en.wikibooks.org/wiki/Unicode/Character_reference/10000-10FFF No regressions in either unit tests or DRT.
06-09-2012
Bump priority to Major to match the priority of RT-20545 and add 222-candidate tag (it was removed from RT-20545 because that issue is resolved in the 2.2 GA release).
29-08-2012
Hi, can we please increase the priority of this. The original bug RT-20545 filed by me had the "222-candidate" tag (which was subsequently removed).
20-08-2012
Given this issue and glyph support that comes with RT-17411, we may want to revisit our font rendering code.
17-08-2012
See RT-20545 for more details.
17-08-2012

Duplicate :	JDK-8127584 - WebView does not support rendering surrogate pair charcter
Relates :	JDK-8125928 - Surrogate pair characters are not rendered in certain conditions