-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8257664: HTMLEditorKit: Wrong CSS relative font sizes #1759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
CSS font-size inherits a computed value which is an absolute value: - https://www.w3.org/TR/CSS2/cascade.html - https://www.w3.org/TR/CSS2/fonts.html#font-size-props
Hi @stanio, welcome to this OpenJDK project and thanks for contributing! We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user stanio" as summary for the issue. If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing |
I'll need a few days to find a printer and a scanner for submitting OCA. |
@stanio This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
I'll try to get my OCA done this week. |
I've just emailed my scanned OCA. |
Webrevs
|
Thank you. Your OCA has been processed and your account has been marked as verified. |
|
||
/* | ||
* @test | ||
* @key headless |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to specify headless tag. If it's not @key headful, then it is implicitly headless
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the test is headful because it uses SwingUtilities.invokeAndWait
even though it does not show any UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've used SwingUtilities.invokeAndWait
just to be on the safe side that "everything Swing should be executed on the EDT" but I guess I could drop it as no UI ever shown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that if we use invokeAndWait(), it needs to be headful..There are many test where we use invokeAndWait but they are headless. But it will be good to see what the test is doing visually so you probably can make it headful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, see if the option I've added to save an image capture of the editor component appears sufficient for the visual inspection.
* property values, Cascading, and Inheritance</a> | ||
*/ | ||
static final Object FONT_SIZE_INHERIT = | ||
new CSS().new FontSize().parseCssValue("100%"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to instantiate new CSS object here? Can't we reuse "css" variable which is already initialized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hadn't previously realized the ViewAttributeSet
class is not static, so it should be possible to reuse the instance css
. Not sure if a separate instance per style sheet is necessary, but I'll prepare a revision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have now made it use the instance StyleSheet.css
variable.
- Renamed bug8257665.java -> TestWrongCSSFontSize.java - Added full copyright statement - Removed redundant @key headless - Corrected bug no. 8257665 -> 8257664
Providing a way to display the rendered HTML, especially when the test fails, for visual inspection could be a bonus. This feature could be activated with a parameter passed to the test. It's not a requirement, just a suggestion. |
test/jdk/javax/swing/text/html/StyleSheet/TestWrongCSSFontSize.java
Outdated
Show resolved
Hide resolved
- Correct test type/ctor name in main() - Add program option to save image capture of the editor
Init the "fontSizeInherit" value using the instance "StyleSheet.css".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
The test runs successfully on headless hosts in mach5.
As for the visual inspection, I thought about creating a frame with JEditorPane but saving an image is will also work on headless systems. That is to say, saving the image is even better.
src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
Outdated
Show resolved
Hide resolved
Declare fontSizeInherit() accessor private.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Internal testing is also ok.
However, I have one question, html text is honouring "font-size" value(say 1.5 as per testcase) but if Display resolution in windows system setting or via -Dsun.java2d.uiScale is set to something different(say 1.25), then should it honour the font-size property (1.5) or Display resolution (1.25)?
Shouldn't UI scaling be applied automatically? The font size in user space should remain the same, yet the actual font size would be scaled up according to the DPI setting. That is in my understanding, CSS rule applies 150% to the base font size according to its rules; then Does it make sense to run the test with different |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
@stanio 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:
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 443 new commits pushed to the
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 (@aivanov-jdk, @prsadhuk) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
The display dpi shouldn't matter. I've tried it in a couple of different monitor configurations: 1.25, 1.5, and 2.0 scaling. I've also tried it with non-dpi-aware Java 8. I've used Before I type |
Yes, your commits in the branch will be squashed into one commit in the upstream. I am ready to sponsor, I think @prsadhuk wouldn't mind to sponsor too. However, @prsadhuk hasn't approved it yet; I'd like to wait until he does so. Thank you @stanio for contributing the fix! |
OK. Good to know dpi factor is not affecting this usecase, but speaking of |
Thank you @prsadhuk for reviewing this. Should/could I go with |
yes sure |
/integrate |
/sponsor |
@aivanov-jdk @stanio Since your change was applied there have been 443 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 70b5b31. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Fix for JDK-8257664 – HTMLEditorKit: Wrong CSS relative font sizes.
Disclaimer: I'm the reporter of the issue and I've been advised the best chance to get it addressed is to submit a pull request against this repository. I haven't built the JDK myself, I'll need guidance if required. I have a proof-of-concept example – demonstrating the bug and a workaround available as a public gist. I have included a sample test though I don't know if it is annotated properly.
Current behavior
Expected behavior
All text should be displayed with a font size of the computed
<body>
font-size × 1.5.Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1759/head:pull/1759
$ git checkout pull/1759