8267554: Support loading stylesheets from data-URIs

[mstr2]

This PR extends data URI support to allow stylesheets to be loaded from data URIs.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8267554: Support loading stylesheets from data-URIs

Reviewers

• Kevin Rushforth (@kevinrushforth - Reviewer)
• Ajit Ghaisas (@aghaisas - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/536/head:pull/536
$ git checkout pull/536

Update a local copy of the PR:
$ git checkout pull/536
$ git pull https://git.openjdk.java.net/jfx pull/536/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 536

View PR using the GUI difftool:
$ git pr show -t 536

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/536.diff

[bridgekeeper]

👋 Welcome back mstrauss! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 06: Full - Incremental (230cc49e)
• 05: Full - Incremental (64d72fe3)
• 04: Full - Incremental (c734640f)
• 03: Full - Incremental (7dfbc0cb)
• 02: Full - Incremental (39ff7583)
• 01: Full - Incremental (70c29866)
• 00: Full (16119e8c)

[kevinrushforth]

/reviewers 2
/csr

[openjdk]

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

[openjdk]

@kevinrushforth has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@mstr2 please create a CSR request for issue JDK-8267554. This pull request cannot be integrated until the CSR request is approved.

[kevinrushforth]

I looked at just the public API and spec, and have two comments:

• I don't see any justification for adding Stylesheet::loadBinary(InputStream) to the public API. See my comments inline.
• Do you intend to support setting a user agent stylesheet via a data URL? The docs should be explicit about whether or not a data URI can be used for the following methods:
  • Application::setUserAgentStylesheet
  • Scene::setUserAgentStylesheet
  • SubScene::setUserAgentStylesheet

[mstr2]

• Do you intend to support setting a user agent stylesheet via a data URL? The docs should be explicit about whether or not a data URI can be used for the following methods:

  • Application::setUserAgentStylesheet
  • Scene::setUserAgentStylesheet
  • SubScene::setUserAgentStylesheet

Data URIs also work for user-agent stylesheets. I added documentation to each of the methods.

[kevinrushforth]

The API and spec changes look good. As I mentioned in a comment added to the CSR, it is ready to move to "Proposed". Once we are farther along in the code review, I'll formally review the CSR.

One thing I noticed is that the diffs don't exactly match what you pasted in the CSR (looks like a copy/paste issue). The Scene::setUserAgentStylesheet and SubScene::setUserAgentStylesheet methods each have three unchanged lines that are marked with the + diff indicator. Can you double-check?

I'll review the implementation next.

[mstr2]

One thing I noticed is that the diffs don't exactly match what you pasted in the CSR (looks like a copy/paste issue). The Scene::setUserAgentStylesheet and SubScene::setUserAgentStylesheet methods each have three unchanged lines that are marked with the + diff indicator. Can you double-check?

I've fixed that, and also cleaned up the <p> tags for the new paragraphs.

[kevinrushforth]

I spent some time analyzing the changes to StyleManager::loadStylesheetUnPrivileged, especially around the use of the local parse variable, since you no longer modify it during the processing in a couple places. I think everything is fine, but I'd like @aghaisas to also look at this when he reviews it. If @dsgrieve has any comments, they would be welcome.

The following is the current behavior for the case where fname ends with .css or .bss:

fname	.css exists	.bss exists	Result
SOMENAME.bss	YES	NO	fail
SOMENAME.bss	NO	YES	Use SOMENAME.bss instead
SOMENAME.bss	YES	YES	Use SOMENAME.bss
SOMENAME.css	YES	NO	Use SOMENAME.css
SOMENAME.css	NO	YES	Use SOMENAME.bss (NOTE: if -Dbinary.css=false then fail)
SOMENAME.css	YES	YES	Use SOMENAME.bss (NOTE: if -Dbinary.css=false then SOMENAME.css)

In case where fname ends with neither .css nor .css, it is assumed to be a CSS file and parsed as such.

As near as I can tell, both from reading the code and from running tests, this is still working as expected. So there should be no regression in behavior.

The code to process a data URI looks good.

As for the tests, can you add at least one test of calling the public setUserAgentStylesheet method using a data URI? Maybe as part of StyleManagerTest? Also, I left a couple suggestions inline.

[mstr2]

I added a test for each of Application.setUserAgentStylesheet, Scene.setUserAgentStylesheet, and SubScene.setUserAgentStylesheet.

[kevinrushforth]

Changes look good. I'll do a final pass tomorrow.

[aghaisas]

Code changes are OK.
I found an Exception being logged from newly added test. Please check.

[kevinrushforth]

Looks good.

[openjdk]

@mstr2 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8267554: Support loading stylesheets from data-URIs

Reviewed-by: kcr, aghaisas

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 6 new commits pushed to the master branch:

• 3fd4c97: 8234920: Add SpotLight to the selection of 3D light types
• 063bfe8: 8264137: Suppress deprecation and removal warnings of internal methods
• 8e11b94: 8268915: WebKit build fails with Xcode 12.5
• 45786ac: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability
• 04493e5: 8165214: ListView.EditEvent.getIndex() does not return the correct index
• 13cffba: 8269026: PasswordField doesn't render bullet character on Android

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@kevinrushforth, @aghaisas) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[mstr2]

/integrate

[openjdk]

@mstr2
Your change (at version 230cc49) is now ready to be sponsored by a Committer.

[kevinrushforth]

/sponsor

[openjdk]

Going to push as commit 78179be.
Since your change was applied there have been 6 commits pushed to the master branch:

• 3fd4c97: 8234920: Add SpotLight to the selection of 3D light types
• 063bfe8: 8264137: Suppress deprecation and removal warnings of internal methods
• 8e11b94: 8268915: WebKit build fails with Xcode 12.5
• 45786ac: 8252238: TableView: Editable (pseudo-editable) cells should respect the row editability
• 04493e5: 8165214: ListView.EditEvent.getIndex() does not return the correct index
• 13cffba: 8269026: PasswordField doesn't render bullet character on Android

Your commit was automatically rebased without conflicts.

[openjdk]

@kevinrushforth @mstr2 Pushed as commit 78179be.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.