JDK-8179321 : WebEngine.getDocument().getDocumentURI() no longer returns null for loading a String of HTML
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u131,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2017-04-26
  • Updated: 2020-01-31
  • Resolved: 2017-04-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u141Fixed 9Fixed
Related Reports
Relates :  
In Java 8 U121 and earlier, if you called WebView.loadContent on an Html String and called javafx.scene.web.WebEngine.getDocument().getDocumentUri() the answer was always null, now the answer is "about:blank". Previously this result was reserved for pages were loaded with "about:blank" directly.

Attached is a reproducible test case that shows the change in behavior between Java 8 U121 and Java 8 U131 which broke our application.

Is this something you can put back?
Is this a documented change?
If you can't put it back, how do we now tell the difference between a page that was loaded with "about:blank" and an html string that was passed into the WebEngine.loadContent("Html String")?

We have customers using webstart who will have their JREs automatically upgraded to Java 8 U 131 and our application will break because of this change. 
changeset: 9e024aac43ca parent: a3da54ae1f1f user: arajkumar date: Thu Apr 27 00:09:42 2017 +0530 description: 8179321: WebEngine.getDocument().getDocumentURI() no longer returns null for loading a String of HTML Reviewed-by: kcr, ghb URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9e024aac43ca

Fix request approved This fix can now be pushed to FX 9-dev for JDK 9.

Looks good to me, +1.

Fix Request a) Why it's important to fix this bug: This bug is a regression after new WebKit upgrade (JDK-8166999), it breaks few customer applications. b) Explain the nature of fix: WebKit DOM binding related IDL files has support for DOM3 interface under a define, just we need to enable the define for Java language binding. c) Estimate its risk: This is low risk fix, it just enables the legacy code path. d) Describe its test coverage: Unit test case added under DOMTest, it loads a simple page as `String` and tests Document.documentURI remains null after loading the string. e) Reviewer: [~kcr] and [~ghb]

Thanks [~kcr]. Fixed the typo: http://cr.openjdk.java.net/~arajkumar/8179321/webrev.01/

Fix looks good to me. I tested that the new unit test (and the attached app) fail without the fix and pass with the fix. I also confirmed that that the java-wrappers file matches exactly the new generated file. One minor typo in a comment in the test: + // Stil we are supporting DOM3 interface, need to relook once we move to Should be "Still" I want to see Guru's review before approving it for JDK 9.


In this bug I will be addressing only `Document.documentURI` property, new bug(JDK-8179362) has been created to identify other DOM3 compatibility issues.

Document.documentURI behavior is now matching with DOM4 spec after last WebKit upgrade(JDK-8166999). But JavaFX is still supporting old DOM 3 interface like ObjC & GTK binding, we need to add a condition in Document.idl to support DOM3 similar like ObjC & GTK bindings.

[~ghb] Please assign someone to look into this regression.