JDK-8282772: JButton text set as HTML content has unwanted padding #8407
Conversation
…ttonUI insets. Edited HtmlButtonImageTest to cycle all L&Fs. Recreated this branch to fix sync issue.
|
👋 Welcome back DamonGuy! A progress list of the required criteria for merging this PR into |
Webrevs
|
| @@ -268,7 +268,7 @@ | |||
| </uiComponent> | |||
| <uiComponent opaque="false" type="javax.swing.JButton" name="Button" ui="ButtonUI" subregion="false"> | |||
| <stateTypes/> | |||
| <contentMargins top="6" bottom="6" left="14" right="14"/> | |||
| <contentMargins top="6" bottom="6" left="0" right="0"/> | |||
There was a problem hiding this comment.
I also tested for non-HTML text after the changes, and the changes do not affect normal text.
And this is true for this Nimbus case too ? Whereas your code update in BasicButtonUI is checking for HTML, I don't see how it could not change normal text in the Nimbus case.
There was a problem hiding this comment.
I thought the same thing. In the test, I forced the L&F to nimbus only and tested with the left and right insets set to 0 and 14. The text appears normally and identically for both cases (HTML text and non-HTML text). I also tried changing the size of the button from 37x37 to 100x100 and 200x200. The appearance was the same for all cases.
However, I just tried using different text from the tests before and I do get cases where text gets snipped to "..." when the new insets wouldn't. So, you're right that normal text is affected. I just used text that wasn't long enough in testing.
The reason I went this route for the fix was because in NimbusStyle, the insets are retrieved but the property key but the button component for BasicHTML is not set yet and returns null. So, I can't use this method to set the insets to 0 since the property key has not been set in the stack yet.
I finally found the applicable class of where to make the edits yesterday. I just made the changes similar to the other L&Fs.
|
@DamonGuy 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 293 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 (@prrace, @prsadhuk) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
| @@ -24,7 +24,6 @@ | |||
| /* | |||
| * @test | |||
| * @bug 8015854 | |||
| * @requires (os.family == "mac") | |||
| * @summary Tests HTML image as JButton text for unwanted padding on macOS Aqua LAF | |||
| * @run main HtmlButtonImageTest | |||
| */ | |||
There was a problem hiding this comment.
I believe you have run this test on CI systems on all platforms
There was a problem hiding this comment.
Thanks for catching that unedited summary. Fixed.
| paintViewR.y = insets.top; | ||
| paintViewR.width = c.getWidth() - (insets.left + insets.right); | ||
| paintViewR.height = c.getHeight() - (insets.top + insets.bottom); | ||
| final View v = (View)c.getClientProperty(BasicHTML.propertyKey); |
There was a problem hiding this comment.
I guess this issue is only for JButton so is it needed to apply this for all components or we need to put a check for c instance of JButton
There was a problem hiding this comment.
Wasn't completely sure if it was necessary to add the check since it passed without, meaning I wouldn't need to import JButton into this class. However, it does make sense to check for JButtons, so I made the change. Tested the change and everything still passes.
| @@ -110,6 +116,15 @@ private static void testImageCentering(int... colors) throws IOException { | |||
| throw new RuntimeException("HTML image not centered in button"); | |||
There was a problem hiding this comment.
overall looks ok. Only thing is during failure, it does not show for which L&F the test is failing since you are iterating for all L&Fs.
There was a problem hiding this comment.
Sure, this can be changed. I can instead iterate through all L&F's and track all failing L&F's in a buffer to be displayed in the runtime exception in the end. How should the images be handled? Should I just generate X images where X is the number of failed L&F's?
…w at the end of test.
|
/integrate |
|
/sponsor |
|
Going to push as commit ccbe8fa.
Your commit was automatically rebased without conflicts. |
openjdk
bot
removed
ready
|
This PR breaks correct text location when using HTML text in buttons. It works only if horizontal/vertical alignment is center and if using symmetric margin (top == bottom and left == right). And shouldn't text positioned the same for HTML and non-HTML buttons? Screenshot that demonstrates the problem.
Code used to create above screenshots: import java.awt.*;
import javax.swing.*;
import javax.swing.border.*;
public class HtmlButtonTest
{
public static void main( String[] args ) {
SwingUtilities.invokeLater( () -> {
JFrame frame = new JFrame( "HTML Button Test" );
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
JPanel panel = new JPanel( new GridBagLayout() );
panel.setBorder( new EmptyBorder( 20, 20, 20, 20 ) );
createButtons( panel, "center", SwingConstants.CENTER, SwingConstants.CENTER, null );
createButtons( panel, "left", SwingConstants.LEFT, SwingConstants.CENTER, null );
createButtons( panel, "right", SwingConstants.RIGHT, SwingConstants.CENTER, null );
createButtons( panel, "center with margin 30,4,4,4", SwingConstants.CENTER, SwingConstants.CENTER, new Insets( 30, 4, 4, 4 ) );
createButtons( panel, "left with margin 30,4,4,4", SwingConstants.LEFT, SwingConstants.CENTER, new Insets( 30, 4, 4, 4 ) );
createButtons( panel, "left/top with margin 30,4,4,4", SwingConstants.LEFT, SwingConstants.TOP, new Insets( 30, 4, 4, 4 ) );
frame.add( new JLabel( "Java version " + System.getProperty( "java.version" ) ), BorderLayout.NORTH );
frame.add( panel );
frame.pack();
frame.setVisible( true );
} );
}
private static void createButtons( JPanel panel, String text, int horizontalAlignment, int verticalAlignment, Insets margin ) {
JButton button = new JButton( text );
button.setHorizontalAlignment( horizontalAlignment );
button.setVerticalAlignment( verticalAlignment );
if( margin != null )
button.setMargin( margin );
panel.add( button, new GridBagConstraints( 0, GridBagConstraints.RELATIVE, 1, 1, 1.0, 0.0,
GridBagConstraints.CENTER, GridBagConstraints.HORIZONTAL, new Insets( 4, 4, 4, 4 ), 0, 0 ) );
JButton htmlButton = new JButton( "<html>HTML " + text + "</html>" );
htmlButton.setHorizontalAlignment( horizontalAlignment );
htmlButton.setVerticalAlignment( verticalAlignment );
if( margin != null )
htmlButton.setMargin( margin );
panel.add( htmlButton, new GridBagConstraints( 0, GridBagConstraints.RELATIVE, 1, 1, 1.0, 0.0,
GridBagConstraints.CENTER, GridBagConstraints.HORIZONTAL, new Insets( 4, 4, 24, 4 ), 0, 0 ) );
}
} |
|
BTW this PR also breaks 3rd party L&Fs like FlatLaf. |
|
I really wonder why the (10 year old) issue JDK-8015854 was accepted as bug. 😕 He sets the preferred size of the button to 30x30 and adds an HTML image to that button and expects that it is painted centered.
If the user reduces the preferred size, he also needs to reduce the margin. testButton.setMargin(new Insets(0, 0, 0, 0));
I would recommend to revert this PR and also PR #7310. |
|
Hi @DevCharly, I'll look into this. I see your point on how this sort of goes against expected behavior, knowing the margins are (2, 14, 2, 14). I can distinguish between HTML images and HTML text to resolve this issue somewhat for the unexpected padding, but I think reverting the PRs is also a valid solution. |
The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text.
The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/8407/head:pull/8407$ git checkout pull/8407Update a local copy of the PR:
$ git checkout pull/8407$ git pull https://git.openjdk.java.net/jdk pull/8407/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 8407View PR using the GUI difftool:
$ git pr show -t 8407Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/8407.diff