From Sergey.Bylokhov at oracle.com Thu May 2 12:01:54 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 May 2019 05:01:54 -0700 Subject: [13] Review Request: 8223237 Replace use of string.equals("") with isEmpty() in java.desktop Message-ID: <199db90a-9b16-60ed-c079-aec7c8655ee4@oracle.com> Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8223237 Fix: http://cr.openjdk.java.net/~serb/8223237/webrev.00 This change is an equivalent of JDK-8214971[1] but for the java.desktop module. - The string.equals("") replaced by the string.isEmpty() in all cases - The "".equals(string) replaced by the string.isEmpty() when string is non-null [1] https://bugs.openjdk.java.net/browse/JDK-8214971 In one case I dropped string.equals("") as unneeded: http://cr.openjdk.java.net/~serb/8223237/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java.udiff.html -- Best regards, Sergey. From philip.race at oracle.com Sat May 4 05:37:53 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 03 May 2019 22:37:53 -0700 Subject: [OpenJDK 2D-Dev] [13] Review Request: 8223237 Replace use of string.equals("") with isEmpty() in java.desktop In-Reply-To: <199db90a-9b16-60ed-c079-aec7c8655ee4@oracle.com> References: <199db90a-9b16-60ed-c079-aec7c8655ee4@oracle.com> Message-ID: <5CCD2531.3000707@oracle.com> I am not sure how important this clean up is but since you've done it .. replacing "".equals(foo) wth foo.isEmpty(() isn't equivalent but the cases I saw where you did are either foo == null || [!]foo.isEmpty() eg : - if (fontName == null || "".equals(fontName)) { + if (fontName == null || fontName.isEmpty()) { or foo != null && [!]foo.isEmpty() eg: - if(text != null && !text.equals("")) { + if(text != null && !text.isEmpty()) { so these should be fine. Although for the line above since you are touching it I'd like "if(" turned into "if (" Here's another one - if(!keyword.equals("")&& !value.equals("")) { + if(!keyword.isEmpty()&& !value.isEmpty()) { With those updates, +1 -phil On 5/2/19, 5:01 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223237 > Fix: http://cr.openjdk.java.net/~serb/8223237/webrev.00 > > This change is an equivalent of JDK-8214971[1] but for the > java.desktop module. > - The string.equals("") replaced by the string.isEmpty() in all cases > - The "".equals(string) replaced by the string.isEmpty() when string > is non-null > [1] https://bugs.openjdk.java.net/browse/JDK-8214971 > > > In one case I dropped string.equals("") as unneeded: > http://cr.openjdk.java.net/~serb/8223237/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java.udiff.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed May 15 18:31:34 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 15 May 2019 11:31:34 -0700 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: References: <255e2b65-5c71-94e1-c50c-63651f7834f7@oracle.com> <46318767-5fa9-62d8-01de-02f29313b8c9@oracle.com> <805e2c79-fd48-c73f-97b0-cd808e73d1b4@oracle.com> <5C4A9E59.1060908@oracle.com> <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> Message-ID: OK. Let's try that. I am sure it is still going to be non-ideal in a couple of ways 1) where printed is shorter than screenwidth and we don't adjust, there may be space after the text and before the "edge" of the component, but at least there's no clipping and the text should look natural initself 2) Where printed is longer than screenwidth and we do adjust we may still run into similar cases as this .. -phil. On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: > > > > On 18-Apr-19 12:31 AM, Phil Race wrote: >> >> >> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>> >>> Hi Phil, >>> >>> It seems screenWidth or "advance of the string at screen-resolution" >>> is 533 whereas string advance calculated using printer fontmetrics >>> is 503 >>> >>> Now, TextLine#getJustifiedLine() [called from >>> TextLayout.getJustifiedLayout] again calculates "justifyAdvance" for >>> TextLineComponent which comes out to be 503,then it calculates >>> the actual justification "delta" by subtracting justifyAdvance from >>> screenWidth which is 533-503=30 and it then does >>> TextJustifier.justify(delta) >>> which calculates the amount by which each side of each glyph should >>> grow or shrink. >>> >>> Then TextLine.getJustifiedLine() applies this value by calling >>> TextLineComponent.applyJustificationDeltas() where it >>> ?handle whitespace by modifying advance but? handle everything else >>> by modifying position before and after, >>> ?so "spaces" seem to grow in size resulting in shifting of text with >>> whitespaces. >> >> The spaces being used to add needed or absorb surplus space is what I >> understood the current code to be doing, >> >> However I am not sure what you mean by this :- >> "but? handle everything else by modifying position before and after," >> >> Code run through text layout will always have glyph positions >> assigned, so I would suppose modifying the position >> is how the spaces were handled too .. and of course this means >> running through all preceding glyphs to make >> it consistent .. and I thought it was only adjusting the spaces, so >> what is "everything else" > It seems when TextLineComponent.applyJustificationDeltas() is called, > ExtendedTextSourceLabel.applyJustificationDeltas() handles that > http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 > where it handles "whitespace" a bit different (if block) from other > glyph (else block) where advance is is not considered, which is also > conveyed? in the comment @1011 >>> >>> ?Since it was mentioned in TextLayout.getJustifiedLayout() that "? >>> For best results, justificationWidth should not be too different >>> from the current advance of the line" >> >> So for "best" results don't try to adjust a string that's 3 words and >> 80 pixels to a 500 pixel width. >> >>> I am proposing a fix to conditionally call >>> TextLayout.getJustifiedLayout() only if the difference between >>> justificationWidth and advance with for printer is more than 10. >>> >> >> I had proposed investigating what happens if you simply don't use >> justification when the text will fit. >> Maybe you are refining that but I am not sure about the details. >> 10 is one arbitrary number and is not proportional to the length - >> which is what I would be >> thinking about first in succh an approach >> And I am not even sure you mean what you say. >> You say "more" than 10, yet your code implements "less" than 10. > It was a typo in mail. > Modified? webrev to not use justification if string width of text is > within screenWidth > http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ > > Regards > Prasanta >> And moreover its an absolute value you are using, which re-introduces >> the clipping problem, doesn't it ? >> ie you are purely looking at the difference and it isn't what I has >> proposed and I thought you were trying. >> >> -phil >> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>> >>> Regards >>> Prasanta >>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>> >>>> >>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> Thanks Phil for review. So, you are doubting it will regress swing >>>>> printing tests. As you told earlier, I have ran the following >>>>> regression test with this fix >>>>> >>>> >>>> It may not regress a test if the test is not being tested under the >>>> same conditions for which it is created but I am telling you for a >>>> fact that the fix is wrong. screenWidth should be "width on the screen" >>>>> >>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug above is >>>>> covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>> and I did not notice any regression. Any other test we have for >>>>> swing printing that we can run? >>>>> >>>> >>>> No idea which tests will show this today but I know it is an issue. >>>> No way we can push this and then just wait for the complaints. >>>> >>>>> >>Previously we were using DEFAULT_FRC to make it a screen width >>>>> which except for maybe needing to be updated for hi-dpi screens is >>>>> what we want. >>>>> This issue was there from jdk1.6. If it is for hidpi screen, we >>>>> would have seen it from jdk9 onwards where we supported hidpi, no? >>>> >>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>> I think that should have been updated in 1.9 but was missed because >>>> it (hidpi for windows) was not a small or contained task. >>>> This is an ancilliary observation of something that should be looked >>>> at entirely independent of this bug. >>>> >>>> -phil. >>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>> The current fix confused me for a while as I could not see how it was >>>>>> at all different than the existing code, since I can't imagine >>>>>> when we'd >>>>>> ever take the "else" branch here : >>>>>> 533 TextLayout layout; >>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>> 536 } else { >>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>> 538 } Eventually when walking through it I noticed this 531 >>>>>> FontMetrics fm = g2d.getFontMetrics(); >>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm >>>>>> ,trimmedText); >>>>>> >>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER - ie >>>>>> the scaled FontRenderContext. >>>>>> It then uses this to calculate the advance width for such a case >>>>>> - ie the printer >>>>>> but then *assigns it to a variable called screenWidth*. >>>>>> >>>>>> Previously we were using DEFAULT_FRC to make it a screen width >>>>>> which except >>>>>> for maybe needing to be updated for hi-dpi screens is what we want. >>>>>> >>>>>> So in the updated proposed fix the wrong width is passed to? >>>>>> getJustifiedLayout(). >>>>>> >>>>>> This may not matter here because there is plenty of space, but in >>>>>> other cases >>>>>> Swing printing will be clipped as a result. And there were many, >>>>>> many, bug reports about >>>>>> that. Which is why the code is laying out to the screenwidth >>>>>> because that is where the >>>>>> UI component size available came from. Buttons & Label text are >>>>>> the typical cases where >>>>>> this showed up. >>>>>> >>>>>> There maybe other things to change, as well but the incorrect >>>>>> screenWidth is the >>>>>> main problem I see here. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> >>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> I believe drawChars() also has same printing issue [and should >>>>>>>>> be changed like modified drawString()] but I am not able to >>>>>>>>> test it as reproducer testcase uses JLabel whose constructor >>>>>>>>> can only accept "String" and not char[] so I can only test >>>>>>>>> drawString(). Using drawChars() implementation in drawString() >>>>>>>>> still reproduces the issue. >>>>>>>> >>>>>>>> Is it possible temporary replace the call to drawString() by >>>>>>>> the drawChars(), to check how drawChars() will work? >>>>>>> As I told, it behaves similarly to unmodified drawString and the >>>>>>> issue can still be seen. I think we should commit this >>>>>>> drawString() change in this fix and I can open another bug to >>>>>>> investigate drawChars() impl and reproducer. Will that be fine? >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> or probably we can implement drawChars() on top of drawString()? >>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Prasanta. >>>>>>>>>> >>>>>>>>>>> I modified the fix to use deviceFRC if not compatible and in >>>>>>>>>>> sync with the comment which says "obtain a TextLayout with >>>>>>>>>>> advances for the printer graphics FRC" >>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates the >>>>>>>>>>> advances of the string if text layouting is used. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>> >>>>>>>>>> Can you please take a look to the existed drawChars() method, >>>>>>>>>> which is implemented in the similar way as drawStringImpl() >>>>>>>>>> and new version of drawString(), but they have some small >>>>>>>>>> difference. Why we cannot use the same logic? >>>>>>>>>> >>>>>>>>>> For example in the drawChars: >>>>>>>>>> ========= >>>>>>>>>> ??????????? FontRenderContext deviceFontRenderContext = g2d. >>>>>>>>>> ??????????????? getFontRenderContext(); >>>>>>>>>> ??????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>> ??????????? if (frc != null && >>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>> ??????????????? (deviceFontRenderContext, frc)) { >>>>>>>>>> ???????????????? String text = new String(data, offset, length); >>>>>>>>>> ???????????????? TextLayout layout = new TextLayout(text, >>>>>>>>>> g2d.getFont(), >>>>>>>>>> deviceFontRenderContext); >>>>>>>>>> ???????????????? String trimmedText = trimTrailingSpaces(text); >>>>>>>>>> ???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>> ???????????????????? float screenWidth = (float)g2d.getFont(). >>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>> ???????????????????? layout = >>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>> >>>>>>>>>> ========== >>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>> >>>>>>>>>> ?524???????????????? FontRenderContext frc = >>>>>>>>>> getFontRenderContext(c); >>>>>>>>>> ?525???????????????? if (frc.isAntiAliased() || >>>>>>>>>> frc.usesFractionalMetrics()) { >>>>>>>>>> ?526???????????????????? frc = new >>>>>>>>>> FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>> ?527???????????????? } >>>>>>>>>> ?528???????????????? FontRenderContext deviceFRC = >>>>>>>>>> g2d.getFontRenderContext(); >>>>>>>>>> ?529???????????????? String trimmedText = >>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>> ?530???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>> ?531???????????????????? FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>> ?532???????????????????? float screenWidth = >>>>>>>>>> SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>> ?533???????????????????? TextLayout layout; >>>>>>>>>> ?534???????????????????? if >>>>>>>>>> (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>> ?535???????????????????????? layout = createTextLayout(c, >>>>>>>>>> text, g2d.getFont(), deviceFRC); >>>>>>>>>> ?536???????????????????? } else { >>>>>>>>>> ?537???????????????????????? layout = createTextLayout(c, >>>>>>>>>> text, g2d.getFont(), frc); >>>>>>>>>> ?538???????????????????? } >>>>>>>>>> ?540???????????????????? layout = >>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu May 16 05:23:35 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 16 May 2019 10:53:35 +0530 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: References: <46318767-5fa9-62d8-01de-02f29313b8c9@oracle.com> <805e2c79-fd48-c73f-97b0-cd808e73d1b4@oracle.com> <5C4A9E59.1060908@oracle.com> <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> Message-ID: Not sure if you are saying it's ok to "push"? I guess I need a 2nd reviewer if you are ok with this. Regards Prasanta On 16-May-19 12:01 AM, Phil Race wrote: > OK. Let's try that. I am sure it is still going to be non-ideal in a > couple of ways > 1) where printed is shorter than screenwidth and we don't adjust, > there may > be space after the text and before the "edge" of the component, but at > least > there's no clipping and the text should look natural initself > > 2) Where printed is longer than screenwidth and we do adjust we may still > run into similar cases as this .. > > -phil. > > On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: >> >> >> >> On 18-Apr-19 12:31 AM, Phil Race wrote: >>> >>> >>> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>>> >>>> Hi Phil, >>>> >>>> It seems screenWidth or "advance of the string at >>>> screen-resolution" is 533 whereas string advance calculated using >>>> printer fontmetrics is 503 >>>> >>>> Now, TextLine#getJustifiedLine() [called from >>>> TextLayout.getJustifiedLayout] again calculates "justifyAdvance" >>>> for TextLineComponent which comes out to be 503,then it calculates >>>> the actual justification "delta" by subtracting justifyAdvance from >>>> screenWidth which is 533-503=30 and it then does >>>> TextJustifier.justify(delta) >>>> which calculates the amount by which each side of each glyph should >>>> grow or shrink. >>>> >>>> Then TextLine.getJustifiedLine() applies this value by calling >>>> TextLineComponent.applyJustificationDeltas() where it >>>> ?handle whitespace by modifying advance but? handle everything else >>>> by modifying position before and after, >>>> ?so "spaces" seem to grow in size resulting in shifting of text >>>> with whitespaces. >>> >>> The spaces being used to add needed or absorb surplus space is what >>> I understood the current code to be doing, >>> >>> However I am not sure what you mean by this :- >>> "but? handle everything else by modifying position before and after," >>> >>> Code run through text layout will always have glyph positions >>> assigned, so I would suppose modifying the position >>> is how the spaces were handled too .. and of course this means >>> running through all preceding glyphs to make >>> it consistent .. and I thought it was only adjusting the spaces, so >>> what is "everything else" >> It seems when TextLineComponent.applyJustificationDeltas() is called, >> ExtendedTextSourceLabel.applyJustificationDeltas() handles that >> http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 >> where it handles "whitespace" a bit different (if block) from other >> glyph (else block) where advance is is not considered, which is also >> conveyed? in the comment @1011 >>>> >>>> ?Since it was mentioned in TextLayout.getJustifiedLayout() that "? >>>> For best results, justificationWidth should not be too different >>>> from the current advance of the line" >>> >>> So for "best" results don't try to adjust a string that's 3 words >>> and 80 pixels to a 500 pixel width. >>> >>>> I am proposing a fix to conditionally call >>>> TextLayout.getJustifiedLayout() only if the difference between >>>> justificationWidth and advance with for printer is more than 10. >>>> >>> >>> I had proposed investigating what happens if you simply don't use >>> justification when the text will fit. >>> Maybe you are refining that but I am not sure about the details. >>> 10 is one arbitrary number and is not proportional to the length - >>> which is what I would be >>> thinking about first in succh an approach >>> And I am not even sure you mean what you say. >>> You say "more" than 10, yet your code implements "less" than 10. >> It was a typo in mail. >> Modified? webrev to not use justification if string width of text is >> within screenWidth >> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ >> >> Regards >> Prasanta >>> And moreover its an absolute value you are using, which >>> re-introduces the clipping problem, doesn't it ? >>> ie you are purely looking at the difference and it isn't what I has >>> proposed and I thought you were trying. >>> >>> -phil >>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>>> >>>> Regards >>>> Prasanta >>>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>>> >>>>> >>>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Thanks Phil for review. So, you are doubting it will regress >>>>>> swing printing tests. As you told earlier, I have ran the >>>>>> following regression test with this fix >>>>>> >>>>> >>>>> It may not regress a test if the test is not being tested under the >>>>> same conditions for which it is created but I am telling you for a >>>>> fact that the fix is wrong. screenWidth should be "width on the >>>>> screen" >>>>>> >>>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug above >>>>>> is covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>>> and I did not notice any regression. Any other test we have for >>>>>> swing printing that we can run? >>>>>> >>>>> >>>>> No idea which tests will show this today but I know it is an issue. >>>>> No way we can push this and then just wait for the complaints. >>>>> >>>>>> >>Previously we were using DEFAULT_FRC to make it a screen width >>>>>> which except for maybe needing to be updated for hi-dpi screens >>>>>> is what we want. >>>>>> This issue was there from jdk1.6. If it is for hidpi screen, we >>>>>> would have seen it from jdk9 onwards where we supported hidpi, no? >>>>> >>>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>>> I think that should have been updated in 1.9 but was missed because >>>>> it (hidpi for windows) was not a small or contained task. >>>>> This is an ancilliary observation of something that should be looked >>>>> at entirely independent of this bug. >>>>> >>>>> -phil. >>>>> >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>>> The current fix confused me for a while as I could not see how >>>>>>> it was >>>>>>> at all different than the existing code, since I can't imagine >>>>>>> when we'd >>>>>>> ever take the "else" branch here : >>>>>>> 533 TextLayout layout; >>>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>> 536 } else { >>>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>> 538 } Eventually when walking through it I noticed this 531 >>>>>>> FontMetrics fm = g2d.getFontMetrics(); >>>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm >>>>>>> ,trimmedText); >>>>>>> >>>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER - >>>>>>> ie the scaled FontRenderContext. >>>>>>> It then uses this to calculate the advance width for such a case >>>>>>> - ie the printer >>>>>>> but then *assigns it to a variable called screenWidth*. >>>>>>> >>>>>>> Previously we were using DEFAULT_FRC to make it a screen width >>>>>>> which except >>>>>>> for maybe needing to be updated for hi-dpi screens is what we want. >>>>>>> >>>>>>> So in the updated proposed fix the wrong width is passed to? >>>>>>> getJustifiedLayout(). >>>>>>> >>>>>>> This may not matter here because there is plenty of space, but >>>>>>> in other cases >>>>>>> Swing printing will be clipped as a result. And there were many, >>>>>>> many, bug reports about >>>>>>> that. Which is why the code is laying out to the screenwidth >>>>>>> because that is where the >>>>>>> UI component size available came from. Buttons & Label text are >>>>>>> the typical cases where >>>>>>> this showed up. >>>>>>> >>>>>>> There maybe other things to change, as well but the incorrect >>>>>>> screenWidth is the >>>>>>> main problem I see here. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi Sergey, >>>>>>>>>> >>>>>>>>>> I believe drawChars() also has same printing issue [and >>>>>>>>>> should be changed like modified drawString()] but I am not >>>>>>>>>> able to test it as reproducer testcase uses JLabel whose >>>>>>>>>> constructor can only accept "String" and not char[] so I can >>>>>>>>>> only test drawString(). Using drawChars() implementation in >>>>>>>>>> drawString() still reproduces the issue. >>>>>>>>> >>>>>>>>> Is it possible temporary replace the call to drawString() by >>>>>>>>> the drawChars(), to check how drawChars() will work? >>>>>>>> As I told, it behaves similarly to unmodified drawString and >>>>>>>> the issue can still be seen. I think we should commit this >>>>>>>> drawString() change in this fix and I can open another bug to >>>>>>>> investigate drawChars() impl and reproducer. Will that be fine? >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> or probably we can implement drawChars() on top of drawString()? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>> >>>>>>>>>>>> I modified the fix to use deviceFRC if not compatible and >>>>>>>>>>>> in sync with the comment which says "obtain a TextLayout >>>>>>>>>>>> with advances for the printer graphics FRC" >>>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates the >>>>>>>>>>>> advances of the string if text layouting is used. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>>> >>>>>>>>>>> Can you please take a look to the existed drawChars() >>>>>>>>>>> method, which is implemented in the similar way as >>>>>>>>>>> drawStringImpl() and new version of drawString(), but they >>>>>>>>>>> have some small difference. Why we cannot use the same logic? >>>>>>>>>>> >>>>>>>>>>> For example in the drawChars: >>>>>>>>>>> ========= >>>>>>>>>>> ??????????? FontRenderContext deviceFontRenderContext = g2d. >>>>>>>>>>> ??????????????? getFontRenderContext(); >>>>>>>>>>> ??????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>>> ??????????? if (frc != null && >>>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>>> ??????????????? (deviceFontRenderContext, frc)) { >>>>>>>>>>> ???????????????? String text = new String(data, offset, >>>>>>>>>>> length); >>>>>>>>>>> ???????????????? TextLayout layout = new TextLayout(text, >>>>>>>>>>> g2d.getFont(), >>>>>>>>>>> deviceFontRenderContext); >>>>>>>>>>> ???????????????? String trimmedText = trimTrailingSpaces(text); >>>>>>>>>>> ???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>> ???????????????????? float screenWidth = (float)g2d.getFont(). >>>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>>> ???????????????????? layout = >>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>> >>>>>>>>>>> ========== >>>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>>> >>>>>>>>>>> ?524???????????????? FontRenderContext frc = >>>>>>>>>>> getFontRenderContext(c); >>>>>>>>>>> ?525???????????????? if (frc.isAntiAliased() || >>>>>>>>>>> frc.usesFractionalMetrics()) { >>>>>>>>>>> ?526???????????????????? frc = new >>>>>>>>>>> FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>>> ?527???????????????? } >>>>>>>>>>> ?528???????????????? FontRenderContext deviceFRC = >>>>>>>>>>> g2d.getFontRenderContext(); >>>>>>>>>>> ?529???????????????? String trimmedText = >>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>> ?530???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>> ?531???????????????????? FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>>> ?532???????????????????? float screenWidth = >>>>>>>>>>> SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>>> ?533???????????????????? TextLayout layout; >>>>>>>>>>> ?534???????????????????? if >>>>>>>>>>> (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>> ?535???????????????????????? layout = createTextLayout(c, >>>>>>>>>>> text, g2d.getFont(), deviceFRC); >>>>>>>>>>> ?536???????????????????? } else { >>>>>>>>>>> ?537???????????????????????? layout = createTextLayout(c, >>>>>>>>>>> text, g2d.getFont(), frc); >>>>>>>>>>> ?538???????????????????? } >>>>>>>>>>> ?540???????????????????? layout = >>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 16 15:43:03 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 May 2019 08:43:03 -0700 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: References: <805e2c79-fd48-c73f-97b0-cd808e73d1b4@oracle.com> <5C4A9E59.1060908@oracle.com> <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> Message-ID: <74c9e459-1b84-2bad-5c1a-c8dd944a7fdd@oracle.com> Hi, Prasanta. Should not we use the real "screen" FontRenderContext instead of "DEFAULT_FRC"? Did you check do we need to update the similat cases in the same class(we use getJustifiedLayout() 4 times mostly in the same code pattern)? On 15/05/2019 22:23, Prasanta Sadhukhan wrote: > Not sure if you are saying it's ok to "push"? I guess I need a 2nd reviewer if you are ok with this. > > Regards > Prasanta > On 16-May-19 12:01 AM, Phil Race wrote: >> OK. Let's try that. I am sure it is still going to be non-ideal in a couple of ways >> 1) where printed is shorter than screenwidth and we don't adjust, there may >> be space after the text and before the "edge" of the component, but at least >> there's no clipping and the text should look natural initself >> >> 2) Where printed is longer than screenwidth and we do adjust we may still >> run into similar cases as this .. >> >> -phil. >> >> On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: >>> >>> >>> >>> On 18-Apr-19 12:31 AM, Phil Race wrote: >>>> >>>> >>>> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi Phil, >>>>> >>>>> It seems screenWidth or "advance of the string at screen-resolution" is 533 whereas string advance calculated using printer fontmetrics is 503 >>>>> >>>>> Now, TextLine#getJustifiedLine() [called from TextLayout.getJustifiedLayout] again calculates "justifyAdvance" for TextLineComponent which comes out to be 503,then it calculates >>>>> the actual justification "delta" by subtracting justifyAdvance from screenWidth which is 533-503=30 and it then does TextJustifier.justify(delta) >>>>> which calculates the amount by which each side of each glyph should grow or shrink. >>>>> >>>>> Then TextLine.getJustifiedLine() applies this value by calling TextLineComponent.applyJustificationDeltas() where it >>>>> ?handle whitespace by modifying advance but? handle everything else by modifying position before and after, >>>>> ?so "spaces" seem to grow in size resulting in shifting of text with whitespaces. >>>> >>>> The spaces being used to add needed or absorb surplus space is what I understood the current code to be doing, >>>> >>>> However I am not sure what you mean by this :- >>>> "but? handle everything else by modifying position before and after," >>>> >>>> Code run through text layout will always have glyph positions assigned, so I would suppose modifying the position >>>> is how the spaces were handled too .. and of course this means running through all preceding glyphs to make >>>> it consistent .. and I thought it was only adjusting the spaces, so what is "everything else" >>> It seems when TextLineComponent.applyJustificationDeltas() is called, ExtendedTextSourceLabel.applyJustificationDeltas() handles that >>> http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 >>> where it handles "whitespace" a bit different (if block) from other glyph (else block) where advance is is not considered, which is also conveyed? in the comment @1011 >>>>> >>>>> ?Since it was mentioned in TextLayout.getJustifiedLayout() that "? For best results, justificationWidth should not be too different from the current advance of the line" >>>> >>>> So for "best" results don't try to adjust a string that's 3 words and 80 pixels to a 500 pixel width. >>>> >>>>> I am proposing a fix to conditionally call TextLayout.getJustifiedLayout() only if the difference between justificationWidth and advance with for printer is more than 10. >>>>> >>>> >>>> I had proposed investigating what happens if you simply don't use justification when the text will fit. >>>> Maybe you are refining that but I am not sure about the details. >>>> 10 is one arbitrary number and is not proportional to the length - which is what I would be >>>> thinking about first in succh an approach >>>> And I am not even sure you mean what you say. >>>> You say "more" than 10, yet your code implements "less" than 10. >>> It was a typo in mail. >>> Modified? webrev to not use justification if string width of text is within screenWidth >>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ >>> >>> Regards >>> Prasanta >>>> And moreover its an absolute value you are using, which re-introduces the clipping problem, doesn't it ? >>>> ie you are purely looking at the difference and it isn't what I has proposed and I thought you were trying. >>>> >>>> -phil >>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>>>> >>>>>> >>>>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> Thanks Phil for review. So, you are doubting it will regress swing printing tests. As you told earlier, I have ran the following regression test with this fix >>>>>>> >>>>>> >>>>>> It may not regress a test if the test is not being tested under the >>>>>> same conditions for which it is created but I am telling you for a >>>>>> fact that the fix is wrong. screenWidth should be "width on the screen" >>>>>>> >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug above is covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>>>> and I did not notice any regression. Any other test we have for swing printing that we can run? >>>>>>> >>>>>> >>>>>> No idea which tests will show this today but I know it is an issue. >>>>>> No way we can push this and then just wait for the complaints. >>>>>> >>>>>>> >>Previously we were using DEFAULT_FRC to make it a screen width which except for maybe needing to be updated for hi-dpi screens is what we want. >>>>>>> This issue was there from jdk1.6. If it is for hidpi screen, we would have seen it from jdk9 onwards where we supported hidpi, no? >>>>>> >>>>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>>>> I think that should have been updated in 1.9 but was missed because >>>>>> it (hidpi for windows) was not a small or contained task. >>>>>> This is an ancilliary observation of something that should be looked >>>>>> at entirely independent of this bug. >>>>>> >>>>>> -phil. >>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>>>> The current fix confused me for a while as I could not see how it was >>>>>>>> at all different than the existing code, since I can't imagine when we'd >>>>>>>> ever take the "else" branch here : >>>>>>>> 533 TextLayout layout; >>>>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>> 536 } else { >>>>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>> 538 } Eventually when walking through it I noticed this 531 FontMetrics fm = g2d.getFontMetrics(); >>>>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>> >>>>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER - ie the scaled FontRenderContext. >>>>>>>> It then uses this to calculate the advance width for such a case - ie the printer >>>>>>>> but then *assigns it to a variable called screenWidth*. >>>>>>>> >>>>>>>> Previously we were using DEFAULT_FRC to make it a screen width which except >>>>>>>> for maybe needing to be updated for hi-dpi screens is what we want. >>>>>>>> >>>>>>>> So in the updated proposed fix the wrong width is passed to? getJustifiedLayout(). >>>>>>>> >>>>>>>> This may not matter here because there is plenty of space, but in other cases >>>>>>>> Swing printing will be clipped as a result. And there were many, many, bug reports about >>>>>>>> that. Which is why the code is laying out to the screenwidth because that is where the >>>>>>>> UI component size available came from. Buttons & Label text are the typical cases where >>>>>>>> this showed up. >>>>>>>> >>>>>>>> There maybe other things to change, as well but the incorrect screenWidth is the >>>>>>>> main problem I see here. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>>>> Hi Sergey, >>>>>>>>>>> >>>>>>>>>>> I believe drawChars() also has same printing issue [and should be changed like modified drawString()] but I am not able to test it as reproducer testcase uses JLabel whose constructor can only accept "String" and not char[] so I can only test drawString(). Using drawChars() implementation in drawString() still reproduces the issue. >>>>>>>>>> >>>>>>>>>> Is it possible temporary replace the call to drawString() by the drawChars(), to check how drawChars() will work? >>>>>>>>> As I told, it behaves similarly to unmodified drawString and the issue can still be seen. I think we should commit this drawString() change in this fix and I can open another bug to investigate drawChars() impl and reproducer. Will that be fine? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> or probably we can implement drawChars() on top of drawString()? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>> >>>>>>>>>>>>> I modified the fix to use deviceFRC if not compatible and in sync with the comment which says "obtain a TextLayout with advances for the printer graphics FRC" >>>>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates the advances of the string if text layouting is used. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>>>> >>>>>>>>>>>> Can you please take a look to the existed drawChars() method, which is implemented in the similar way as drawStringImpl() and new version of drawString(), but they have some small difference. Why we cannot use the same logic? >>>>>>>>>>>> >>>>>>>>>>>> For example in the drawChars: >>>>>>>>>>>> ========= >>>>>>>>>>>> ??????????? FontRenderContext deviceFontRenderContext = g2d. >>>>>>>>>>>> ??????????????? getFontRenderContext(); >>>>>>>>>>>> ??????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>>>> ??????????? if (frc != null && >>>>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>>>> ??????????????? (deviceFontRenderContext, frc)) { >>>>>>>>>>>> ???????????????? String text = new String(data, offset, length); >>>>>>>>>>>> ???????????????? TextLayout layout = new TextLayout(text, g2d.getFont(), >>>>>>>>>>>> deviceFontRenderContext); >>>>>>>>>>>> ???????????????? String trimmedText = trimTrailingSpaces(text); >>>>>>>>>>>> ???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>> ???????????????????? float screenWidth = (float)g2d.getFont(). >>>>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>>>> ???????????????????? layout = layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>> >>>>>>>>>>>> ========== >>>>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>>>> >>>>>>>>>>>> ?524???????????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>>>> ?525???????????????? if (frc.isAntiAliased() || frc.usesFractionalMetrics()) { >>>>>>>>>>>> ?526???????????????????? frc = new FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>>>> ?527???????????????? } >>>>>>>>>>>> ?528???????????????? FontRenderContext deviceFRC = g2d.getFontRenderContext(); >>>>>>>>>>>> ?529???????????????? String trimmedText = trimTrailingSpaces(text); >>>>>>>>>>>> ?530???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>> ?531???????????????????? FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>>>> ?532???????????????????? float screenWidth = SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>>>> ?533???????????????????? TextLayout layout; >>>>>>>>>>>> ?534???????????????????? if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>>> ?535???????????????????????? layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>>>>>> ?536???????????????????? } else { >>>>>>>>>>>> ?537???????????????????????? layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>>>> ?538???????????????????? } >>>>>>>>>>>> ?540???????????????????? layout = layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri May 17 05:05:45 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 17 May 2019 10:35:45 +0530 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: <74c9e459-1b84-2bad-5c1a-c8dd944a7fdd@oracle.com> References: <5C4A9E59.1060908@oracle.com> <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> <74c9e459-1b84-2bad-5c1a-c8dd944a7fdd@oracle.com> Message-ID: <9b63748a-f815-dad5-92f1-e12d53565a1a@oracle.com> Hi Sergey, On 16-May-19 9:13 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > Should not we use the real "screen" FontRenderContext instead of > "DEFAULT_FRC"? Yes, I guess it was mentioned in one of the review comment earliter, that it may not be the cause of this problem, but it needs to be changed. > Did you check do we need to update the similat cases in the same > class(we use getJustifiedLayout() 4 times mostly in the same code > pattern)? Might as well. I updated 3 of them and the 4th one is with AttributeCharaterIterator (and not dealing with String as such unlike other 3) so did not update. Modified webrev with the change http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.5/ Regards Prasanta > > On 15/05/2019 22:23, Prasanta Sadhukhan wrote: >> Not sure if you are saying it's ok to "push"? I guess I need a 2nd >> reviewer if you are ok with this. >> >> Regards >> Prasanta >> On 16-May-19 12:01 AM, Phil Race wrote: >>> OK. Let's try that. I am sure it is still going to be non-ideal in a >>> couple of ways >>> 1) where printed is shorter than screenwidth and we don't adjust, >>> there may >>> be space after the text and before the "edge" of the component, but >>> at least >>> there's no clipping and the text should look natural initself >>> >>> 2) Where printed is longer than screenwidth and we do adjust we may >>> still >>> run into similar cases as this .. >>> >>> -phil. >>> >>> On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> >>>> On 18-Apr-19 12:31 AM, Phil Race wrote: >>>>> >>>>> >>>>> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi Phil, >>>>>> >>>>>> It seems screenWidth or "advance of the string at >>>>>> screen-resolution" is 533 whereas string advance calculated using >>>>>> printer fontmetrics is 503 >>>>>> >>>>>> Now, TextLine#getJustifiedLine() [called from >>>>>> TextLayout.getJustifiedLayout] again calculates "justifyAdvance" >>>>>> for TextLineComponent which comes out to be 503,then it calculates >>>>>> the actual justification "delta" by subtracting justifyAdvance >>>>>> from screenWidth which is 533-503=30 and it then does >>>>>> TextJustifier.justify(delta) >>>>>> which calculates the amount by which each side of each glyph >>>>>> should grow or shrink. >>>>>> >>>>>> Then TextLine.getJustifiedLine() applies this value by calling >>>>>> TextLineComponent.applyJustificationDeltas() where it >>>>>> ?handle whitespace by modifying advance but? handle everything >>>>>> else by modifying position before and after, >>>>>> ?so "spaces" seem to grow in size resulting in shifting of text >>>>>> with whitespaces. >>>>> >>>>> The spaces being used to add needed or absorb surplus space is >>>>> what I understood the current code to be doing, >>>>> >>>>> However I am not sure what you mean by this :- >>>>> "but? handle everything else by modifying position before and after," >>>>> >>>>> Code run through text layout will always have glyph positions >>>>> assigned, so I would suppose modifying the position >>>>> is how the spaces were handled too .. and of course this means >>>>> running through all preceding glyphs to make >>>>> it consistent .. and I thought it was only adjusting the spaces, >>>>> so what is "everything else" >>>> It seems when TextLineComponent.applyJustificationDeltas() is >>>> called, ExtendedTextSourceLabel.applyJustificationDeltas() handles >>>> that >>>> http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 >>>> >>>> where it handles "whitespace" a bit different (if block) from other >>>> glyph (else block) where advance is is not considered, which is >>>> also conveyed? in the comment @1011 >>>>>> >>>>>> ?Since it was mentioned in TextLayout.getJustifiedLayout() that >>>>>> "? For best results, justificationWidth should not be too >>>>>> different from the current advance of the line" >>>>> >>>>> So for "best" results don't try to adjust a string that's 3 words >>>>> and 80 pixels to a 500 pixel width. >>>>> >>>>>> I am proposing a fix to conditionally call >>>>>> TextLayout.getJustifiedLayout() only if the difference between >>>>>> justificationWidth and advance with for printer is more than 10. >>>>>> >>>>> >>>>> I had proposed investigating what happens if you simply don't use >>>>> justification when the text will fit. >>>>> Maybe you are refining that but I am not sure about the details. >>>>> 10 is one arbitrary number and is not proportional to the length - >>>>> which is what I would be >>>>> thinking about first in succh an approach >>>>> And I am not even sure you mean what you say. >>>>> You say "more" than 10, yet your code implements "less" than 10. >>>> It was a typo in mail. >>>> Modified? webrev to not use justification if string width of text >>>> is within screenWidth >>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ >>>> >>>> Regards >>>> Prasanta >>>>> And moreover its an absolute value you are using, which >>>>> re-introduces the clipping problem, doesn't it ? >>>>> ie you are purely looking at the difference and it isn't what I >>>>> has proposed and I thought you were trying. >>>>> >>>>> -phil >>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>>>>> >>>>>>> >>>>>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> Thanks Phil for review. So, you are doubting it will regress >>>>>>>> swing printing tests. As you told earlier, I have ran the >>>>>>>> following regression test with this fix >>>>>>>> >>>>>>> >>>>>>> It may not regress a test if the test is not being tested under the >>>>>>> same conditions for which it is created but I am telling you for a >>>>>>> fact that the fix is wrong. screenWidth should be "width on the >>>>>>> screen" >>>>>>>> >>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug above >>>>>>>> is covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>>>>> and I did not notice any regression. Any other test we have for >>>>>>>> swing printing that we can run? >>>>>>>> >>>>>>> >>>>>>> No idea which tests will show this today but I know it is an issue. >>>>>>> No way we can push this and then just wait for the complaints. >>>>>>> >>>>>>>> >>Previously we were using DEFAULT_FRC to make it a screen >>>>>>>> width which except for maybe needing to be updated for hi-dpi >>>>>>>> screens is what we want. >>>>>>>> This issue was there from jdk1.6. If it is for hidpi screen, we >>>>>>>> would have seen it from jdk9 onwards where we supported hidpi, no? >>>>>>> >>>>>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>>>>> I think that should have been updated in 1.9 but was missed because >>>>>>> it (hidpi for windows) was not a small or contained task. >>>>>>> This is an ancilliary observation of something that should be >>>>>>> looked >>>>>>> at entirely independent of this bug. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>>>>> The current fix confused me for a while as I could not see how >>>>>>>>> it was >>>>>>>>> at all different than the existing code, since I can't imagine >>>>>>>>> when we'd >>>>>>>>> ever take the "else" branch here : >>>>>>>>> 533 TextLayout layout; >>>>>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>>> 536 } else { >>>>>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>> 538 } Eventually when walking through it I noticed this 531 >>>>>>>>> FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm >>>>>>>>> ,trimmedText); >>>>>>>>> >>>>>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER - >>>>>>>>> ie the scaled FontRenderContext. >>>>>>>>> It then uses this to calculate the advance width for such a >>>>>>>>> case - ie the printer >>>>>>>>> but then *assigns it to a variable called screenWidth*. >>>>>>>>> >>>>>>>>> Previously we were using DEFAULT_FRC to make it a screen width >>>>>>>>> which except >>>>>>>>> for maybe needing to be updated for hi-dpi screens is what we >>>>>>>>> want. >>>>>>>>> >>>>>>>>> So in the updated proposed fix the wrong width is passed to? >>>>>>>>> getJustifiedLayout(). >>>>>>>>> >>>>>>>>> This may not matter here because there is plenty of space, but >>>>>>>>> in other cases >>>>>>>>> Swing printing will be clipped as a result. And there were >>>>>>>>> many, many, bug reports about >>>>>>>>> that. Which is why the code is laying out to the screenwidth >>>>>>>>> because that is where the >>>>>>>>> UI component size available came from. Buttons & Label text >>>>>>>>> are the typical cases where >>>>>>>>> this showed up. >>>>>>>>> >>>>>>>>> There maybe other things to change, as well but the incorrect >>>>>>>>> screenWidth is the >>>>>>>>> main problem I see here. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>> >>>>>>>>>>>> I believe drawChars() also has same printing issue [and >>>>>>>>>>>> should be changed like modified drawString()] but I am not >>>>>>>>>>>> able to test it as reproducer testcase uses JLabel whose >>>>>>>>>>>> constructor can only accept "String" and not char[] so I >>>>>>>>>>>> can only test drawString(). Using drawChars() >>>>>>>>>>>> implementation in drawString() still reproduces the issue. >>>>>>>>>>> >>>>>>>>>>> Is it possible temporary replace the call to drawString() by >>>>>>>>>>> the drawChars(), to check how drawChars() will work? >>>>>>>>>> As I told, it behaves similarly to unmodified drawString and >>>>>>>>>> the issue can still be seen. I think we should commit this >>>>>>>>>> drawString() change in this fix and I can open another bug to >>>>>>>>>> investigate drawChars() impl and reproducer. Will that be fine? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>>> or probably we can implement drawChars() on top of >>>>>>>>>>> drawString()? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>> >>>>>>>>>>>>>> I modified the fix to use deviceFRC if not compatible and >>>>>>>>>>>>>> in sync with the comment which says "obtain a TextLayout >>>>>>>>>>>>>> with advances for the printer graphics FRC" >>>>>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates >>>>>>>>>>>>>> the advances of the string if text layouting is used. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please take a look to the existed drawChars() >>>>>>>>>>>>> method, which is implemented in the similar way as >>>>>>>>>>>>> drawStringImpl() and new version of drawString(), but they >>>>>>>>>>>>> have some small difference. Why we cannot use the same logic? >>>>>>>>>>>>> >>>>>>>>>>>>> For example in the drawChars: >>>>>>>>>>>>> ========= >>>>>>>>>>>>> ??????????? FontRenderContext deviceFontRenderContext = g2d. >>>>>>>>>>>>> ??????????????? getFontRenderContext(); >>>>>>>>>>>>> ??????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>>>>> ??????????? if (frc != null && >>>>>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>>>>> ??????????????? (deviceFontRenderContext, frc)) { >>>>>>>>>>>>> ???????????????? String text = new String(data, offset, >>>>>>>>>>>>> length); >>>>>>>>>>>>> ???????????????? TextLayout layout = new TextLayout(text, >>>>>>>>>>>>> g2d.getFont(), >>>>>>>>>>>>> deviceFontRenderContext); >>>>>>>>>>>>> ???????????????? String trimmedText = >>>>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>>>> ???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>>> ???????????????????? float screenWidth = >>>>>>>>>>>>> (float)g2d.getFont(). >>>>>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>>>>> ???????????????????? layout = >>>>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>> >>>>>>>>>>>>> ========== >>>>>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>>>>> >>>>>>>>>>>>> ?524???????????????? FontRenderContext frc = >>>>>>>>>>>>> getFontRenderContext(c); >>>>>>>>>>>>> ?525???????????????? if (frc.isAntiAliased() || >>>>>>>>>>>>> frc.usesFractionalMetrics()) { >>>>>>>>>>>>> ?526???????????????????? frc = new >>>>>>>>>>>>> FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>>>>> ?527???????????????? } >>>>>>>>>>>>> ?528???????????????? FontRenderContext deviceFRC = >>>>>>>>>>>>> g2d.getFontRenderContext(); >>>>>>>>>>>>> ?529???????????????? String trimmedText = >>>>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>>>> ?530???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>>> ?531???????????????????? FontMetrics fm = >>>>>>>>>>>>> g2d.getFontMetrics(); >>>>>>>>>>>>> ?532???????????????????? float screenWidth = >>>>>>>>>>>>> SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>>>>> ?533???????????????????? TextLayout layout; >>>>>>>>>>>>> ?534???????????????????? if >>>>>>>>>>>>> (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>>>> ?535???????????????????????? layout = createTextLayout(c, >>>>>>>>>>>>> text, g2d.getFont(), deviceFRC); >>>>>>>>>>>>> ?536???????????????????? } else { >>>>>>>>>>>>> ?537???????????????????????? layout = createTextLayout(c, >>>>>>>>>>>>> text, g2d.getFont(), frc); >>>>>>>>>>>>> ?538???????????????????? } >>>>>>>>>>>>> ?540???????????????????? layout = >>>>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > > From prasanta.sadhukhan at oracle.com Mon May 20 09:49:50 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 May 2019 15:19:50 +0530 Subject: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame In-Reply-To: <142c8228-8abe-8d75-4323-4bcbd1efeab3@oracle.com> References: <22a77e7c-4d6e-d300-6412-7a032a9e4258@oracle.com> <440dc24e-b011-35af-a6b1-86d036334070@oracle.com> <2278bf48-ff56-1775-1652-fff040e6edce@oracle.com> <641d40c7-7db6-bbcf-653e-a2513c6e57a3@oracle.com> <837dc5d0-430b-44ba-aad8-9c9e070bc226@default> <5a87e5d5-091b-4787-9dc3-2a01011ae604@default> <9d5ed15d-30e1-aa9d-b0e1-464d73c09d71@oracle.com> <59cffc7e-cafe-d5c0-f6d7-25c858c36d6d@oracle.com> <142c8228-8abe-8d75-4323-4bcbd1efeab3@oracle.com> Message-ID: <5a191005-c9c5-974b-8237-bcde32db9ba1@oracle.com> Hi Sergey, I have unified approach to get InternalFrame from button. Since updateFrameGeometry() was called with "javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton" component whose parent does not have internal frame,it was asserting so as done in paintButtonBackground(), updateFrameGeometry() is modified to check if the comp is JButton ,then extract the titlePane and use titlePane's parent to find internalFrame. http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.2/ Regards Prasanta On 14-Nov-18 2:01 AM, Sergey Bylokhov wrote: > On 13/11/2018 01:25, Prasanta Sadhukhan wrote: >> findInternalFrame() is called from paintButtonBackground(), >> paintFrameBorder() and updateFrameGeometry() >> but in paintButtonBackground() and paintFrameBorder() >> updateFrameGeometry() is called before findInternalFrame() so >> basically it is updateFrameGeometry()#findInternalFrame that is get >> called during assertion. > > But in these cases it is used in a little bit different ways, take a > look to the paintButtonBackground(). > > ?- In first line we will call updateFrameGeometry(), and inside: > ?? 1. We will call "comp = context.getComponent()" > ?? 2. Then will try to find titlePane using findChild() -? I guess it > will always fail for button. > ?? 3. Then we pass the comp to the findInternalFrame > ?- After that we return to the paintButtonBackground and: > ?? 1. We will call "button = context.getComponent()" > ?? 2. We will take a "titlePane = (JComponent)button.getParent()"; > NOTE: It is different that in "updateFrameGeometry" > ?? 3. Then we will take titlePaneParent from the titlepane > ?? 4. Then we pass the titlePaneParent to the findInternalFrame > > Note that context in both cases is the same, but we pass different > components to findInternalFrame. > I tried to move the call of findInternalFrame in the > paintButtonBackground before > updateFrameGeometry(to compare the second and first approaches) and it > is completes successfully. So it > seems we need to unify approach on how we get a InternalFrame from the > button. > > Can you please check this. > > >> >> During assertion, >> paintButtonBackground() is called which calls updateFrameGeometry() with >> comp=javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton[InternalFrameTitlePane.iconifyButton,240,3,18x18,alignmentX=0.0,alignmentY=0.5,border=,flags=290,maximumSize=,minimumSize=, >> >> preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=false,pressedIcon=, >> >> rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true] >> >> >> and comp's parent is >> javax.swing.plaf.synth.SynthInternalFrameTitlePane[InternalFrame.northPane,0,0,300x24,layout=com.sun.java.swing.plaf.gtk.Metacity$TitlePaneLayout, >> >> alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 26e3b5d8,flags=8388610,maximumSize=,minimumSize=,preferredSize=] >> >> >> so "comp.getParent() instanceof BasicInternalFrameTitlePane" check is >> satisfied so "comp" becomes SynthInternalFrameTitlePane. >> >> Since SynthInternalFrameTitlePane is not an instance of >> JInternalFrame nor JInternalFrame.JDesktopIcon, it results in >> assertion, so as a fix I extracted the internalframe from >> BasicInternalFrameTitlePane. >> >> Regards >> Prasanta >> On 13-Nov-18 7:56 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> Can you please provide more details on the hierarchy of components >>> which trigger this assertion. >>> >>> This method is used in 3 places, in two places we try to find the >>> child "InternalFrame.northPane" >>> and pass it to the findInternalFrame(). But in one place we take a >>> "button.getParent()", then pass >>> it to the findInternalFrame(), and take the parent one more time: >>> "comp.getParent() instanceof BasicInternalFrameTitlePane" >>> >>> Perhaps one call to "getParent()" is superfluous? What is the >>> hierarchy of panes/buttons/internal frames? >>> >>> >>> On 12/11/2018 03:21, Prasanta Sadhukhan wrote: >>>> Thanks Muneer for the confirmation. Gentle reminder to review which >>>> is pending for over a month now. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>> >>>> Regards >>>> Prasanta >>>> On 24-Oct-18 3:13 PM, Muneer Kolarkunnu wrote: >>>>> Hi Prasanta, >>>>> >>>>> I tested with provided binary and issue is resolved with this fix. >>>>> Thanks for fixing this issue. >>>>> >>>>> Regards, >>>>> Muneer >>>>> >>>>> -----Original Message----- >>>>> From: Muneer Kolarkunnu >>>>> Sent: Wednesday, October 24, 2018 12:00 PM >>>>> To: Prasanta Sadhukhan ; Sergey >>>>> Bylokhov ; swing-dev at openjdk.java.net >>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : >>>>> java.lang.AssertionError: cannot find the internal frame >>>>> >>>>> Hi Prasanta, >>>>> >>>>> I can verify it if you can share a binary with fix. >>>>> >>>>> Regards, >>>>> Muneer >>>>> >>>>> -----Original Message----- >>>>> From: Prasanta Sadhukhan >>>>> Sent: Wednesday, October 24, 2018 11:41 AM >>>>> To: Sergey Bylokhov ; >>>>> swing-dev at openjdk.java.net; ABDUL.KOLARKUNNU >>>>> >>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : >>>>> java.lang.AssertionError: cannot find the internal frame >>>>> >>>>> Hi Muneer, >>>>> >>>>> Could you check (as a submitter) if the proposed fix works in your >>>>> jemmy environment? It seems to work for me with the command line >>>>> you gave in JBS. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 22-Oct-18 11:24 AM, Prasanta Sadhukhan wrote: >>>>>> Gentle reminder... >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 05-Oct-18 2:31 PM, Prasanta Sadhukhan wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> >>>>>>> On 04-Oct-18 11:03 PM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> On 04-Oct-18 10:44 PM, Prasanta Sadhukhan wrote: >>>>>>>>> >>>>>>>>> On 04-Oct-18 10:29 PM, Sergey Bylokhov wrote: >>>>>>>>>> On 04/10/2018 09:44, Prasanta Sadhukhan wrote: >>>>>>>>>>> Hi Sergey, >>>>>>>>>>> >>>>>>>>>>> Yes, this method should return JInternalFrame but there is >>>>>>>>>>> no way >>>>>>>>>>> to get JinternalFrame object from BasicInternalFrameTitlePane >>>>>>>>>>> currently. >>>>>>>>>> But why it is not possible? The BasicInternalFrameTitlePane is a >>>>>>>>>> title of the internalFrame and it looks like it should be >>>>>>>>>> located >>>>>>>>>> somewhere inside the internalFrame, isn't it? >>>>>>>>>> >>>>>>>>> BasicInternalTitlePane has a protected variable of JInternalFrame >>>>>>>>> object and there is no public method to access that so that's >>>>>>>>> why I >>>>>>>>> told it is not currently possible unless we add a public >>>>>>>>> method in >>>>>>>>> this Basic* class, if I understand it correctly. Let me know >>>>>>>>> if it >>>>>>>>> can be accessed some other way. >>>>>>>>> >>>>>>>> JInternalFrame.getUI().getNorthPane() probably might give >>>>>>>> BasicInternalTitlePane object but I do not think we can get >>>>>>>> viceversa, ie get JInternalFrame object from >>>>>>>> BasicInternalTitlePane. >>>>>>> I have improved the code to get JInternalFrame from >>>>>>> BasicInternalFrameTitlePane, as you have suggested >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> This Metacity class has the provision of accepting null value >>>>>>>>>> from >>>>>>>>>> this method >>>>>>>>>>> and this assertion problem is caused only when we ran with >>>>>>>>>>> "esa" >>>>>>>>>>> [to enable assertion]. The submitter has not mentioned there is >>>>>>>>>>> any failure if we run the without esa, so I have only done away >>>>>>>>>>> with the wrong assertion for BasicInternalFrameTitlePane. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 04-Oct-18 9:43 PM, Sergey Bylokhov wrote: >>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>> Can you please clarify this code a little bit. As far as I >>>>>>>>>>>> understand this method should return the JInternalFrame, which >>>>>>>>>>>> should be accessed via the comp passed to this method. This >>>>>>>>>>>> method already has this check: >>>>>>>>>>>> ???????? if (comp.getParent() instanceof >>>>>>>>>>>> BasicInternalFrameTitlePane) { >>>>>>>>>>>> ???????????? comp = comp.getParent(); >>>>>>>>>>>> ???????? } >>>>>>>>>>>> >>>>>>>>>>>> So maybe we can improve it to fetch the JInternalFrame from >>>>>>>>>>>> the >>>>>>>>>>>> BasicInternalFrameTitlePane or from another class passed to >>>>>>>>>>>> this >>>>>>>>>>>> method? >>>>>>>>>>>> >>>>>>>>>>>> On 04/10/2018 07:35, Prasanta Sadhukhan wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a cleanup of the code where wrong assertion is >>>>>>>>>>>>> used when Component is an instance of >>>>>>>>>>>>> BasicInternalFrameTitlePane. >>>>>>>>>>>>> >>>>>>>>>>>>> Now, BasicInternalFrameTitlePane is extended from JComponent >>>>>>>>>>>>> and not from JInternalFrame so it will never satisfy the >>>>>>>>>>>>> if-else condition if "Component is instanceof >>>>>>>>>>>>> BasicInternalFrameTitlePane", so proposed fix is to assert >>>>>>>>>>>>> only >>>>>>>>>>>>> if the component is not an instance of >>>>>>>>>>>>> BasicInternalFrameTitlePane >>>>>>>>>>>>> >>>>>>>>>>>>> diff -r d96a607e9594 >>>>>>>>>>>>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Meta >>>>>>>>>>>>> >>>>>>>>>>>>> city.java >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> a/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>> >>>>>>>>>>>>> tacity.java >>>>>>>>>>>>> Tue Sep 18 18:32:03 2018 -0700 >>>>>>>>>>>>> +++ >>>>>>>>>>>>> b/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>> >>>>>>>>>>>>> tacity.java >>>>>>>>>>>>> Thu Oct 04 19:53:10 2018 +0530 >>>>>>>>>>>>> @@ -337,7 +337,9 @@ >>>>>>>>>>>>> ?????????? } else if (comp instanceof >>>>>>>>>>>>> JInternalFrame.JDesktopIcon) { >>>>>>>>>>>>> ?????????????? return >>>>>>>>>>>>> ((JInternalFrame.JDesktopIcon)comp).getInternalFrame(); >>>>>>>>>>>>> ?????????? } >>>>>>>>>>>>> -??????? assert false : "cannot find the internal frame"; >>>>>>>>>>>>> +?????? if (!(comp instanceof BasicInternalFrameTitlePane)) { >>>>>>>>>>>>> +??????????? assert false : "cannot find the internal frame"; >>>>>>>>>>>>> +?????? } >>>>>>>>>>>>> ?????????? return null; >>>>>>>>>>>>> ?????? } >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>> >>>>>>>>>> >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Mon May 20 15:37:04 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Mon, 20 May 2019 08:37:04 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ Message-ID: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> bugs: https://bugs.openjdk.java.net/browse/JDK-8153090 https://bugs.openjdk.java.net/browse/JDK-8223788 https://bugs.openjdk.java.net/browse/JDK-8224149 webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ The fix eliminates issues in JColorChooser dialog making it more accessible by keyboard. See JBS for details. --Semyon From philip.race at oracle.com Mon May 20 17:10:38 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 May 2019 10:10:38 -0700 Subject: [13] Review Request: 8213516 jck test api/javax_accessibility/AccessibleState/fields.html fails intermittent In-Reply-To: References: Message-ID: <76e6aca0-cce2-03b4-0289-128fe13580c0@oracle.com> Looks fine. -phil. On 4/29/19 1:06 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213516 > Fix: http://cr.openjdk.java.net/~serb/8213516/webrev.00 > > We have a bug in our implementation of the cache in the > AccessibleBundle class. The current cache should cache the "value" per > compound key "locale+name_bundle", but the only locale is used. The > problem is reproduced when we try to use different resource bundles > for one locale. > > One of the previous version of the fix was sent here: > https://mail.openjdk.java.net/pipermail/swing-dev/2019-March/009509.html > http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.06 > > Since this is a cache I have an assumption that the performance of > this code matters. So I decided to measure the difference before/after > the fix, and w/o cache of > AccessibleRole.LABEL.toDisplayString(Locale.ENGLISH); > > BEFORE: 25.826 ops/MICROSECONDS > AFTER: 5.459 ops/MICROSECONDS > WITHOUT CACHE 11.015 ops/MICROSECONDS > > ======= > This cache was added in jdk 1.3 in 1999 using this description: > "Obtaining resource bundles can be expensive,...A time performance > improvement can be made if we cache the resource bundles by locale. We > probably should also see if ResourceBundle itself caches these for us" > ======= > > I have checked that the current implementation of ResourceBundle > caches its state and our implementation does not provide any real > benefit. > From philip.race at oracle.com Mon May 20 18:04:32 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 May 2019 11:04:32 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> Message-ID: <5CE2EC30.1040304@oracle.com> Hi, I'm afraid I know next to nothing about the focus traversal code in Swing or AWT, but it smells very wrong to have such knowledge of a specific Swing component in the AWT focus code. -phil. On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: > bugs: > > https://bugs.openjdk.java.net/browse/JDK-8153090 > > https://bugs.openjdk.java.net/browse/JDK-8223788 > > https://bugs.openjdk.java.net/browse/JDK-8224149 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ > > The fix eliminates issues in JColorChooser dialog making it more > accessible by keyboard. See JBS for details. > > --Semyon > From Sergey.Bylokhov at oracle.com Mon May 20 18:09:57 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 May 2019 11:09:57 -0700 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: <9b63748a-f815-dad5-92f1-e12d53565a1a@oracle.com> References: <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> <74c9e459-1b84-2bad-5c1a-c8dd944a7fdd@oracle.com> <9b63748a-f815-dad5-92f1-e12d53565a1a@oracle.com> Message-ID: Hi, Prasanta. This version looks fine, but I have two comments: - Please split the long lines in the fix. - Can you please confirm that the tests(jck/regression) are passed on the latest version, and there are no new issues. On 16/05/2019 22:05, Prasanta Sadhukhan wrote: > Hi Sergey, > > > On 16-May-19 9:13 PM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> Should not we use the real "screen" FontRenderContext instead of "DEFAULT_FRC"? > Yes, I guess it was mentioned in one of the review comment earliter, that it may not be the cause of this problem, but it needs to be changed. >> Did you check do we need to update the similat cases in the same class(we use getJustifiedLayout() 4 times mostly in the same code pattern)? > Might as well. I updated 3 of them and the 4th one is with AttributeCharaterIterator (and not dealing with String as such unlike other 3) so did not update. > Modified webrev with the change > http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.5/ > > Regards > Prasanta >> >> On 15/05/2019 22:23, Prasanta Sadhukhan wrote: >>> Not sure if you are saying it's ok to "push"? I guess I need a 2nd reviewer if you are ok with this. >>> >>> Regards >>> Prasanta >>> On 16-May-19 12:01 AM, Phil Race wrote: >>>> OK. Let's try that. I am sure it is still going to be non-ideal in a couple of ways >>>> 1) where printed is shorter than screenwidth and we don't adjust, there may >>>> be space after the text and before the "edge" of the component, but at least >>>> there's no clipping and the text should look natural initself >>>> >>>> 2) Where printed is longer than screenwidth and we do adjust we may still >>>> run into similar cases as this .. >>>> >>>> -phil. >>>> >>>> On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> >>>>> >>>>> On 18-Apr-19 12:31 AM, Phil Race wrote: >>>>>> >>>>>> >>>>>> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> Hi Phil, >>>>>>> >>>>>>> It seems screenWidth or "advance of the string at screen-resolution" is 533 whereas string advance calculated using printer fontmetrics is 503 >>>>>>> >>>>>>> Now, TextLine#getJustifiedLine() [called from TextLayout.getJustifiedLayout] again calculates "justifyAdvance" for TextLineComponent which comes out to be 503,then it calculates >>>>>>> the actual justification "delta" by subtracting justifyAdvance from screenWidth which is 533-503=30 and it then does TextJustifier.justify(delta) >>>>>>> which calculates the amount by which each side of each glyph should grow or shrink. >>>>>>> >>>>>>> Then TextLine.getJustifiedLine() applies this value by calling TextLineComponent.applyJustificationDeltas() where it >>>>>>> ?handle whitespace by modifying advance but? handle everything else by modifying position before and after, >>>>>>> ?so "spaces" seem to grow in size resulting in shifting of text with whitespaces. >>>>>> >>>>>> The spaces being used to add needed or absorb surplus space is what I understood the current code to be doing, >>>>>> >>>>>> However I am not sure what you mean by this :- >>>>>> "but? handle everything else by modifying position before and after," >>>>>> >>>>>> Code run through text layout will always have glyph positions assigned, so I would suppose modifying the position >>>>>> is how the spaces were handled too .. and of course this means running through all preceding glyphs to make >>>>>> it consistent .. and I thought it was only adjusting the spaces, so what is "everything else" >>>>> It seems when TextLineComponent.applyJustificationDeltas() is called, ExtendedTextSourceLabel.applyJustificationDeltas() handles that >>>>> http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 >>>>> where it handles "whitespace" a bit different (if block) from other glyph (else block) where advance is is not considered, which is also conveyed? in the comment @1011 >>>>>>> >>>>>>> ?Since it was mentioned in TextLayout.getJustifiedLayout() that "? For best results, justificationWidth should not be too different from the current advance of the line" >>>>>> >>>>>> So for "best" results don't try to adjust a string that's 3 words and 80 pixels to a 500 pixel width. >>>>>> >>>>>>> I am proposing a fix to conditionally call TextLayout.getJustifiedLayout() only if the difference between justificationWidth and advance with for printer is more than 10. >>>>>>> >>>>>> >>>>>> I had proposed investigating what happens if you simply don't use justification when the text will fit. >>>>>> Maybe you are refining that but I am not sure about the details. >>>>>> 10 is one arbitrary number and is not proportional to the length - which is what I would be >>>>>> thinking about first in succh an approach >>>>>> And I am not even sure you mean what you say. >>>>>> You say "more" than 10, yet your code implements "less" than 10. >>>>> It was a typo in mail. >>>>> Modified? webrev to not use justification if string width of text is within screenWidth >>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ >>>>> >>>>> Regards >>>>> Prasanta >>>>>> And moreover its an absolute value you are using, which re-introduces the clipping problem, doesn't it ? >>>>>> ie you are purely looking at the difference and it isn't what I has proposed and I thought you were trying. >>>>>> >>>>>> -phil >>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>>>>>> >>>>>>>>> Thanks Phil for review. So, you are doubting it will regress swing printing tests. As you told earlier, I have ran the following regression test with this fix >>>>>>>>> >>>>>>>> >>>>>>>> It may not regress a test if the test is not being tested under the >>>>>>>> same conditions for which it is created but I am telling you for a >>>>>>>> fact that the fix is wrong. screenWidth should be "width on the screen" >>>>>>>>> >>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug above is covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>>>>>> and I did not notice any regression. Any other test we have for swing printing that we can run? >>>>>>>>> >>>>>>>> >>>>>>>> No idea which tests will show this today but I know it is an issue. >>>>>>>> No way we can push this and then just wait for the complaints. >>>>>>>> >>>>>>>>> >>Previously we were using DEFAULT_FRC to make it a screen width which except for maybe needing to be updated for hi-dpi screens is what we want. >>>>>>>>> This issue was there from jdk1.6. If it is for hidpi screen, we would have seen it from jdk9 onwards where we supported hidpi, no? >>>>>>>> >>>>>>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>>>>>> I think that should have been updated in 1.9 but was missed because >>>>>>>> it (hidpi for windows) was not a small or contained task. >>>>>>>> This is an ancilliary observation of something that should be looked >>>>>>>> at entirely independent of this bug. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>>>>>> The current fix confused me for a while as I could not see how it was >>>>>>>>>> at all different than the existing code, since I can't imagine when we'd >>>>>>>>>> ever take the "else" branch here : >>>>>>>>>> 533 TextLayout layout; >>>>>>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>>>> 536 } else { >>>>>>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>> 538 } Eventually when walking through it I noticed this 531 FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>> >>>>>>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER - ie the scaled FontRenderContext. >>>>>>>>>> It then uses this to calculate the advance width for such a case - ie the printer >>>>>>>>>> but then *assigns it to a variable called screenWidth*. >>>>>>>>>> >>>>>>>>>> Previously we were using DEFAULT_FRC to make it a screen width which except >>>>>>>>>> for maybe needing to be updated for hi-dpi screens is what we want. >>>>>>>>>> >>>>>>>>>> So in the updated proposed fix the wrong width is passed to getJustifiedLayout(). >>>>>>>>>> >>>>>>>>>> This may not matter here because there is plenty of space, but in other cases >>>>>>>>>> Swing printing will be clipped as a result. And there were many, many, bug reports about >>>>>>>>>> that. Which is why the code is laying out to the screenwidth because that is where the >>>>>>>>>> UI component size available came from. Buttons & Label text are the typical cases where >>>>>>>>>> this showed up. >>>>>>>>>> >>>>>>>>>> There maybe other things to change, as well but the incorrect screenWidth is the >>>>>>>>>> main problem I see here. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>>> >>>>>>>>>>>>> I believe drawChars() also has same printing issue [and should be changed like modified drawString()] but I am not able to test it as reproducer testcase uses JLabel whose constructor can only accept "String" and not char[] so I can only test drawString(). Using drawChars() implementation in drawString() still reproduces the issue. >>>>>>>>>>>> >>>>>>>>>>>> Is it possible temporary replace the call to drawString() by the drawChars(), to check how drawChars() will work? >>>>>>>>>>> As I told, it behaves similarly to unmodified drawString and the issue can still be seen. I think we should commit this drawString() change in this fix and I can open another bug to investigate drawChars() impl and reproducer. Will that be fine? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>>> or probably we can implement drawChars() on top of drawString()? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I modified the fix to use deviceFRC if not compatible and in sync with the comment which says "obtain a TextLayout with advances for the printer graphics FRC" >>>>>>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates the advances of the string if text layouting is used. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you please take a look to the existed drawChars() method, which is implemented in the similar way as drawStringImpl() and new version of drawString(), but they have some small difference. Why we cannot use the same logic? >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example in the drawChars: >>>>>>>>>>>>>> ========= >>>>>>>>>>>>>> ??????????? FontRenderContext deviceFontRenderContext = g2d. >>>>>>>>>>>>>> ??????????????? getFontRenderContext(); >>>>>>>>>>>>>> ??????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>>>>>> ??????????? if (frc != null && >>>>>>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>>>>>> ??????????????? (deviceFontRenderContext, frc)) { >>>>>>>>>>>>>> ???????????????? String text = new String(data, offset, length); >>>>>>>>>>>>>> ???????????????? TextLayout layout = new TextLayout(text, g2d.getFont(), >>>>>>>>>>>>>> deviceFontRenderContext); >>>>>>>>>>>>>> ???????????????? String trimmedText = trimTrailingSpaces(text); >>>>>>>>>>>>>> ???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>>>> ???????????????????? float screenWidth = (float)g2d.getFont(). >>>>>>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>>>>>> ???????????????????? layout = layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>>> >>>>>>>>>>>>>> ========== >>>>>>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ?524???????????????? FontRenderContext frc = getFontRenderContext(c); >>>>>>>>>>>>>> ?525???????????????? if (frc.isAntiAliased() || frc.usesFractionalMetrics()) { >>>>>>>>>>>>>> ?526???????????????????? frc = new FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>>>>>> ?527???????????????? } >>>>>>>>>>>>>> ?528???????????????? FontRenderContext deviceFRC = g2d.getFontRenderContext(); >>>>>>>>>>>>>> ?529???????????????? String trimmedText = trimTrailingSpaces(text); >>>>>>>>>>>>>> ?530???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>>>> ?531???????????????????? FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>>>>>> ?532???????????????????? float screenWidth = SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>>>>>> ?533???????????????????? TextLayout layout; >>>>>>>>>>>>>> ?534???????????????????? if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>>>>> ?535???????????????????????? layout = createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>>>>>>>> ?536???????????????????? } else { >>>>>>>>>>>>>> ?537???????????????????????? layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>>>>>> ?538???????????????????? } >>>>>>>>>>>>>> ?540???????????????????? layout = layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon May 20 18:15:18 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 May 2019 11:15:18 -0700 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: References: <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> <74c9e459-1b84-2bad-5c1a-c8dd944a7fdd@oracle.com> <9b63748a-f815-dad5-92f1-e12d53565a1a@oracle.com> Message-ID: <5CE2EEB6.8000005@oracle.com> On 5/20/19, 11:09 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > This version looks fine, but I have two comments: > - Please split the long lines in the fix. > - Can you please confirm that the tests(jck/regression) are passed on > the latest version, and there are no new issues. > > On 16/05/2019 22:05, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> >> On 16-May-19 9:13 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> Should not we use the real "screen" FontRenderContext instead of >>> "DEFAULT_FRC"? >> Yes, I guess it was mentioned in one of the review comment earliter, >> that it may not be the cause of this problem, but it needs to be >> changed. Yes. I think you mean this comment :- On 2/25/19, 1:55 PM, Phil Race wrote: > > Previously we were using DEFAULT_FRC to make it a screen width which except > for maybe needing to be updated for hi-dpi screens is what we want. In other words it is something that should have been updated as part of the hi-dpi work, and we might as well fix it now. -phil. >>> Did you check do we need to update the similat cases in the same >>> class(we use getJustifiedLayout() 4 times mostly in the same code >>> pattern)? >> Might as well. I updated 3 of them and the 4th one is with >> AttributeCharaterIterator (and not dealing with String as such unlike >> other 3) so did not update. >> Modified webrev with the change >> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.5/ >> >> Regards >> Prasanta >>> >>> On 15/05/2019 22:23, Prasanta Sadhukhan wrote: >>>> Not sure if you are saying it's ok to "push"? I guess I need a 2nd >>>> reviewer if you are ok with this. >>>> >>>> Regards >>>> Prasanta >>>> On 16-May-19 12:01 AM, Phil Race wrote: >>>>> OK. Let's try that. I am sure it is still going to be non-ideal in >>>>> a couple of ways >>>>> 1) where printed is shorter than screenwidth and we don't adjust, >>>>> there may >>>>> be space after the text and before the "edge" of the component, >>>>> but at least >>>>> there's no clipping and the text should look natural initself >>>>> >>>>> 2) Where printed is longer than screenwidth and we do adjust we >>>>> may still >>>>> run into similar cases as this .. >>>>> >>>>> -phil. >>>>> >>>>> On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 18-Apr-19 12:31 AM, Phil Race wrote: >>>>>>> >>>>>>> >>>>>>> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> It seems screenWidth or "advance of the string at >>>>>>>> screen-resolution" is 533 whereas string advance calculated >>>>>>>> using printer fontmetrics is 503 >>>>>>>> >>>>>>>> Now, TextLine#getJustifiedLine() [called from >>>>>>>> TextLayout.getJustifiedLayout] again calculates >>>>>>>> "justifyAdvance" for TextLineComponent which comes out to be >>>>>>>> 503,then it calculates >>>>>>>> the actual justification "delta" by subtracting justifyAdvance >>>>>>>> from screenWidth which is 533-503=30 and it then does >>>>>>>> TextJustifier.justify(delta) >>>>>>>> which calculates the amount by which each side of each glyph >>>>>>>> should grow or shrink. >>>>>>>> >>>>>>>> Then TextLine.getJustifiedLine() applies this value by calling >>>>>>>> TextLineComponent.applyJustificationDeltas() where it >>>>>>>> handle whitespace by modifying advance but handle everything >>>>>>>> else by modifying position before and after, >>>>>>>> so "spaces" seem to grow in size resulting in shifting of text >>>>>>>> with whitespaces. >>>>>>> >>>>>>> The spaces being used to add needed or absorb surplus space is >>>>>>> what I understood the current code to be doing, >>>>>>> >>>>>>> However I am not sure what you mean by this :- >>>>>>> "but handle everything else by modifying position before and >>>>>>> after," >>>>>>> >>>>>>> Code run through text layout will always have glyph positions >>>>>>> assigned, so I would suppose modifying the position >>>>>>> is how the spaces were handled too .. and of course this means >>>>>>> running through all preceding glyphs to make >>>>>>> it consistent .. and I thought it was only adjusting the spaces, >>>>>>> so what is "everything else" >>>>>> It seems when TextLineComponent.applyJustificationDeltas() is >>>>>> called, ExtendedTextSourceLabel.applyJustificationDeltas() >>>>>> handles that >>>>>> http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 >>>>>> >>>>>> where it handles "whitespace" a bit different (if block) from >>>>>> other glyph (else block) where advance is is not considered, >>>>>> which is also conveyed in the comment @1011 >>>>>>>> >>>>>>>> Since it was mentioned in TextLayout.getJustifiedLayout() that >>>>>>>> " For best results, justificationWidth should not be too >>>>>>>> different from the current advance of the line" >>>>>>> >>>>>>> So for "best" results don't try to adjust a string that's 3 >>>>>>> words and 80 pixels to a 500 pixel width. >>>>>>> >>>>>>>> I am proposing a fix to conditionally call >>>>>>>> TextLayout.getJustifiedLayout() only if the difference between >>>>>>>> justificationWidth and advance with for printer is more than 10. >>>>>>>> >>>>>>> >>>>>>> I had proposed investigating what happens if you simply don't >>>>>>> use justification when the text will fit. >>>>>>> Maybe you are refining that but I am not sure about the details. >>>>>>> 10 is one arbitrary number and is not proportional to the length >>>>>>> - which is what I would be >>>>>>> thinking about first in succh an approach >>>>>>> And I am not even sure you mean what you say. >>>>>>> You say "more" than 10, yet your code implements "less" than 10. >>>>>> It was a typo in mail. >>>>>> Modified webrev to not use justification if string width of text >>>>>> is within screenWidth >>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> And moreover its an absolute value you are using, which >>>>>>> re-introduces the clipping problem, doesn't it ? >>>>>>> ie you are purely looking at the difference and it isn't what I >>>>>>> has proposed and I thought you were trying. >>>>>>> >>>>>>> -phil >>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> Thanks Phil for review. So, you are doubting it will regress >>>>>>>>>> swing printing tests. As you told earlier, I have ran the >>>>>>>>>> following regression test with this fix >>>>>>>>>> >>>>>>>>> >>>>>>>>> It may not regress a test if the test is not being tested >>>>>>>>> under the >>>>>>>>> same conditions for which it is created but I am telling you >>>>>>>>> for a >>>>>>>>> fact that the fix is wrong. screenWidth should be "width on >>>>>>>>> the screen" >>>>>>>>>> >>>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug >>>>>>>>>> above is covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>>>>>>> and I did not notice any regression. Any other test we have >>>>>>>>>> for swing printing that we can run? >>>>>>>>>> >>>>>>>>> >>>>>>>>> No idea which tests will show this today but I know it is an >>>>>>>>> issue. >>>>>>>>> No way we can push this and then just wait for the complaints. >>>>>>>>> >>>>>>>>>> >>Previously we were using DEFAULT_FRC to make it a screen >>>>>>>>>> width which except for maybe needing to be updated for hi-dpi >>>>>>>>>> screens is what we want. >>>>>>>>>> This issue was there from jdk1.6. If it is for hidpi screen, >>>>>>>>>> we would have seen it from jdk9 onwards where we supported >>>>>>>>>> hidpi, no? >>>>>>>>> >>>>>>>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>>>>>>> I think that should have been updated in 1.9 but was missed >>>>>>>>> because >>>>>>>>> it (hidpi for windows) was not a small or contained task. >>>>>>>>> This is an ancilliary observation of something that should be >>>>>>>>> looked >>>>>>>>> at entirely independent of this bug. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>>>>>>> The current fix confused me for a while as I could not see >>>>>>>>>>> how it was >>>>>>>>>>> at all different than the existing code, since I can't >>>>>>>>>>> imagine when we'd >>>>>>>>>>> ever take the "else" branch here : >>>>>>>>>>> 533 TextLayout layout; >>>>>>>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), >>>>>>>>>>> deviceFRC); >>>>>>>>>>> 536 } else { >>>>>>>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>>> 538 } Eventually when walking through it I noticed this 531 >>>>>>>>>>> FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm >>>>>>>>>>> ,trimmedText); >>>>>>>>>>> >>>>>>>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER >>>>>>>>>>> - ie the scaled FontRenderContext. >>>>>>>>>>> It then uses this to calculate the advance width for such a >>>>>>>>>>> case - ie the printer >>>>>>>>>>> but then *assigns it to a variable called screenWidth*. >>>>>>>>>>> >>>>>>>>>>> Previously we were using DEFAULT_FRC to make it a screen >>>>>>>>>>> width which except >>>>>>>>>>> for maybe needing to be updated for hi-dpi screens is what >>>>>>>>>>> we want. >>>>>>>>>>> >>>>>>>>>>> So in the updated proposed fix the wrong width is passed to >>>>>>>>>>> getJustifiedLayout(). >>>>>>>>>>> >>>>>>>>>>> This may not matter here because there is plenty of space, >>>>>>>>>>> but in other cases >>>>>>>>>>> Swing printing will be clipped as a result. And there were >>>>>>>>>>> many, many, bug reports about >>>>>>>>>>> that. Which is why the code is laying out to the screenwidth >>>>>>>>>>> because that is where the >>>>>>>>>>> UI component size available came from. Buttons & Label text >>>>>>>>>>> are the typical cases where >>>>>>>>>>> this showed up. >>>>>>>>>>> >>>>>>>>>>> There maybe other things to change, as well but the >>>>>>>>>>> incorrect screenWidth is the >>>>>>>>>>> main problem I see here. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I believe drawChars() also has same printing issue [and >>>>>>>>>>>>>> should be changed like modified drawString()] but I am >>>>>>>>>>>>>> not able to test it as reproducer testcase uses JLabel >>>>>>>>>>>>>> whose constructor can only accept "String" and not char[] >>>>>>>>>>>>>> so I can only test drawString(). Using drawChars() >>>>>>>>>>>>>> implementation in drawString() still reproduces the issue. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible temporary replace the call to drawString() >>>>>>>>>>>>> by the drawChars(), to check how drawChars() will work? >>>>>>>>>>>> As I told, it behaves similarly to unmodified drawString >>>>>>>>>>>> and the issue can still be seen. I think we should commit >>>>>>>>>>>> this drawString() change in this fix and I can open another >>>>>>>>>>>> bug to investigate drawChars() impl and reproducer. Will >>>>>>>>>>>> that be fine? >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>>> or probably we can implement drawChars() on top of >>>>>>>>>>>>> drawString()? >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I modified the fix to use deviceFRC if not compatible >>>>>>>>>>>>>>>> and in sync with the comment which says "obtain a >>>>>>>>>>>>>>>> TextLayout with advances for the printer graphics FRC" >>>>>>>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates >>>>>>>>>>>>>>>> the advances of the string if text layouting is used. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you please take a look to the existed drawChars() >>>>>>>>>>>>>>> method, which is implemented in the similar way as >>>>>>>>>>>>>>> drawStringImpl() and new version of drawString(), but >>>>>>>>>>>>>>> they have some small difference. Why we cannot use the >>>>>>>>>>>>>>> same logic? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example in the drawChars: >>>>>>>>>>>>>>> ========= >>>>>>>>>>>>>>> FontRenderContext deviceFontRenderContext = >>>>>>>>>>>>>>> g2d. >>>>>>>>>>>>>>> getFontRenderContext(); >>>>>>>>>>>>>>> FontRenderContext frc = >>>>>>>>>>>>>>> getFontRenderContext(c); >>>>>>>>>>>>>>> if (frc != null && >>>>>>>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>>>>>>> (deviceFontRenderContext, frc)) { >>>>>>>>>>>>>>> String text = new String(data, offset, >>>>>>>>>>>>>>> length); >>>>>>>>>>>>>>> TextLayout layout = new >>>>>>>>>>>>>>> TextLayout(text, g2d.getFont(), >>>>>>>>>>>>>>> deviceFontRenderContext); >>>>>>>>>>>>>>> String trimmedText = >>>>>>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>>>>>> if (!trimmedText.isEmpty()) { >>>>>>>>>>>>>>> float screenWidth = >>>>>>>>>>>>>>> (float)g2d.getFont(). >>>>>>>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>>>>>>> layout = >>>>>>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ========== >>>>>>>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 524 FontRenderContext frc = >>>>>>>>>>>>>>> getFontRenderContext(c); >>>>>>>>>>>>>>> 525 if (frc.isAntiAliased() || >>>>>>>>>>>>>>> frc.usesFractionalMetrics()) { >>>>>>>>>>>>>>> 526 frc = new >>>>>>>>>>>>>>> FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>>>>>>> 527 } >>>>>>>>>>>>>>> 528 FontRenderContext deviceFRC = >>>>>>>>>>>>>>> g2d.getFontRenderContext(); >>>>>>>>>>>>>>> 529 String trimmedText = >>>>>>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>>>>>> 530 if (!trimmedText.isEmpty()) { >>>>>>>>>>>>>>> 531 FontMetrics fm = >>>>>>>>>>>>>>> g2d.getFontMetrics(); >>>>>>>>>>>>>>> 532 float screenWidth = >>>>>>>>>>>>>>> SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>>>>>>> 533 TextLayout layout; >>>>>>>>>>>>>>> 534 if >>>>>>>>>>>>>>> (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>>>>>> 535 layout = >>>>>>>>>>>>>>> createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>>>>>>>>> 536 } else { >>>>>>>>>>>>>>> 537 layout = >>>>>>>>>>>>>>> createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>>>>>>> 538 } >>>>>>>>>>>>>>> 540 layout = >>>>>>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Mon May 20 20:06:37 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Mon, 20 May 2019 13:06:37 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <5CE2EC30.1040304@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> <5CE2EC30.1040304@oracle.com> Message-ID: <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> On 5/20/19 11:04 AM, Philip Race wrote: > Hi, > > I'm afraid I know next to nothing about the focus traversal > code in Swing or AWT, but it smells very wrong to have > such knowledge of a specific Swing component in the > AWT focus code. I don't see anything wrong here. You can find a lot of Swing component specific code in java.awt.* implementations. This is not the first Swing aware AWT class. --Semyon > > -phil. > > On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: >> bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8153090 >> >> https://bugs.openjdk.java.net/browse/JDK-8223788 >> >> https://bugs.openjdk.java.net/browse/JDK-8224149 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ >> >> The fix eliminates issues in JColorChooser dialog making it more >> accessible by keyboard. See JBS for details. >> >> --Semyon >> From prasanta.sadhukhan at oracle.com Tue May 21 05:21:25 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 21 May 2019 10:51:25 +0530 Subject: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame In-Reply-To: <5a191005-c9c5-974b-8237-bcde32db9ba1@oracle.com> References: <22a77e7c-4d6e-d300-6412-7a032a9e4258@oracle.com> <440dc24e-b011-35af-a6b1-86d036334070@oracle.com> <2278bf48-ff56-1775-1652-fff040e6edce@oracle.com> <641d40c7-7db6-bbcf-653e-a2513c6e57a3@oracle.com> <837dc5d0-430b-44ba-aad8-9c9e070bc226@default> <5a87e5d5-091b-4787-9dc3-2a01011ae604@default> <9d5ed15d-30e1-aa9d-b0e1-464d73c09d71@oracle.com> <59cffc7e-cafe-d5c0-f6d7-25c858c36d6d@oracle.com> <142c8228-8abe-8d75-4323-4bcbd1efeab3@oracle.com> <5a191005-c9c5-974b-8237-bcde32db9ba1@oracle.com> Message-ID: PS: Since this is causing few tests to fail in headful nightly, I wish to get this reviewed and committed soon. Regards Prasanta On 20-May-19 3:19 PM, Prasanta Sadhukhan wrote: > Hi Sergey, > > I have unified approach to get InternalFrame from button. Since > updateFrameGeometry() was called with > "javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton" > component whose parent does not have internal frame,it was asserting > so as done in paintButtonBackground(), updateFrameGeometry() is > modified to check if the comp is JButton ,then extract the titlePane > and use titlePane's parent to find internalFrame. > http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.2/ > > Regards > Prasanta > On 14-Nov-18 2:01 AM, Sergey Bylokhov wrote: >> On 13/11/2018 01:25, Prasanta Sadhukhan wrote: >>> findInternalFrame() is called from paintButtonBackground(), >>> paintFrameBorder() and updateFrameGeometry() >>> but in paintButtonBackground() and paintFrameBorder() >>> updateFrameGeometry() is called before findInternalFrame() so >>> basically it is updateFrameGeometry()#findInternalFrame that is get >>> called during assertion. >> >> But in these cases it is used in a little bit different ways, take a >> look to the paintButtonBackground(). >> >> ?- In first line we will call updateFrameGeometry(), and inside: >> ?? 1. We will call "comp = context.getComponent()" >> ?? 2. Then will try to find titlePane using findChild() -? I guess it >> will always fail for button. >> ?? 3. Then we pass the comp to the findInternalFrame >> ?- After that we return to the paintButtonBackground and: >> ?? 1. We will call "button = context.getComponent()" >> ?? 2. We will take a "titlePane = (JComponent)button.getParent()"; >> NOTE: It is different that in "updateFrameGeometry" >> ?? 3. Then we will take titlePaneParent from the titlepane >> ?? 4. Then we pass the titlePaneParent to the findInternalFrame >> >> Note that context in both cases is the same, but we pass different >> components to findInternalFrame. >> I tried to move the call of findInternalFrame in the >> paintButtonBackground before >> updateFrameGeometry(to compare the second and first approaches) and >> it is completes successfully. So it >> seems we need to unify approach on how we get a InternalFrame from >> the button. >> >> Can you please check this. >> >> >>> >>> During assertion, >>> paintButtonBackground() is called which calls updateFrameGeometry() >>> with >>> comp=javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton[InternalFrameTitlePane.iconifyButton,240,3,18x18,alignmentX=0.0,alignmentY=0.5,border=,flags=290,maximumSize=,minimumSize=, >>> >>> preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=false,pressedIcon=, >>> >>> rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true] >>> >>> >>> and comp's parent is >>> javax.swing.plaf.synth.SynthInternalFrameTitlePane[InternalFrame.northPane,0,0,300x24,layout=com.sun.java.swing.plaf.gtk.Metacity$TitlePaneLayout, >>> >>> alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 26e3b5d8,flags=8388610,maximumSize=,minimumSize=,preferredSize=] >>> >>> >>> so "comp.getParent() instanceof BasicInternalFrameTitlePane" check >>> is satisfied so "comp" becomes SynthInternalFrameTitlePane. >>> >>> Since SynthInternalFrameTitlePane is not an instance of >>> JInternalFrame nor JInternalFrame.JDesktopIcon, it results in >>> assertion, so as a fix I extracted the internalframe from >>> BasicInternalFrameTitlePane. >>> >>> Regards >>> Prasanta >>> On 13-Nov-18 7:56 AM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> >>>> Can you please provide more details on the hierarchy of components >>>> which trigger this assertion. >>>> >>>> This method is used in 3 places, in two places we try to find the >>>> child "InternalFrame.northPane" >>>> and pass it to the findInternalFrame(). But in one place we take a >>>> "button.getParent()", then pass >>>> it to the findInternalFrame(), and take the parent one more time: >>>> "comp.getParent() instanceof BasicInternalFrameTitlePane" >>>> >>>> Perhaps one call to "getParent()" is superfluous? What is the >>>> hierarchy of panes/buttons/internal frames? >>>> >>>> >>>> On 12/11/2018 03:21, Prasanta Sadhukhan wrote: >>>>> Thanks Muneer for the confirmation. Gentle reminder to review >>>>> which is pending for over a month now. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 24-Oct-18 3:13 PM, Muneer Kolarkunnu wrote: >>>>>> Hi Prasanta, >>>>>> >>>>>> I tested with provided binary and issue is resolved with this >>>>>> fix. Thanks for fixing this issue. >>>>>> >>>>>> Regards, >>>>>> Muneer >>>>>> >>>>>> -----Original Message----- >>>>>> From: Muneer Kolarkunnu >>>>>> Sent: Wednesday, October 24, 2018 12:00 PM >>>>>> To: Prasanta Sadhukhan ; Sergey >>>>>> Bylokhov ; swing-dev at openjdk.java.net >>>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : >>>>>> java.lang.AssertionError: cannot find the internal frame >>>>>> >>>>>> Hi Prasanta, >>>>>> >>>>>> I can verify it if you can share a binary with fix. >>>>>> >>>>>> Regards, >>>>>> Muneer >>>>>> >>>>>> -----Original Message----- >>>>>> From: Prasanta Sadhukhan >>>>>> Sent: Wednesday, October 24, 2018 11:41 AM >>>>>> To: Sergey Bylokhov ; >>>>>> swing-dev at openjdk.java.net; ABDUL.KOLARKUNNU >>>>>> >>>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : >>>>>> java.lang.AssertionError: cannot find the internal frame >>>>>> >>>>>> Hi Muneer, >>>>>> >>>>>> Could you check (as a submitter) if the proposed fix works in >>>>>> your jemmy environment? It seems to work for me with the command >>>>>> line you gave in JBS. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 22-Oct-18 11:24 AM, Prasanta Sadhukhan wrote: >>>>>>> Gentle reminder... >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 05-Oct-18 2:31 PM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> >>>>>>>> On 04-Oct-18 11:03 PM, Prasanta Sadhukhan wrote: >>>>>>>>> >>>>>>>>> On 04-Oct-18 10:44 PM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> On 04-Oct-18 10:29 PM, Sergey Bylokhov wrote: >>>>>>>>>>> On 04/10/2018 09:44, Prasanta Sadhukhan wrote: >>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>> >>>>>>>>>>>> Yes, this method should return JInternalFrame but there is >>>>>>>>>>>> no way >>>>>>>>>>>> to get JinternalFrame object from BasicInternalFrameTitlePane >>>>>>>>>>>> currently. >>>>>>>>>>> But why it is not possible? The BasicInternalFrameTitlePane >>>>>>>>>>> is a >>>>>>>>>>> title of the internalFrame and it looks like it should be >>>>>>>>>>> located >>>>>>>>>>> somewhere inside the internalFrame, isn't it? >>>>>>>>>>> >>>>>>>>>> BasicInternalTitlePane has a protected variable of >>>>>>>>>> JInternalFrame >>>>>>>>>> object and there is no public method to access that so that's >>>>>>>>>> why I >>>>>>>>>> told it is not currently possible unless we add a public >>>>>>>>>> method in >>>>>>>>>> this Basic* class, if I understand it correctly. Let me know >>>>>>>>>> if it >>>>>>>>>> can be accessed some other way. >>>>>>>>>> >>>>>>>>> JInternalFrame.getUI().getNorthPane() probably might give >>>>>>>>> BasicInternalTitlePane object but I do not think we can get >>>>>>>>> viceversa, ie get JInternalFrame object from >>>>>>>>> BasicInternalTitlePane. >>>>>>>> I have improved the code to get JInternalFrame from >>>>>>>> BasicInternalFrameTitlePane, as you have suggested >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>>> This Metacity class has the provision of accepting null >>>>>>>>>>> value from >>>>>>>>>>> this method >>>>>>>>>>>> and this assertion problem is caused only when we ran with >>>>>>>>>>>> "esa" >>>>>>>>>>>> [to enable assertion]. The submitter has not mentioned >>>>>>>>>>>> there is >>>>>>>>>>>> any failure if we run the without esa, so I have only done >>>>>>>>>>>> away >>>>>>>>>>>> with the wrong assertion for BasicInternalFrameTitlePane. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>> On 04-Oct-18 9:43 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>> Can you please clarify this code a little bit. As far as I >>>>>>>>>>>>> understand this method should return the JInternalFrame, >>>>>>>>>>>>> which >>>>>>>>>>>>> should be accessed via the comp passed to this method. This >>>>>>>>>>>>> method already has this check: >>>>>>>>>>>>> ???????? if (comp.getParent() instanceof >>>>>>>>>>>>> BasicInternalFrameTitlePane) { >>>>>>>>>>>>> ???????????? comp = comp.getParent(); >>>>>>>>>>>>> ???????? } >>>>>>>>>>>>> >>>>>>>>>>>>> So maybe we can improve it to fetch the JInternalFrame >>>>>>>>>>>>> from the >>>>>>>>>>>>> BasicInternalFrameTitlePane or from another class passed >>>>>>>>>>>>> to this >>>>>>>>>>>>> method? >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/10/2018 07:35, Prasanta Sadhukhan wrote: >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review a cleanup of the code where wrong assertion is >>>>>>>>>>>>>> used when Component is an instance of >>>>>>>>>>>>>> BasicInternalFrameTitlePane. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now, BasicInternalFrameTitlePane is extended from JComponent >>>>>>>>>>>>>> and not from JInternalFrame so it will never satisfy the >>>>>>>>>>>>>> if-else condition if "Component is instanceof >>>>>>>>>>>>>> BasicInternalFrameTitlePane", so proposed fix is to >>>>>>>>>>>>>> assert only >>>>>>>>>>>>>> if the component is not an instance of >>>>>>>>>>>>>> BasicInternalFrameTitlePane >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff -r d96a607e9594 >>>>>>>>>>>>>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Meta >>>>>>>>>>>>>> >>>>>>>>>>>>>> city.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> a/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>>> >>>>>>>>>>>>>> tacity.java >>>>>>>>>>>>>> Tue Sep 18 18:32:03 2018 -0700 >>>>>>>>>>>>>> +++ >>>>>>>>>>>>>> b/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>>> >>>>>>>>>>>>>> tacity.java >>>>>>>>>>>>>> Thu Oct 04 19:53:10 2018 +0530 >>>>>>>>>>>>>> @@ -337,7 +337,9 @@ >>>>>>>>>>>>>> ?????????? } else if (comp instanceof >>>>>>>>>>>>>> JInternalFrame.JDesktopIcon) { >>>>>>>>>>>>>> ?????????????? return >>>>>>>>>>>>>> ((JInternalFrame.JDesktopIcon)comp).getInternalFrame(); >>>>>>>>>>>>>> ?????????? } >>>>>>>>>>>>>> -??????? assert false : "cannot find the internal frame"; >>>>>>>>>>>>>> +?????? if (!(comp instanceof >>>>>>>>>>>>>> BasicInternalFrameTitlePane)) { >>>>>>>>>>>>>> +??????????? assert false : "cannot find the internal >>>>>>>>>>>>>> frame"; >>>>>>>>>>>>>> +?????? } >>>>>>>>>>>>>> ?????????? return null; >>>>>>>>>>>>>> ?????? } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> >>>>>>>>>>> >>>>> >>>> >>>> >>> >> >> > From prasanta.sadhukhan at oracle.com Tue May 21 06:48:35 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 21 May 2019 12:18:35 +0530 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> <5CE2EC30.1040304@oracle.com> <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> Message-ID: <65ee59fe-118e-a7e5-b957-95d48d8c84e9@oracle.com> Probably we can move this traversal code to javax.swing.SortingFocusTraversalPolicy#SwingContainerOrderFocusTraversalPolicy for this JToggleButton swing component to avoid this scepticism. Regards Prasanta On 21-May-19 1:36 AM, semyon.sadetsky at oracle.com wrote: > On 5/20/19 11:04 AM, Philip Race wrote: > >> Hi, >> >> I'm afraid I know next to nothing about the focus traversal >> code in Swing or AWT, but it smells very wrong to have >> such knowledge of a specific Swing component in the >> AWT focus code. > I don't see anything wrong here. You can find a lot of Swing component > specific code in java.awt.* implementations. This is not the first > Swing aware AWT class. > > --Semyon >> >> -phil. >> >> On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: >>> bugs: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153090 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8223788 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224149 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ >>> >>> The fix eliminates issues in JColorChooser dialog making it more >>> accessible by keyboard. See JBS for details. >>> >>> --Semyon >>> > From prasanta.sadhukhan at oracle.com Tue May 21 08:49:18 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 21 May 2019 14:19:18 +0530 Subject: [13] RFR JDK-8214702:Wrong text position for whitespaced string in printing Swing text In-Reply-To: References: <5C4DFE39.9070305@oracle.com> <944fa833-469b-d31f-038d-2eef4a6bf7d3@oracle.com> <5C4E8D54.9090807@oracle.com> <8eb983e6-89d8-6cb4-7a32-270c1062ae8e@oracle.com> <8b3e423f-55ef-63a6-eca1-481a8e29be4c@oracle.com> <9a1ceec7-d4e7-de3b-0033-90689095278a@oracle.com> <5C74E422.4030008@oracle.com> <74c9e459-1b84-2bad-5c1a-c8dd944a7fdd@oracle.com> <9b63748a-f815-dad5-92f1-e12d53565a1a@oracle.com> Message-ID: <98a6e932-148b-9f20-0996-2e94d147ae48@oracle.com> Thanks for your review. I have run the relevant jck/regression test and I do not observe any new issues. As for long lines, I will split it while pushing. Regards Prasanta On 20-May-19 11:39 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > This version looks fine, but I have two comments: > ?- Please split the long lines in the fix. > ?- Can you please confirm that the tests(jck/regression) are passed on > the latest version, and there are no new issues. > > On 16/05/2019 22:05, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> >> On 16-May-19 9:13 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> Should not we use the real "screen" FontRenderContext instead of >>> "DEFAULT_FRC"? >> Yes, I guess it was mentioned in one of the review comment earliter, >> that it may not be the cause of this problem, but it needs to be >> changed. >>> Did you check do we need to update the similat cases in the same >>> class(we use getJustifiedLayout() 4 times mostly in the same code >>> pattern)? >> Might as well. I updated 3 of them and the 4th one is with >> AttributeCharaterIterator (and not dealing with String as such unlike >> other 3) so did not update. >> Modified webrev with the change >> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.5/ >> >> Regards >> Prasanta >>> >>> On 15/05/2019 22:23, Prasanta Sadhukhan wrote: >>>> Not sure if you are saying it's ok to "push"? I guess I need a 2nd >>>> reviewer if you are ok with this. >>>> >>>> Regards >>>> Prasanta >>>> On 16-May-19 12:01 AM, Phil Race wrote: >>>>> OK. Let's try that. I am sure it is still going to be non-ideal in >>>>> a couple of ways >>>>> 1) where printed is shorter than screenwidth and we don't adjust, >>>>> there may >>>>> be space after the text and before the "edge" of the component, >>>>> but at least >>>>> there's no clipping and the text should look natural initself >>>>> >>>>> 2) Where printed is longer than screenwidth and we do adjust we >>>>> may still >>>>> run into similar cases as this .. >>>>> >>>>> -phil. >>>>> >>>>> On 4/19/19 12:56 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 18-Apr-19 12:31 AM, Phil Race wrote: >>>>>>> >>>>>>> >>>>>>> On 4/16/19 3:38 AM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> It seems screenWidth or "advance of the string at >>>>>>>> screen-resolution" is 533 whereas string advance calculated >>>>>>>> using printer fontmetrics is 503 >>>>>>>> >>>>>>>> Now, TextLine#getJustifiedLine() [called from >>>>>>>> TextLayout.getJustifiedLayout] again calculates >>>>>>>> "justifyAdvance" for TextLineComponent which comes out to be >>>>>>>> 503,then it calculates >>>>>>>> the actual justification "delta" by subtracting justifyAdvance >>>>>>>> from screenWidth which is 533-503=30 and it then does >>>>>>>> TextJustifier.justify(delta) >>>>>>>> which calculates the amount by which each side of each glyph >>>>>>>> should grow or shrink. >>>>>>>> >>>>>>>> Then TextLine.getJustifiedLine() applies this value by calling >>>>>>>> TextLineComponent.applyJustificationDeltas() where it >>>>>>>> ?handle whitespace by modifying advance but? handle everything >>>>>>>> else by modifying position before and after, >>>>>>>> ?so "spaces" seem to grow in size resulting in shifting of text >>>>>>>> with whitespaces. >>>>>>> >>>>>>> The spaces being used to add needed or absorb surplus space is >>>>>>> what I understood the current code to be doing, >>>>>>> >>>>>>> However I am not sure what you mean by this :- >>>>>>> "but? handle everything else by modifying position before and >>>>>>> after," >>>>>>> >>>>>>> Code run through text layout will always have glyph positions >>>>>>> assigned, so I would suppose modifying the position >>>>>>> is how the spaces were handled too .. and of course this means >>>>>>> running through all preceding glyphs to make >>>>>>> it consistent .. and I thought it was only adjusting the spaces, >>>>>>> so what is "everything else" >>>>>> It seems when TextLineComponent.applyJustificationDeltas() is >>>>>> called, ExtendedTextSourceLabel.applyJustificationDeltas() >>>>>> handles that >>>>>> http://hg.openjdk.java.net/jdk/client/file/dc6c5c53669b/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#l1015 >>>>>> >>>>>> where it handles "whitespace" a bit different (if block) from >>>>>> other glyph (else block) where advance is is not considered, >>>>>> which is also conveyed? in the comment @1011 >>>>>>>> >>>>>>>> ?Since it was mentioned in TextLayout.getJustifiedLayout() that >>>>>>>> "? For best results, justificationWidth should not be too >>>>>>>> different from the current advance of the line" >>>>>>> >>>>>>> So for "best" results don't try to adjust a string that's 3 >>>>>>> words and 80 pixels to a 500 pixel width. >>>>>>> >>>>>>>> I am proposing a fix to conditionally call >>>>>>>> TextLayout.getJustifiedLayout() only if the difference between >>>>>>>> justificationWidth and advance with for printer is more than 10. >>>>>>>> >>>>>>> >>>>>>> I had proposed investigating what happens if you simply don't >>>>>>> use justification when the text will fit. >>>>>>> Maybe you are refining that but I am not sure about the details. >>>>>>> 10 is one arbitrary number and is not proportional to the length >>>>>>> - which is what I would be >>>>>>> thinking about first in succh an approach >>>>>>> And I am not even sure you mean what you say. >>>>>>> You say "more" than 10, yet your code implements "less" than 10. >>>>>> It was a typo in mail. >>>>>> Modified? webrev to not use justification if string width of text >>>>>> is within screenWidth >>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.4/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> And moreover its an absolute value you are using, which >>>>>>> re-introduces the clipping problem, doesn't it ? >>>>>>> ie you are purely looking at the difference and it isn't what I >>>>>>> has proposed and I thought you were trying. >>>>>>> >>>>>>> -phil >>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 26-Feb-19 12:30 PM, Philip Race wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/25/19, 10:21 PM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> Thanks Phil for review. So, you are doubting it will regress >>>>>>>>>> swing printing tests. As you told earlier, I have ran the >>>>>>>>>> following regression test with this fix >>>>>>>>>> >>>>>>>>> >>>>>>>>> It may not regress a test if the test is not being tested >>>>>>>>> under the >>>>>>>>> same conditions for which it is created but I am telling you >>>>>>>>> for a >>>>>>>>> fact that the fix is wrong. screenWidth should be "width on >>>>>>>>> the screen" >>>>>>>>>> >>>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-6488219 The bug >>>>>>>>>> above is covered by java/awt/print/PrinterJob/SwingUIText.java) >>>>>>>>>> and I did not notice any regression. Any other test we have >>>>>>>>>> for swing printing that we can run? >>>>>>>>>> >>>>>>>>> >>>>>>>>> No idea which tests will show this today but I know it is an >>>>>>>>> issue. >>>>>>>>> No way we can push this and then just wait for the complaints. >>>>>>>>> >>>>>>>>>> >>Previously we were using DEFAULT_FRC to make it a screen >>>>>>>>>> width which except for maybe needing to be updated for hi-dpi >>>>>>>>>> screens is what we want. >>>>>>>>>> This issue was there from jdk1.6. If it is for hidpi screen, >>>>>>>>>> we would have seen it from jdk9 onwards where we supported >>>>>>>>>> hidpi, no? >>>>>>>>> >>>>>>>>> What I am saying here is that DEFAULT_FRC means "screen frc" and >>>>>>>>> I think that should have been updated in 1.9 but was missed >>>>>>>>> because >>>>>>>>> it (hidpi for windows) was not a small or contained task. >>>>>>>>> This is an ancilliary observation of something that should be >>>>>>>>> looked >>>>>>>>> at entirely independent of this bug. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 26-Feb-19 3:25 AM, Phil Race wrote: >>>>>>>>>>> The current fix confused me for a while as I could not see >>>>>>>>>>> how it was >>>>>>>>>>> at all different than the existing code, since I can't >>>>>>>>>>> imagine when we'd >>>>>>>>>>> ever take the "else" branch here : >>>>>>>>>>> 533 TextLayout layout; >>>>>>>>>>> 534 if (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>> 535 layout = createTextLayout(c, text, g2d.getFont(), >>>>>>>>>>> deviceFRC); >>>>>>>>>>> 536 } else { >>>>>>>>>>> 537 layout = createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>>> 538 } Eventually when walking through it I noticed this 531 >>>>>>>>>>> FontMetrics fm = g2d.getFontMetrics(); >>>>>>>>>>> 532 float screenWidth = SwingUtilities2.stringWidth(c, fm >>>>>>>>>>> ,trimmedText); >>>>>>>>>>> >>>>>>>>>>> "fm" from line 532 is getting a FontMetrics from the PRINTER >>>>>>>>>>> - ie the scaled FontRenderContext. >>>>>>>>>>> It then uses this to calculate the advance width for such a >>>>>>>>>>> case - ie the printer >>>>>>>>>>> but then *assigns it to a variable called screenWidth*. >>>>>>>>>>> >>>>>>>>>>> Previously we were using DEFAULT_FRC to make it a screen >>>>>>>>>>> width which except >>>>>>>>>>> for maybe needing to be updated for hi-dpi screens is what >>>>>>>>>>> we want. >>>>>>>>>>> >>>>>>>>>>> So in the updated proposed fix the wrong width is passed to >>>>>>>>>>> getJustifiedLayout(). >>>>>>>>>>> >>>>>>>>>>> This may not matter here because there is plenty of space, >>>>>>>>>>> but in other cases >>>>>>>>>>> Swing printing will be clipped as a result. And there were >>>>>>>>>>> many, many, bug reports about >>>>>>>>>>> that. Which is why the code is laying out to the screenwidth >>>>>>>>>>> because that is where the >>>>>>>>>>> UI component size available came from. Buttons & Label text >>>>>>>>>>> are the typical cases where >>>>>>>>>>> this showed up. >>>>>>>>>>> >>>>>>>>>>> There maybe other things to change, as well but the >>>>>>>>>>> incorrect screenWidth is the >>>>>>>>>>> main problem I see here. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 2/25/19 12:05 AM, Prasanta Sadhukhan wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 21-Feb-19 4:50 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>> On 13/02/2019 22:53, Prasanta Sadhukhan wrote: >>>>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I believe drawChars() also has same printing issue [and >>>>>>>>>>>>>> should be changed like modified drawString()] but I am >>>>>>>>>>>>>> not able to test it as reproducer testcase uses JLabel >>>>>>>>>>>>>> whose constructor can only accept "String" and not char[] >>>>>>>>>>>>>> so I can only test drawString(). Using drawChars() >>>>>>>>>>>>>> implementation in drawString() still reproduces the issue. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible temporary replace the call to drawString() >>>>>>>>>>>>> by the drawChars(), to check how drawChars() will work? >>>>>>>>>>>> As I told, it behaves similarly to unmodified drawString >>>>>>>>>>>> and the issue can still be seen. I think we should commit >>>>>>>>>>>> this drawString() change in this fix and I can open another >>>>>>>>>>>> bug to investigate drawChars() impl and reproducer. Will >>>>>>>>>>>> that be fine? >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>>> or probably we can implement drawChars() on top of >>>>>>>>>>>>> drawString()? >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>> On 14-Feb-19 4:12 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I modified the fix to use deviceFRC if not compatible >>>>>>>>>>>>>>>> and in sync with the comment which says "obtain a >>>>>>>>>>>>>>>> TextLayout with advances for the printer graphics FRC" >>>>>>>>>>>>>>>> I used SwingUtilies2.getStringWidth() which calculates >>>>>>>>>>>>>>>> the advances of the string if text layouting is used. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.2/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you please take a look to the existed drawChars() >>>>>>>>>>>>>>> method, which is implemented in the similar way as >>>>>>>>>>>>>>> drawStringImpl() and new version of drawString(), but >>>>>>>>>>>>>>> they have some small difference. Why we cannot use the >>>>>>>>>>>>>>> same logic? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example in the drawChars: >>>>>>>>>>>>>>> ========= >>>>>>>>>>>>>>> ??????????? FontRenderContext deviceFontRenderContext = >>>>>>>>>>>>>>> g2d. >>>>>>>>>>>>>>> getFontRenderContext(); >>>>>>>>>>>>>>> ??????????? FontRenderContext frc = >>>>>>>>>>>>>>> getFontRenderContext(c); >>>>>>>>>>>>>>> ??????????? if (frc != null && >>>>>>>>>>>>>>> !isFontRenderContextPrintCompatible >>>>>>>>>>>>>>> (deviceFontRenderContext, frc)) { >>>>>>>>>>>>>>> ???????????????? String text = new String(data, offset, >>>>>>>>>>>>>>> length); >>>>>>>>>>>>>>> ???????????????? TextLayout layout = new >>>>>>>>>>>>>>> TextLayout(text, g2d.getFont(), >>>>>>>>>>>>>>> deviceFontRenderContext); >>>>>>>>>>>>>>> ???????????????? String trimmedText = >>>>>>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>>>>>> ???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>>>>> ???????????????????? float screenWidth = >>>>>>>>>>>>>>> (float)g2d.getFont(). >>>>>>>>>>>>>>> getStringBounds(trimmedText, frc).getWidth(); >>>>>>>>>>>>>>> ???????????????????? layout = >>>>>>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ========== >>>>>>>>>>>>>>> Similar but not the same logic in the fix: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ?524???????????????? FontRenderContext frc = >>>>>>>>>>>>>>> getFontRenderContext(c); >>>>>>>>>>>>>>> ?525???????????????? if (frc.isAntiAliased() || >>>>>>>>>>>>>>> frc.usesFractionalMetrics()) { >>>>>>>>>>>>>>> ?526???????????????????? frc = new >>>>>>>>>>>>>>> FontRenderContext(frc.getTransform(), false, false); >>>>>>>>>>>>>>> ?527???????????????? } >>>>>>>>>>>>>>> ?528???????????????? FontRenderContext deviceFRC = >>>>>>>>>>>>>>> g2d.getFontRenderContext(); >>>>>>>>>>>>>>> ?529???????????????? String trimmedText = >>>>>>>>>>>>>>> trimTrailingSpaces(text); >>>>>>>>>>>>>>> ?530???????????????? if (!trimmedText.isEmpty()) { >>>>>>>>>>>>>>> ?531???????????????????? FontMetrics fm = >>>>>>>>>>>>>>> g2d.getFontMetrics(); >>>>>>>>>>>>>>> ?532???????????????????? float screenWidth = >>>>>>>>>>>>>>> SwingUtilities2.stringWidth(c, fm ,trimmedText); >>>>>>>>>>>>>>> ?533???????????????????? TextLayout layout; >>>>>>>>>>>>>>> ?534???????????????????? if >>>>>>>>>>>>>>> (!isFontRenderContextPrintCompatible(frc, deviceFRC)) { >>>>>>>>>>>>>>> ?535???????????????????????? layout = >>>>>>>>>>>>>>> createTextLayout(c, text, g2d.getFont(), deviceFRC); >>>>>>>>>>>>>>> ?536???????????????????? } else { >>>>>>>>>>>>>>> ?537???????????????????????? layout = >>>>>>>>>>>>>>> createTextLayout(c, text, g2d.getFont(), frc); >>>>>>>>>>>>>>> ?538???????????????????? } >>>>>>>>>>>>>>> ?540???????????????????? layout = >>>>>>>>>>>>>>> layout.getJustifiedLayout(screenWidth); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From philip.race at oracle.com Wed May 22 18:55:48 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 22 May 2019 11:55:48 -0700 Subject: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame In-Reply-To: <5a191005-c9c5-974b-8237-bcde32db9ba1@oracle.com> References: <22a77e7c-4d6e-d300-6412-7a032a9e4258@oracle.com> <440dc24e-b011-35af-a6b1-86d036334070@oracle.com> <2278bf48-ff56-1775-1652-fff040e6edce@oracle.com> <641d40c7-7db6-bbcf-653e-a2513c6e57a3@oracle.com> <837dc5d0-430b-44ba-aad8-9c9e070bc226@default> <5a87e5d5-091b-4787-9dc3-2a01011ae604@default> <9d5ed15d-30e1-aa9d-b0e1-464d73c09d71@oracle.com> <59cffc7e-cafe-d5c0-f6d7-25c858c36d6d@oracle.com> <142c8228-8abe-8d75-4323-4bcbd1efeab3@oracle.com> <5a191005-c9c5-974b-8237-bcde32db9ba1@oracle.com> Message-ID: <5c424365-ef91-62f3-d328-fe7e681582fc@oracle.com> This would be fine with me. -phil. On 5/20/19 2:49 AM, Prasanta Sadhukhan wrote: > Hi Sergey, > > I have unified approach to get InternalFrame from button. Since > updateFrameGeometry() was called with > "javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton" > component whose parent does not have internal frame,it was asserting > so as done in paintButtonBackground(), updateFrameGeometry() is > modified to check if the comp is JButton ,then extract the titlePane > and use titlePane's parent to find internalFrame. > http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.2/ > > Regards > Prasanta > On 14-Nov-18 2:01 AM, Sergey Bylokhov wrote: >> On 13/11/2018 01:25, Prasanta Sadhukhan wrote: >>> findInternalFrame() is called from paintButtonBackground(), >>> paintFrameBorder() and updateFrameGeometry() >>> but in paintButtonBackground() and paintFrameBorder() >>> updateFrameGeometry() is called before findInternalFrame() so >>> basically it is updateFrameGeometry()#findInternalFrame that is get >>> called during assertion. >> >> But in these cases it is used in a little bit different ways, take a >> look to the paintButtonBackground(). >> >> ?- In first line we will call updateFrameGeometry(), and inside: >> ?? 1. We will call "comp = context.getComponent()" >> ?? 2. Then will try to find titlePane using findChild() -? I guess it >> will always fail for button. >> ?? 3. Then we pass the comp to the findInternalFrame >> ?- After that we return to the paintButtonBackground and: >> ?? 1. We will call "button = context.getComponent()" >> ?? 2. We will take a "titlePane = (JComponent)button.getParent()"; >> NOTE: It is different that in "updateFrameGeometry" >> ?? 3. Then we will take titlePaneParent from the titlepane >> ?? 4. Then we pass the titlePaneParent to the findInternalFrame >> >> Note that context in both cases is the same, but we pass different >> components to findInternalFrame. >> I tried to move the call of findInternalFrame in the >> paintButtonBackground before >> updateFrameGeometry(to compare the second and first approaches) and >> it is completes successfully. So it >> seems we need to unify approach on how we get a InternalFrame from >> the button. >> >> Can you please check this. >> >> >>> >>> During assertion, >>> paintButtonBackground() is called which calls updateFrameGeometry() >>> with >>> comp=javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton[InternalFrameTitlePane.iconifyButton,240,3,18x18,alignmentX=0.0,alignmentY=0.5,border=,flags=290,maximumSize=,minimumSize=, >>> >>> preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=false,pressedIcon=, >>> >>> rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true] >>> >>> >>> and comp's parent is >>> javax.swing.plaf.synth.SynthInternalFrameTitlePane[InternalFrame.northPane,0,0,300x24,layout=com.sun.java.swing.plaf.gtk.Metacity$TitlePaneLayout, >>> >>> alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 26e3b5d8,flags=8388610,maximumSize=,minimumSize=,preferredSize=] >>> >>> >>> so "comp.getParent() instanceof BasicInternalFrameTitlePane" check >>> is satisfied so "comp" becomes SynthInternalFrameTitlePane. >>> >>> Since SynthInternalFrameTitlePane is not an instance of >>> JInternalFrame nor JInternalFrame.JDesktopIcon, it results in >>> assertion, so as a fix I extracted the internalframe from >>> BasicInternalFrameTitlePane. >>> >>> Regards >>> Prasanta >>> On 13-Nov-18 7:56 AM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> >>>> Can you please provide more details on the hierarchy of components >>>> which trigger this assertion. >>>> >>>> This method is used in 3 places, in two places we try to find the >>>> child "InternalFrame.northPane" >>>> and pass it to the findInternalFrame(). But in one place we take a >>>> "button.getParent()", then pass >>>> it to the findInternalFrame(), and take the parent one more time: >>>> "comp.getParent() instanceof BasicInternalFrameTitlePane" >>>> >>>> Perhaps one call to "getParent()" is superfluous? What is the >>>> hierarchy of panes/buttons/internal frames? >>>> >>>> >>>> On 12/11/2018 03:21, Prasanta Sadhukhan wrote: >>>>> Thanks Muneer for the confirmation. Gentle reminder to review >>>>> which is pending for over a month now. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 24-Oct-18 3:13 PM, Muneer Kolarkunnu wrote: >>>>>> Hi Prasanta, >>>>>> >>>>>> I tested with provided binary and issue is resolved with this >>>>>> fix. Thanks for fixing this issue. >>>>>> >>>>>> Regards, >>>>>> Muneer >>>>>> >>>>>> -----Original Message----- >>>>>> From: Muneer Kolarkunnu >>>>>> Sent: Wednesday, October 24, 2018 12:00 PM >>>>>> To: Prasanta Sadhukhan ; Sergey >>>>>> Bylokhov ; swing-dev at openjdk.java.net >>>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : >>>>>> java.lang.AssertionError: cannot find the internal frame >>>>>> >>>>>> Hi Prasanta, >>>>>> >>>>>> I can verify it if you can share a binary with fix. >>>>>> >>>>>> Regards, >>>>>> Muneer >>>>>> >>>>>> -----Original Message----- >>>>>> From: Prasanta Sadhukhan >>>>>> Sent: Wednesday, October 24, 2018 11:41 AM >>>>>> To: Sergey Bylokhov ; >>>>>> swing-dev at openjdk.java.net; ABDUL.KOLARKUNNU >>>>>> >>>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : >>>>>> java.lang.AssertionError: cannot find the internal frame >>>>>> >>>>>> Hi Muneer, >>>>>> >>>>>> Could you check (as a submitter) if the proposed fix works in >>>>>> your jemmy environment? It seems to work for me with the command >>>>>> line you gave in JBS. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 22-Oct-18 11:24 AM, Prasanta Sadhukhan wrote: >>>>>>> Gentle reminder... >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 05-Oct-18 2:31 PM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> >>>>>>>> On 04-Oct-18 11:03 PM, Prasanta Sadhukhan wrote: >>>>>>>>> >>>>>>>>> On 04-Oct-18 10:44 PM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> On 04-Oct-18 10:29 PM, Sergey Bylokhov wrote: >>>>>>>>>>> On 04/10/2018 09:44, Prasanta Sadhukhan wrote: >>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>> >>>>>>>>>>>> Yes, this method should return JInternalFrame but there is >>>>>>>>>>>> no way >>>>>>>>>>>> to get JinternalFrame object from BasicInternalFrameTitlePane >>>>>>>>>>>> currently. >>>>>>>>>>> But why it is not possible? The BasicInternalFrameTitlePane >>>>>>>>>>> is a >>>>>>>>>>> title of the internalFrame and it looks like it should be >>>>>>>>>>> located >>>>>>>>>>> somewhere inside the internalFrame, isn't it? >>>>>>>>>>> >>>>>>>>>> BasicInternalTitlePane has a protected variable of >>>>>>>>>> JInternalFrame >>>>>>>>>> object and there is no public method to access that so that's >>>>>>>>>> why I >>>>>>>>>> told it is not currently possible unless we add a public >>>>>>>>>> method in >>>>>>>>>> this Basic* class, if I understand it correctly. Let me know >>>>>>>>>> if it >>>>>>>>>> can be accessed some other way. >>>>>>>>>> >>>>>>>>> JInternalFrame.getUI().getNorthPane() probably might give >>>>>>>>> BasicInternalTitlePane object but I do not think we can get >>>>>>>>> viceversa, ie get JInternalFrame object from >>>>>>>>> BasicInternalTitlePane. >>>>>>>> I have improved the code to get JInternalFrame from >>>>>>>> BasicInternalFrameTitlePane, as you have suggested >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>>> This Metacity class has the provision of accepting null >>>>>>>>>>> value from >>>>>>>>>>> this method >>>>>>>>>>>> and this assertion problem is caused only when we ran with >>>>>>>>>>>> "esa" >>>>>>>>>>>> [to enable assertion]. The submitter has not mentioned >>>>>>>>>>>> there is >>>>>>>>>>>> any failure if we run the without esa, so I have only done >>>>>>>>>>>> away >>>>>>>>>>>> with the wrong assertion for BasicInternalFrameTitlePane. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>> On 04-Oct-18 9:43 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>> Can you please clarify this code a little bit. As far as I >>>>>>>>>>>>> understand this method should return the JInternalFrame, >>>>>>>>>>>>> which >>>>>>>>>>>>> should be accessed via the comp passed to this method. This >>>>>>>>>>>>> method already has this check: >>>>>>>>>>>>> ???????? if (comp.getParent() instanceof >>>>>>>>>>>>> BasicInternalFrameTitlePane) { >>>>>>>>>>>>> ???????????? comp = comp.getParent(); >>>>>>>>>>>>> ???????? } >>>>>>>>>>>>> >>>>>>>>>>>>> So maybe we can improve it to fetch the JInternalFrame >>>>>>>>>>>>> from the >>>>>>>>>>>>> BasicInternalFrameTitlePane or from another class passed >>>>>>>>>>>>> to this >>>>>>>>>>>>> method? >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/10/2018 07:35, Prasanta Sadhukhan wrote: >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review a cleanup of the code where wrong assertion is >>>>>>>>>>>>>> used when Component is an instance of >>>>>>>>>>>>>> BasicInternalFrameTitlePane. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now, BasicInternalFrameTitlePane is extended from JComponent >>>>>>>>>>>>>> and not from JInternalFrame so it will never satisfy the >>>>>>>>>>>>>> if-else condition if "Component is instanceof >>>>>>>>>>>>>> BasicInternalFrameTitlePane", so proposed fix is to >>>>>>>>>>>>>> assert only >>>>>>>>>>>>>> if the component is not an instance of >>>>>>>>>>>>>> BasicInternalFrameTitlePane >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff -r d96a607e9594 >>>>>>>>>>>>>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Meta >>>>>>>>>>>>>> >>>>>>>>>>>>>> city.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> a/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>>> >>>>>>>>>>>>>> tacity.java >>>>>>>>>>>>>> Tue Sep 18 18:32:03 2018 -0700 >>>>>>>>>>>>>> +++ >>>>>>>>>>>>>> b/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>>> >>>>>>>>>>>>>> tacity.java >>>>>>>>>>>>>> Thu Oct 04 19:53:10 2018 +0530 >>>>>>>>>>>>>> @@ -337,7 +337,9 @@ >>>>>>>>>>>>>> ?????????? } else if (comp instanceof >>>>>>>>>>>>>> JInternalFrame.JDesktopIcon) { >>>>>>>>>>>>>> ?????????????? return >>>>>>>>>>>>>> ((JInternalFrame.JDesktopIcon)comp).getInternalFrame(); >>>>>>>>>>>>>> ?????????? } >>>>>>>>>>>>>> -??????? assert false : "cannot find the internal frame"; >>>>>>>>>>>>>> +?????? if (!(comp instanceof >>>>>>>>>>>>>> BasicInternalFrameTitlePane)) { >>>>>>>>>>>>>> +??????????? assert false : "cannot find the internal >>>>>>>>>>>>>> frame"; >>>>>>>>>>>>>> +?????? } >>>>>>>>>>>>>> ?????????? return null; >>>>>>>>>>>>>> ?????? } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> >>>>>>>>>>> >>>>> >>>> >>>> >>> >> >> > From semyon.sadetsky at oracle.com Wed May 22 20:27:56 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Wed, 22 May 2019 13:27:56 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails Message-ID: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8196096 webrev: http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.00/ This is a fix for an unstable test: - inside EDT execution is ensured where necessary. - To pass on the mac platform the check for lightweight popup is excluded and the taskbar overlapping Swing property is enabled. --Semyon From Sergey.Bylokhov at oracle.com Wed May 22 21:29:52 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 May 2019 14:29:52 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> Message-ID: <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> Hi, Semyon. Why it s necessary to change the adjustPopupLocationToFit value? why on macOS it does not work by default like on others platforms? If I read an initial bug 6580930 correctly there was an intention that HW popup should be able to overlap taskbar by default and I assume it works this way on win/lin(or it does not work)? On 22/05/2019 13:27, semyon.sadetsky at oracle.com wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8196096 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.00/ > > This is a fix for an unstable test: > > - inside EDT execution is ensured where necessary. > > - To pass on the mac platform the check for lightweight popup is excluded and the taskbar overlapping Swing property is enabled. > > > --Semyon > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed May 22 21:43:37 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 May 2019 14:43:37 -0700 Subject: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame In-Reply-To: References: <22a77e7c-4d6e-d300-6412-7a032a9e4258@oracle.com> <440dc24e-b011-35af-a6b1-86d036334070@oracle.com> <2278bf48-ff56-1775-1652-fff040e6edce@oracle.com> <641d40c7-7db6-bbcf-653e-a2513c6e57a3@oracle.com> <837dc5d0-430b-44ba-aad8-9c9e070bc226@default> <5a87e5d5-091b-4787-9dc3-2a01011ae604@default> <9d5ed15d-30e1-aa9d-b0e1-464d73c09d71@oracle.com> <59cffc7e-cafe-d5c0-f6d7-25c858c36d6d@oracle.com> <142c8228-8abe-8d75-4323-4bcbd1efeab3@oracle.com> <5a191005-c9c5-974b-8237-bcde32db9ba1@oracle.com> Message-ID: <77bcb281-7587-f134-73d7-03bfc1aa37f5@oracle.com> Looks fine. On 20/05/2019 22:21, Prasanta Sadhukhan wrote: > PS: Since this is causing few tests to fail in headful nightly, I wish to get this reviewed and committed soon. > > Regards > Prasanta > On 20-May-19 3:19 PM, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> I have unified approach to get InternalFrame from button. Since updateFrameGeometry() was called with "javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton" component whose parent does not have internal frame,it was asserting >> so as done in paintButtonBackground(), updateFrameGeometry() is modified to check if the comp is JButton ,then extract the titlePane and use titlePane's parent to find internalFrame. >> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.2/ >> >> Regards >> Prasanta >> On 14-Nov-18 2:01 AM, Sergey Bylokhov wrote: >>> On 13/11/2018 01:25, Prasanta Sadhukhan wrote: >>>> findInternalFrame() is called from paintButtonBackground(), paintFrameBorder() and updateFrameGeometry() >>>> but in paintButtonBackground() and paintFrameBorder() >>>> updateFrameGeometry() is called before findInternalFrame() so basically it is updateFrameGeometry()#findInternalFrame that is get called during assertion. >>> >>> But in these cases it is used in a little bit different ways, take a look to the paintButtonBackground(). >>> >>> ?- In first line we will call updateFrameGeometry(), and inside: >>> ?? 1. We will call "comp = context.getComponent()" >>> ?? 2. Then will try to find titlePane using findChild() -? I guess it will always fail for button. >>> ?? 3. Then we pass the comp to the findInternalFrame >>> ?- After that we return to the paintButtonBackground and: >>> ?? 1. We will call "button = context.getComponent()" >>> ?? 2. We will take a "titlePane = (JComponent)button.getParent()"; NOTE: It is different that in "updateFrameGeometry" >>> ?? 3. Then we will take titlePaneParent from the titlepane >>> ?? 4. Then we pass the titlePaneParent to the findInternalFrame >>> >>> Note that context in both cases is the same, but we pass different components to findInternalFrame. >>> I tried to move the call of findInternalFrame in the paintButtonBackground before >>> updateFrameGeometry(to compare the second and first approaches) and it is completes successfully. So it >>> seems we need to unify approach on how we get a InternalFrame from the button. >>> >>> Can you please check this. >>> >>> >>>> >>>> During assertion, >>>> paintButtonBackground() is called which calls updateFrameGeometry() with >>>> comp=javax.swing.plaf.basic.BasicInternalFrameTitlePane$NoFocusButton[InternalFrameTitlePane.iconifyButton,240,3,18x18,alignmentX=0.0,alignmentY=0.5,border=,flags=290,maximumSize=,minimumSize=, >>>> preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],paintBorder=true,paintFocus=false,pressedIcon=, >>>> rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=,defaultCapable=true] >>>> >>>> and comp's parent is >>>> javax.swing.plaf.synth.SynthInternalFrameTitlePane[InternalFrame.northPane,0,0,300x24,layout=com.sun.java.swing.plaf.gtk.Metacity$TitlePaneLayout, >>>> alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder at 26e3b5d8,flags=8388610,maximumSize=,minimumSize=,preferredSize=] >>>> >>>> so "comp.getParent() instanceof BasicInternalFrameTitlePane" check is satisfied so "comp" becomes SynthInternalFrameTitlePane. >>>> >>>> Since SynthInternalFrameTitlePane is not an instance of JInternalFrame nor JInternalFrame.JDesktopIcon, it results in assertion, so as a fix I extracted the internalframe from BasicInternalFrameTitlePane. >>>> >>>> Regards >>>> Prasanta >>>> On 13-Nov-18 7:56 AM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> >>>>> Can you please provide more details on the hierarchy of components which trigger this assertion. >>>>> >>>>> This method is used in 3 places, in two places we try to find the child "InternalFrame.northPane" >>>>> and pass it to the findInternalFrame(). But in one place we take a "button.getParent()", then pass >>>>> it to the findInternalFrame(), and take the parent one more time: >>>>> "comp.getParent() instanceof BasicInternalFrameTitlePane" >>>>> >>>>> Perhaps one call to "getParent()" is superfluous? What is the hierarchy of panes/buttons/internal frames? >>>>> >>>>> >>>>> On 12/11/2018 03:21, Prasanta Sadhukhan wrote: >>>>>> Thanks Muneer for the confirmation. Gentle reminder to review which is pending for over a month now. >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 24-Oct-18 3:13 PM, Muneer Kolarkunnu wrote: >>>>>>> Hi Prasanta, >>>>>>> >>>>>>> I tested with provided binary and issue is resolved with this fix. Thanks for fixing this issue. >>>>>>> >>>>>>> Regards, >>>>>>> Muneer >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Muneer Kolarkunnu >>>>>>> Sent: Wednesday, October 24, 2018 12:00 PM >>>>>>> To: Prasanta Sadhukhan ; Sergey Bylokhov ; swing-dev at openjdk.java.net >>>>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame >>>>>>> >>>>>>> Hi Prasanta, >>>>>>> >>>>>>> I can verify it if you can share a binary with fix. >>>>>>> >>>>>>> Regards, >>>>>>> Muneer >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Prasanta Sadhukhan >>>>>>> Sent: Wednesday, October 24, 2018 11:41 AM >>>>>>> To: Sergey Bylokhov ; swing-dev at openjdk.java.net; ABDUL.KOLARKUNNU >>>>>>> Subject: Re: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame >>>>>>> >>>>>>> Hi Muneer, >>>>>>> >>>>>>> Could you check (as a submitter) if the proposed fix works in your jemmy environment? It seems to work for me with the command line you gave in JBS. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 22-Oct-18 11:24 AM, Prasanta Sadhukhan wrote: >>>>>>>> Gentle reminder... >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 05-Oct-18 2:31 PM, Prasanta Sadhukhan wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04-Oct-18 11:03 PM, Prasanta Sadhukhan wrote: >>>>>>>>>> >>>>>>>>>> On 04-Oct-18 10:44 PM, Prasanta Sadhukhan wrote: >>>>>>>>>>> >>>>>>>>>>> On 04-Oct-18 10:29 PM, Sergey Bylokhov wrote: >>>>>>>>>>>> On 04/10/2018 09:44, Prasanta Sadhukhan wrote: >>>>>>>>>>>>> Hi Sergey, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, this method should return JInternalFrame but there is no way >>>>>>>>>>>>> to get JinternalFrame object from BasicInternalFrameTitlePane >>>>>>>>>>>>> currently. >>>>>>>>>>>> But why it is not possible? The BasicInternalFrameTitlePane is a >>>>>>>>>>>> title of the internalFrame and it looks like it should be located >>>>>>>>>>>> somewhere inside the internalFrame, isn't it? >>>>>>>>>>>> >>>>>>>>>>> BasicInternalTitlePane has a protected variable of JInternalFrame >>>>>>>>>>> object and there is no public method to access that so that's why I >>>>>>>>>>> told it is not currently possible unless we add a public method in >>>>>>>>>>> this Basic* class, if I understand it correctly. Let me know if it >>>>>>>>>>> can be accessed some other way. >>>>>>>>>>> >>>>>>>>>> JInternalFrame.getUI().getNorthPane() probably might give >>>>>>>>>> BasicInternalTitlePane object but I do not think we can get >>>>>>>>>> viceversa, ie get JInternalFrame object from BasicInternalTitlePane. >>>>>>>>> I have improved the code to get JInternalFrame from >>>>>>>>> BasicInternalFrameTitlePane, as you have suggested >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>>> This Metacity class has the provision of accepting null value from >>>>>>>>>>>> this method >>>>>>>>>>>>> and this assertion problem is caused only when we ran with "esa" >>>>>>>>>>>>> [to enable assertion]. The submitter has not mentioned there is >>>>>>>>>>>>> any failure if we run the without esa, so I have only done away >>>>>>>>>>>>> with the wrong assertion for BasicInternalFrameTitlePane. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> On 04-Oct-18 9:43 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>>> Can you please clarify this code a little bit. As far as I >>>>>>>>>>>>>> understand this method should return the JInternalFrame, which >>>>>>>>>>>>>> should be accessed via the comp passed to this method. This >>>>>>>>>>>>>> method already has this check: >>>>>>>>>>>>>> ???????? if (comp.getParent() instanceof >>>>>>>>>>>>>> BasicInternalFrameTitlePane) { >>>>>>>>>>>>>> ???????????? comp = comp.getParent(); >>>>>>>>>>>>>> ???????? } >>>>>>>>>>>>>> >>>>>>>>>>>>>> So maybe we can improve it to fetch the JInternalFrame from the >>>>>>>>>>>>>> BasicInternalFrameTitlePane or from another class passed to this >>>>>>>>>>>>>> method? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 04/10/2018 07:35, Prasanta Sadhukhan wrote: >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review a cleanup of the code where wrong assertion is >>>>>>>>>>>>>>> used when Component is an instance of BasicInternalFrameTitlePane. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now, BasicInternalFrameTitlePane is extended from JComponent >>>>>>>>>>>>>>> and not from JInternalFrame so it will never satisfy the >>>>>>>>>>>>>>> if-else condition if "Component is instanceof >>>>>>>>>>>>>>> BasicInternalFrameTitlePane", so proposed fix is to assert only >>>>>>>>>>>>>>> if the component is not an instance of >>>>>>>>>>>>>>> BasicInternalFrameTitlePane >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff -r d96a607e9594 >>>>>>>>>>>>>>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Meta >>>>>>>>>>>>>>> city.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> a/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>>>> tacity.java >>>>>>>>>>>>>>> Tue Sep 18 18:32:03 2018 -0700 >>>>>>>>>>>>>>> +++ >>>>>>>>>>>>>>> b/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me >>>>>>>>>>>>>>> tacity.java >>>>>>>>>>>>>>> Thu Oct 04 19:53:10 2018 +0530 >>>>>>>>>>>>>>> @@ -337,7 +337,9 @@ >>>>>>>>>>>>>>> ?????????? } else if (comp instanceof >>>>>>>>>>>>>>> JInternalFrame.JDesktopIcon) { >>>>>>>>>>>>>>> ?????????????? return >>>>>>>>>>>>>>> ((JInternalFrame.JDesktopIcon)comp).getInternalFrame(); >>>>>>>>>>>>>>> ?????????? } >>>>>>>>>>>>>>> -??????? assert false : "cannot find the internal frame"; >>>>>>>>>>>>>>> +?????? if (!(comp instanceof BasicInternalFrameTitlePane)) { >>>>>>>>>>>>>>> +??????????? assert false : "cannot find the internal frame"; >>>>>>>>>>>>>>> +?????? } >>>>>>>>>>>>>>> ?????????? return null; >>>>>>>>>>>>>>> ?????? } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Wed May 22 21:59:13 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Wed, 22 May 2019 14:59:13 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> Message-ID: <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> On 5/22/19 2:29 PM, Sergey Bylokhov wrote: > Hi, Semyon. > > Why it s necessary to change the adjustPopupLocationToFit value? why > on macOS it does not work by default like on others platforms? > If I read an initial bug 6580930 correctly there was an intention that > HW popup should be able to overlap taskbar by default and I assume it > works this way on win/lin(or it does not work)? Any Hi Sergey, It's hard to say now why this Swing property was introduced on Mac. But the current fix is intended to fix the test only and not the product. You can request the removal of the property in a separate bug. --Semyon > > On 22/05/2019 13:27, semyon.sadetsky at oracle.com wrote: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8196096 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.00/ >> >> This is a fix for an unstable test: >> >> - inside EDT execution is ensured where necessary. >> >> - To pass on the mac platform the check for lightweight popup is >> excluded and the taskbar overlapping Swing property is enabled. >> >> >> --Semyon >> > > From Sergey.Bylokhov at oracle.com Wed May 22 22:15:46 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 May 2019 15:15:46 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> Message-ID: <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> On 22/05/2019 14:59, semyon.sadetsky at oracle.com wrote: > On 5/22/19 2:29 PM, Sergey Bylokhov wrote: >> Why it s necessary to change the adjustPopupLocationToFit value? why on macOS it does not work by default like on others platforms? >> If I read an initial bug 6580930 correctly there was an intention that HW popup should be able to overlap taskbar by default and I assume it works this way on win/lin(or it does not work)? Any > It's hard to say now why this Swing property was introduced on Mac. But the current fix is intended to fix the test only and not the product. You can request the removal of the property in a separate bug. This property was introduced long before the macosx-port via JDK-4425878. If the test does not work properly because of the product bug, then you should not work around it, but instead, you should create a new product bug and add this test and a new bugid to the problem list for macOS. > --Semyon >> >> On 22/05/2019 13:27, semyon.sadetsky at oracle.com wrote: >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8196096 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.00/ >>> >>> This is a fix for an unstable test: >>> >>> - inside EDT execution is ensured where necessary. >>> >>> - To pass on the mac platform the check for lightweight popup is excluded and the taskbar overlapping Swing property is enabled. >>> >>> >>> --Semyon >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Wed May 22 22:16:49 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Wed, 22 May 2019 15:16:49 -0700 Subject: [13] RFR 8153090 8223788 8224149: TAB key cannot change input focus after the radio button in the Color Selection dialog.+ In-Reply-To: <65ee59fe-118e-a7e5-b957-95d48d8c84e9@oracle.com> References: <783fc182-de41-96d1-b0fd-93cdd6dc16a6@oracle.com> <5CE2EC30.1040304@oracle.com> <3b55845d-a885-cacd-f995-63680846cb0c@oracle.com> <65ee59fe-118e-a7e5-b957-95d48d8c84e9@oracle.com> Message-ID: <74e3a9b1-b001-28e7-a51a-738f0ab5cfbd@oracle.com> On 5/20/19 11:48 PM, Prasanta Sadhukhan wrote: > Probably we can move this traversal code to > javax.swing.SortingFocusTraversalPolicy#SwingContainerOrderFocusTraversalPolicy > for this JToggleButton swing component to avoid this scepticism. Hi Prasanta, We cannot move it there because it'd not be called when ContainerOrderFocusTraversalPolicy is used. --Semyon > > Regards > Prasanta > On 21-May-19 1:36 AM, semyon.sadetsky at oracle.com wrote: >> On 5/20/19 11:04 AM, Philip Race wrote: >> >>> Hi, >>> >>> I'm afraid I know next to nothing about the focus traversal >>> code in Swing or AWT, but it smells very wrong to have >>> such knowledge of a specific Swing component in the >>> AWT focus code. >> I don't see anything wrong here. You can find a lot of Swing >> component specific code in java.awt.* implementations. This is not >> the first Swing aware AWT class. >> >> --Semyon >>> >>> -phil. >>> >>> On 5/20/19, 8:37 AM, semyon.sadetsky at oracle.com wrote: >>>> bugs: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8153090 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8223788 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8224149 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153090/webrev.00/ >>>> >>>> The fix eliminates issues in JColorChooser dialog making it more >>>> accessible by keyboard. See JBS for details. >>>> >>>> --Semyon >>>> >> > From semyon.sadetsky at oracle.com Thu May 23 15:58:58 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Thu, 23 May 2019 08:58:58 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> Message-ID: <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> On 5/22/19 3:15 PM, Sergey Bylokhov wrote: > On 22/05/2019 14:59, semyon.sadetsky at oracle.com wrote: >> On 5/22/19 2:29 PM, Sergey Bylokhov wrote: >>> Why it s necessary to change the adjustPopupLocationToFit value? why >>> on macOS it does not work by default like on others platforms? >>> If I read an initial bug 6580930 correctly there was an intention >>> that HW popup should be able to overlap taskbar by default and I >>> assume it works this way on win/lin(or it does not work)? Any >> It's hard to say now why this Swing property was introduced on Mac. >> But the current fix is intended to fix the test only and not the >> product. You can request the removal of the property in a separate bug. > > This property was introduced long before the macosx-port via JDK-4425878. > If the test does not work properly because of the product bug, then > you should not work around it, but instead, you should create a new > product bug and add this test and a new bugid to the problem list for > macOS. I don't agree. Java specification doesn't say that the popup menu shall overlap the OS taskbar. The test scenario shouldn't expect that. Permission to overlap taskbar is determined by the security settings and the platform default settings. By adding adjustPopupLocationToFit=false the test is abstracted from those settings which makes the overlap testing sensible. Otherwise the test may fail in some environments and platforms. As for the mac platform where the taskbar overlapping is disabled by default in the toolkit. It was intentionally disabled by fixing of a bug reported by NetBeans team. There is JDK-7124313 reported internally which requests the opposite, but it requires investigation at first, it is not clear that we can do this. --Semyon >>> >>> On 22/05/2019 13:27, semyon.sadetsky at oracle.com wrote: >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8196096 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.00/ >>>> >>>> This is a fix for an unstable test: >>>> >>>> - inside EDT execution is ensured where necessary. >>>> >>>> - To pass on the mac platform the check for lightweight popup is >>>> excluded and the taskbar overlapping Swing property is enabled. >>>> >>>> >>>> --Semyon >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Thu May 23 16:12:25 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 09:12:25 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> Message-ID: <8e91a03b-70c8-32ae-b9da-d2ffe62ddc4c@oracle.com> On 23/05/2019 08:58, semyon.sadetsky at oracle.com wrote: >> This property was introduced long before the macosx-port via JDK-4425878. >> If the test does not work properly because of the product bug, then you should not work around it, but instead, you should create a new product bug and add this test and a new bugid to the problem list for macOS. > I don't agree. Java specification doesn't say that the popup menu shall overlap the OS taskbar. The test scenario shouldn't expect that. Permission to overlap taskbar is determined by the security settings and the platform default settings. By adding adjustPopupLocationToFit=false the test is abstracted from those settings which makes the overlap testing sensible. Otherwise the test may fail in some environments and platforms. > As for the mac platform where the taskbar overlapping is disabled by default in the toolkit. It was intentionally disabled by fixing of a bug reported by NetBeans team. There is JDK-7124313 reported internally which requests the opposite, but it requires investigation at first, it is not clear that we can do this. You just workaround the case for which the test was created, this is not a test bug, and it should not be fixed by the change in the test during test_sprint. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu May 23 16:28:58 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Thu, 23 May 2019 09:28:58 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <8e91a03b-70c8-32ae-b9da-d2ffe62ddc4c@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> <8e91a03b-70c8-32ae-b9da-d2ffe62ddc4c@oracle.com> Message-ID: <79e4c107-8df1-2b8b-5c56-a8f26be5adfd@oracle.com> On 5/23/19 9:12 AM, Sergey Bylokhov wrote: > On 23/05/2019 08:58, semyon.sadetsky at oracle.com wrote: >>> This property was introduced long before the macosx-port via >>> JDK-4425878. >>> If the test does not work properly because of the product bug, then >>> you should not work around it, but instead, you should create a new >>> product bug and add this test and a new bugid to the problem list >>> for macOS. >> I don't agree. Java specification doesn't say that the popup menu >> shall overlap the OS taskbar. The test scenario shouldn't expect >> that. Permission to overlap taskbar is determined by the security >> settings and the platform default settings. By adding >> adjustPopupLocationToFit=false the test is abstracted from those >> settings which makes the overlap testing sensible. Otherwise the test >> may fail in some environments and platforms. >> As for the mac platform where the taskbar overlapping is disabled by >> default in the toolkit. It was intentionally disabled by fixing of a >> bug reported by NetBeans team. There is JDK-7124313 reported >> internally which requests the opposite, but it requires investigation >> at first, it is not clear that we can do this. > > You just workaround the case for which the test was created, this is > not a test bug, and it should not be fixed by the change in the test > during test_sprint. What product issue do you suggest to fix? From Sergey.Bylokhov at oracle.com Thu May 23 16:37:52 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 09:37:52 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <79e4c107-8df1-2b8b-5c56-a8f26be5adfd@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> <8e91a03b-70c8-32ae-b9da-d2ffe62ddc4c@oracle.com> <79e4c107-8df1-2b8b-5c56-a8f26be5adfd@oracle.com> Message-ID: On 23/05/2019 09:28, semyon.sadetsky at oracle.com wrote: >> You just workaround the case for which the test was created, this is not a test bug, and it should not be fixed by the change in the test during test_sprint. > What product issue do you suggest to fix? I do not suggest to fix a product bug, I suggest to fix the usage of EDT and any other issues of instability of the test. And add this test and a new bugid to the problem list on macOS. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu May 23 17:15:16 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Thu, 23 May 2019 10:15:16 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> <8e91a03b-70c8-32ae-b9da-d2ffe62ddc4c@oracle.com> <79e4c107-8df1-2b8b-5c56-a8f26be5adfd@oracle.com> Message-ID: <77eb683d-e495-3685-10da-4214a1ac126b@oracle.com> On 5/23/19 9:37 AM, Sergey Bylokhov wrote: > On 23/05/2019 09:28, semyon.sadetsky at oracle.com wrote: >>> You just workaround the case for which the test was created, this is >>> not a test bug, and it should not be fixed by the change in the test >>> during test_sprint. >> What product issue do you suggest to fix? > > I do not suggest to fix a product bug, I suggest to fix the usage of > EDT and any other issues of instability of the test. > And add this test and a new bugid to the problem list on macOS. http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.01/ From Sergey.Bylokhov at oracle.com Thu May 23 23:51:26 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 May 2019 16:51:26 -0700 Subject: [13] RFR 8196096: javax/swing/JPopupMenu/6580930/bug6580930.java fails In-Reply-To: <77eb683d-e495-3685-10da-4214a1ac126b@oracle.com> References: <769ca5f8-e714-d888-f54f-e0d0dd0adcdd@oracle.com> <463c882c-acfd-56ab-c82e-ca59c85ea3dd@oracle.com> <8de94fa8-73ac-705d-90ba-b46732708c7a@oracle.com> <07b33f8a-f235-870e-f303-748113c29e05@oracle.com> <52716f20-658f-c0db-9cc7-44ba5e66f2d3@oracle.com> <8e91a03b-70c8-32ae-b9da-d2ffe62ddc4c@oracle.com> <79e4c107-8df1-2b8b-5c56-a8f26be5adfd@oracle.com> <77eb683d-e495-3685-10da-4214a1ac126b@oracle.com> Message-ID: <0a95b076-e9b4-400d-64ef-8098dd3efc96@oracle.com> Looks fine. On 23/05/2019 10:15, semyon.sadetsky at oracle.com wrote: > On 5/23/19 9:37 AM, Sergey Bylokhov wrote: > >> On 23/05/2019 09:28, semyon.sadetsky at oracle.com wrote: >>>> You just workaround the case for which the test was created, this is not a test bug, and it should not be fixed by the change in the test during test_sprint. >>> What product issue do you suggest to fix? >> >> I do not suggest to fix a product bug, I suggest to fix the usage of EDT and any other issues of instability of the test. >> And add this test and a new bugid to the problem list on macOS. > http://cr.openjdk.java.net/~ssadetsky/8196096/webrev.01/ > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri May 24 20:26:49 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Fri, 24 May 2019 13:26:49 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly Message-ID: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> webrev: http://cr.openjdk.java.net/~ssadetsky/7184956/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-7184956 Fix for a test: Mac light weigh popup testing excluded. --Semyon From Sergey.Bylokhov at oracle.com Fri May 24 21:07:11 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 May 2019 14:07:11 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> Message-ID: <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> Hi, Semyon. I am not sure that this is a test bug, the Aqua L&F uses HW popup by default, but the case when the user requests LW popup for some reason should work, it is just not implemented yet. BTW: note that the current two weeks sprint is about the cleanup of our internal CI, which has some failing tests which are not in the problem list. It is not necessary to change the tests which are already in the problem list. On 24/05/2019 13:26, semyon.sadetsky at oracle.com wrote: > webrev: http://cr.openjdk.java.net/~ssadetsky/7184956/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-7184956 > > Fix for a test: Mac light weigh popup testing excluded. > > --Semyon > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue May 28 11:01:06 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 May 2019 16:31:06 +0530 Subject: [13] RFR 8224876:javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java fails on linux-x64 Message-ID: Hi All, Please review a test-fix for an issue where the test check fails after the content of window is dragged & resized. Test is passing in local ubuntu18.04 system but is failing on mach5 linux headful system as test check for pixels happens too quickly after window drag/resize. Increased delay between test drag&drop and check to make sure check happens after reasonable amount of time. Test now pass in all mach5 systems. Bug: https://bugs.openjdk.java.net/browse/JDK-8224876 webrev: http://cr.openjdk.java.net/~psadhukhan/8224876/webrev.0/ Regards Prasanta From semyon.sadetsky at oracle.com Tue May 28 16:19:23 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Tue, 28 May 2019 09:19:23 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> Message-ID: <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> On 5/24/19 2:07 PM, Sergey Bylokhov wrote: > Hi, Semyon. > > I am not sure that this is a test bug, the Aqua L&F uses HW popup by > default, but the case when the user requests LW popup for some reason > should work, it is just not implemented yet. Hi Sergey, I think your understanding of the lightWeightPopupEnabled property purpose is not fully correct. The specification of the property is very clear on that: /** * Sets the value of the lightWeightPopupEnabled property, * which by default is true. * By default, when a look and feel displays a popup, * it can choose to * use a lightweight (all-Java) popup. * Lightweight popup windows are more efficient than heavyweight * (native peer) windows, * but lightweight and heavyweight components do not mix well in a GUI. * If your application mixes lightweight and heavyweight components, * you should disable lightweight popups. * Some look and feels might always use heavyweight popups, * no matter what the value of this property. */ So, there is nothing to implement in Aqua L&F about it. --Semyon > > BTW: note that the current two weeks sprint is about the cleanup of > our internal CI, which has some failing tests which are not in the > problem list. It is not necessary to change the tests which are > already in the problem list. > > On 24/05/2019 13:26, semyon.sadetsky at oracle.com wrote: >> webrev: http://cr.openjdk.java.net/~ssadetsky/7184956/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-7184956 >> >> Fix for a test: Mac light weigh popup testing excluded. >> >> --Semyon >> > > From Sergey.Bylokhov at oracle.com Tue May 28 20:55:24 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 May 2019 13:55:24 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> Message-ID: <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> On 28/05/2019 09:19, semyon.sadetsky at oracle.com wrote: > Hi Sergey, > I think your understanding of the lightWeightPopupEnabled property purpose is not fully correct. The specification of the property is very clear on that: > ?? /** > ???? * Sets the value of the lightWeightPopupEnabled property, > ???? * which by default is true. > ???? * By default, when a look and feel displays a popup, > ???? * it can choose to > ???? * use a lightweight (all-Java) popup. > ???? * Lightweight popup windows are more efficient than heavyweight > ???? * (native peer) windows, > ???? * but lightweight and heavyweight components do not mix well in a GUI. > ???? * If your application mixes lightweight and heavyweight components, > ???? * you should disable lightweight popups. > ???? * Some look and feels might always use heavyweight popups, > ???? * no matter what the value of this property. > ???? */ > So, there is nothing to implement in Aqua L&F about it. I guess the spec above is from the different method, which is not used in the test? But as of the spec for setDefaultLightWeightPopupEnabled()/getDefaultLightWeightPopupEnabled() we of course work according to the specification, but it does not mean that we should not implement/change the optional part. It is know that such lw-popups are used by some applications, an example is here: https://bugs.openjdk.java.net/browse/JDK-7156657 It seems it is not possible to implement the same appearance it in Aqua? -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue May 28 20:59:16 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 May 2019 13:59:16 -0700 Subject: [13] RFR 8224876:javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java fails on linux-x64 In-Reply-To: References: Message-ID: <5b9179d9-220e-9838-0454-cc84592fd093@oracle.com> Hi, Prasanta. Isn't strange that 1 second is not enough to wait for redraw? I'll reply soon after rechecking the test manually on this system. On 28/05/2019 04:01, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test-fix for an issue where the test check fails after the content of window is dragged & resized. > Test is passing in local ubuntu18.04 system but is failing on mach5 linux headful system as test check for pixels happens too quickly after window drag/resize. > Increased delay between test drag&drop and check to make sure check happens after reasonable amount of time. Test now pass in all mach5 systems. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224876 > webrev: http://cr.openjdk.java.net/~psadhukhan/8224876/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue May 28 22:19:51 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Tue, 28 May 2019 15:19:51 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> Message-ID: <48004b2f-fe17-b452-c17e-18bbf263faba@oracle.com> On 5/28/19 1:55 PM, Sergey Bylokhov wrote: > On 28/05/2019 09:19, semyon.sadetsky at oracle.com wrote: >> Hi Sergey, >> I think your understanding of the lightWeightPopupEnabled property >> purpose is not fully correct. The specification of the property is >> very clear on that: >> /** >> * Sets the value of the lightWeightPopupEnabled >> property, >> * which by default is true. >> * By default, when a look and feel displays a popup, >> * it can choose to >> * use a lightweight (all-Java) popup. >> * Lightweight popup windows are more efficient than heavyweight >> * (native peer) windows, >> * but lightweight and heavyweight components do not mix well in >> a GUI. >> * If your application mixes lightweight and heavyweight >> components, >> * you should disable lightweight popups. >> * Some look and feels might always use heavyweight popups, >> * no matter what the value of this property. >> */ >> So, there is nothing to implement in Aqua L&F about it. > > I guess the spec above is from the different method, which is not used > in the test? But as of the spec for > setDefaultLightWeightPopupEnabled()/getDefaultLightWeightPopupEnabled() > we of course work according to the specification, but it does not mean > that we should not implement/change the optional part. Did you mean that *the default* value of some property has more priority then the value of the property it-self? This sounds very strange to me. This'd mean that if we setDefaultLightWeightPopupEnabled() to some value than we cannot use setLightWeightPopupEnabled() to change the value. This contradicts to the current implementation which uses the default as initial property value only: public JPopupMenu(String label) { this.label = label; lightWeightPopup = getDefaultLightWeightPopupEnabled(); ... I see no reason to change that behavior. From Sergey.Bylokhov at oracle.com Tue May 28 22:56:23 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 May 2019 15:56:23 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <48004b2f-fe17-b452-c17e-18bbf263faba@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> <48004b2f-fe17-b452-c17e-18bbf263faba@oracle.com> Message-ID: <5ffe8e99-5224-6901-0011-d63cc454ab2a@oracle.com> On 28/05/2019 15:19, semyon.sadetsky at oracle.com wrote: >> I guess the spec above is from the different method, which is not used in the test? But as of the spec for setDefaultLightWeightPopupEnabled()/getDefaultLightWeightPopupEnabled() we of course work according to the specification, but it does not mean that we should not implement/change the optional part. > Did you mean that *the default* value of some property has more priority then the value of the property it-self? This sounds very strange to me. I said nothing about the property itself, I just point that the method which is called in the test setDefaultLightWeightPopupEnabled() is eventually ignored, but it should not. It should be somehow possible to switch from one type of popups to another regardless which type of popups used by default. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Wed May 29 15:58:31 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Wed, 29 May 2019 08:58:31 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <5ffe8e99-5224-6901-0011-d63cc454ab2a@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> <48004b2f-fe17-b452-c17e-18bbf263faba@oracle.com> <5ffe8e99-5224-6901-0011-d63cc454ab2a@oracle.com> Message-ID: <8547e163-fba3-fe47-1d96-768ff400fa3d@oracle.com> On 5/28/19 3:56 PM, Sergey Bylokhov wrote: > On 28/05/2019 15:19, semyon.sadetsky at oracle.com wrote: >>> I guess the spec above is from the different method, which is not >>> used in the test? But as of the spec for >>> setDefaultLightWeightPopupEnabled()/getDefaultLightWeightPopupEnabled() >>> we of course work according to the specification, but it does not >>> mean that we should not implement/change the optional part. >> Did you mean that *the default* value of some property has more >> priority then the value of the property it-self? This sounds very >> strange to me. > > I said nothing about the property itself, I just point that the method > which is called in the test setDefaultLightWeightPopupEnabled() is > eventually ignored, but it should not. And why it shouldn't when the spec states the opposite? : * Some look and feels might always use heavyweight popups, * no matter what the value of this property. Maybe the thing is that you just overlooked the specification? If you haven't enough expertise in the area you should insist on your superficial suggestions to implement something and I shouldn't explain why they are not feasible many times here. From philip.race at oracle.com Wed May 29 21:18:45 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 29 May 2019 14:18:45 -0700 Subject: RFR: 8225020: Problem list some sanity test failures Message-ID: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> bug : https://bugs.openjdk.java.net/browse/JDK-8225020 Problem listing some sanity tests which consistently fail Bugs are open on each of these. diff below -phil. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -795,6 +795,10 @@ ?javax/swing/RepaintManager/IconifyTest/IconifyTest.java 8221903 linux-all ?javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 linux-all +sanity/client/SwingSet/src/ColorChooserDemoTest.java 8221312 generic-all +sanity/client/SwingSet/src/ToolTipDemoTest.java 8225012 windows-all +sanity/client/SwingSet/src/ScrollPaneDemoTest.java 8225013 linux-all + ?############################################################################ From Sergey.Bylokhov at oracle.com Thu May 30 00:41:55 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 May 2019 17:41:55 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <8547e163-fba3-fe47-1d96-768ff400fa3d@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> <48004b2f-fe17-b452-c17e-18bbf263faba@oracle.com> <5ffe8e99-5224-6901-0011-d63cc454ab2a@oracle.com> <8547e163-fba3-fe47-1d96-768ff400fa3d@oracle.com> Message-ID: <3320bb7c-34ec-d3e6-4af6-893ccb701e17@oracle.com> On 29/05/2019 08:58, semyon.sadetsky at oracle.com wrote: > And why it shouldn't when the spec states the opposite? : > ????? * Some look and feels might always use heavyweight popups, > ????? * no matter what the value of this property. > Maybe the thing is that you just overlooked the specification? The spec does not say the opposite, if something is specified as optional and may be ignored, does not mean that it should be ignored. It should be somehow possible to switch from one type of popups to another regardless which type of popups used by default, since it is known that the applications use both types for a different reasons. > If you haven't enough expertise in the area you should insist on your superficial suggestions to implement something and I shouldn't explain why they are not feasible many times here. Thank you for the suggestion. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu May 30 07:02:18 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 May 2019 12:32:18 +0530 Subject: [13] RFR 8224876:javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java fails on linux-x64 In-Reply-To: <5b9179d9-220e-9838-0454-cc84592fd093@oracle.com> References: <5b9179d9-220e-9838-0454-cc84592fd093@oracle.com> Message-ID: <85251886-7ba3-f74f-2408-6e4e21c647ff@oracle.com> I could not find anything amiss when I capture the screen output at the time of fail, so I decided to go to timeout increase route. I guess it is needed to check the test manually in that mach5 specific linux system to see what is happening. Regards Prasanta On 29-May-19 2:29 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Isn't strange that 1 second is not enough to wait for redraw? > I'll reply soon after rechecking the test manually on this system. > > On 28/05/2019 04:01, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test-fix for an issue where the test check fails >> after the content of window is dragged & resized. >> Test is passing in local ubuntu18.04 system but is failing on mach5 >> linux headful system as test check for pixels happens too quickly >> after window drag/resize. >> Increased delay between test drag&drop and check to make sure check >> happens after reasonable amount of time. Test now pass in all mach5 >> systems. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224876 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8224876/webrev.0/ >> >> Regards >> Prasanta > > From abdul.kolarkunnu at oracle.com Thu May 30 07:13:06 2019 From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com) Date: Thu, 30 May 2019 12:43:06 +0530 Subject: RFR: 8225020: Problem list some sanity test failures In-Reply-To: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> References: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> Message-ID: <3afeb333-b1dd-b44a-f29b-036a57022f93@oracle.com> Looks good to me. -Muneer On 30/05/19 2:48 AM, Phil Race wrote: > bug : https://bugs.openjdk.java.net/browse/JDK-8225020 > Problem listing some sanity tests which consistently fail > Bugs are open on each of these. > > diff below > > > -phil. > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -795,6 +795,10 @@ > ?javax/swing/RepaintManager/IconifyTest/IconifyTest.java 8221903 > linux-all > ?javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 > linux-all > > +sanity/client/SwingSet/src/ColorChooserDemoTest.java 8221312 generic-all > +sanity/client/SwingSet/src/ToolTipDemoTest.java 8225012 windows-all > +sanity/client/SwingSet/src/ScrollPaneDemoTest.java 8225013 linux-all > + > ?############################################################################ > > From prasanta.sadhukhan at oracle.com Thu May 30 07:16:47 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 May 2019 12:46:47 +0530 Subject: RFR: 8225020: Problem list some sanity test failures In-Reply-To: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> References: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> Message-ID: <661888ea-bbbd-8ff7-42a9-f2258457d2c4@oracle.com> +1 Regards Prasanta On 30-May-19 2:48 AM, Phil Race wrote: > bug : https://bugs.openjdk.java.net/browse/JDK-8225020 > Problem listing some sanity tests which consistently fail > Bugs are open on each of these. > > diff below > > > -phil. > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -795,6 +795,10 @@ > ?javax/swing/RepaintManager/IconifyTest/IconifyTest.java 8221903 > linux-all > ?javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 > linux-all > > +sanity/client/SwingSet/src/ColorChooserDemoTest.java 8221312 generic-all > +sanity/client/SwingSet/src/ToolTipDemoTest.java 8225012 windows-all > +sanity/client/SwingSet/src/ScrollPaneDemoTest.java 8225013 linux-all > + > ?############################################################################ > > From fujie at loongson.cn Thu May 30 07:33:04 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 30 May 2019 15:33:04 +0800 Subject: RFR: 8225020: Problem list some sanity test failures In-Reply-To: <661888ea-bbbd-8ff7-42a9-f2258457d2c4@oracle.com> References: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> <661888ea-bbbd-8ff7-42a9-f2258457d2c4@oracle.com> Message-ID: <66221871-1643-c7a6-fabf-e58bc41725f5@loongson.cn> Hi all, +1 Also when running jdk-tier3 on Ubuntu18.04, the following tests may fail: ------------------------------------------- sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java sanity/client/SwingSet/src/EditorPaneDemoTest.java sanity/client/SwingSet/src/InternalFrameDemoTest.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/TextFieldDemoTest.java sanity/client/SwingSet/src/ToolTipDemoTest.java ------------------------------------------- Thanks a lot. Best regards, Jie On 2019/5/30 ??3:16, Prasanta Sadhukhan wrote: > +1 > > Regards > Prasanta > On 30-May-19 2:48 AM, Phil Race wrote: >> bug : https://bugs.openjdk.java.net/browse/JDK-8225020 >> Problem listing some sanity tests which consistently fail >> Bugs are open on each of these. >> >> diff below >> >> >> -phil. >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -795,6 +795,10 @@ >> ?javax/swing/RepaintManager/IconifyTest/IconifyTest.java 8221903 >> linux-all >> ?javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 >> linux-all >> >> +sanity/client/SwingSet/src/ColorChooserDemoTest.java 8221312 >> generic-all >> +sanity/client/SwingSet/src/ToolTipDemoTest.java 8225012 windows-all >> +sanity/client/SwingSet/src/ScrollPaneDemoTest.java 8225013 linux-all >> + >> ?############################################################################ >> >> > From philip.race at oracle.com Thu May 30 16:15:21 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 30 May 2019 09:15:21 -0700 Subject: RFR: 8225020: Problem list some sanity test failures In-Reply-To: <66221871-1643-c7a6-fabf-e58bc41725f5@loongson.cn> References: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> <661888ea-bbbd-8ff7-42a9-f2258457d2c4@oracle.com> <66221871-1643-c7a6-fabf-e58bc41725f5@loongson.cn> Message-ID: <502dcb07-5a44-f241-756d-6e5df8c9fac7@oracle.com> On 5/30/19 12:33 AM, Jie Fu wrote: > Hi all, > > +1 > > Also when running jdk-tier3 on Ubuntu18.04, the following tests may fail: > ------------------------------------------- > sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java > sanity/client/SwingSet/src/ColorChooserDemoTest.java That one is one I problem list below > sanity/client/SwingSet/src/EditorPaneDemoTest.java > sanity/client/SwingSet/src/InternalFrameDemoTest.java This one is very recently fixed > sanity/client/SwingSet/src/SwingSet2DemoTest.java > sanity/client/SwingSet/src/TextFieldDemoTest.java > sanity/client/SwingSet/src/ToolTipDemoTest.java I've only seen that one fail on windows and none of the others fail on 18.04 in our runs. -phil. > ------------------------------------------- > > Thanks a lot. > Best regards, > Jie > > On 2019/5/30 ??3:16, Prasanta Sadhukhan wrote: >> +1 >> >> Regards >> Prasanta >> On 30-May-19 2:48 AM, Phil Race wrote: >>> bug : https://bugs.openjdk.java.net/browse/JDK-8225020 >>> Problem listing some sanity tests which consistently fail >>> Bugs are open on each of these. >>> >>> diff below >>> >>> >>> -phil. >>> >>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt >>> +++ b/test/jdk/ProblemList.txt >>> @@ -795,6 +795,10 @@ >>> ?javax/swing/RepaintManager/IconifyTest/IconifyTest.java 8221903 >>> linux-all >>> ?javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 >>> linux-all >>> >>> +sanity/client/SwingSet/src/ColorChooserDemoTest.java 8221312 >>> generic-all >>> +sanity/client/SwingSet/src/ToolTipDemoTest.java 8225012 windows-all >>> +sanity/client/SwingSet/src/ScrollPaneDemoTest.java 8225013 linux-all >>> + >>> ?############################################################################ >>> >>> >> > From semyon.sadetsky at oracle.com Thu May 30 22:05:27 2019 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Thu, 30 May 2019 15:05:27 -0700 Subject: [13] RFR 7184956: [macosx] JPopupMenu.setDefaultLightPopupEneble(true) doesn't work correctly In-Reply-To: <3320bb7c-34ec-d3e6-4af6-893ccb701e17@oracle.com> References: <59945c45-b9dc-421d-03c3-d750e33585b1@oracle.com> <6f7d31ae-317e-3897-7450-b326cb8e3333@oracle.com> <3b712884-404c-ec63-6b8e-39cd0fd97a08@oracle.com> <80685b56-0888-ac2e-88cd-5a73e96d9c7c@oracle.com> <48004b2f-fe17-b452-c17e-18bbf263faba@oracle.com> <5ffe8e99-5224-6901-0011-d63cc454ab2a@oracle.com> <8547e163-fba3-fe47-1d96-768ff400fa3d@oracle.com> <3320bb7c-34ec-d3e6-4af6-893ccb701e17@oracle.com> Message-ID: On 5/29/19 5:41 PM, Sergey Bylokhov wrote: > On 29/05/2019 08:58, semyon.sadetsky at oracle.com wrote: >> And why it shouldn't when the spec states the opposite? : >> * Some look and feels might always use heavyweight popups, >> * no matter what the value of this property. >> Maybe the thing is that you just overlooked the specification? > > The spec does not say the opposite, if something is specified as > optional and may be ignored, does not mean that it should be ignored. OK, let's implement all possible features that is not disabled... Sounds just not sensible, isn't it? > It should be somehow possible to switch from one type of popups to > another regardless which type of popups used by default, since it is > known that the applications use both types for a different reasons. Again, it shouldn't. The spec is very clear about that point. Aqua L&F disables lightweight popups because they are alien. > >> If you haven't enough expertise in the area you should insist on your >> superficial suggestions to implement something and I shouldn't >> explain why they are not feasible many times here. > > Thank you for the suggestion. > From fujie at loongson.cn Fri May 31 06:09:30 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 31 May 2019 14:09:30 +0800 Subject: RFR: 8225020: Problem list some sanity test failures In-Reply-To: <502dcb07-5a44-f241-756d-6e5df8c9fac7@oracle.com> References: <8fcfdc2e-02bf-08f0-c2ae-8b21d46be5bf@oracle.com> <661888ea-bbbd-8ff7-42a9-f2258457d2c4@oracle.com> <66221871-1643-c7a6-fabf-e58bc41725f5@loongson.cn> <502dcb07-5a44-f241-756d-6e5df8c9fac7@oracle.com> Message-ID: <2bd322b6-3a3d-b3e2-78bc-271493647e58@loongson.cn> On 2019/5/31 ??12:15, Phil Race wrote: > I've only seen that one fail on windows and none of the others fail on > 18.04 in our runs. I verified again with make test TEST="sanity/client/SwingSet/src/SwingSet2DemoTest.java" CONF=release, it passed. That's strange. I often got the following results on my Ubuntu18.04. ============================== Test summary ============================== ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL ERROR ?? jtreg:test/hotspot/jtreg:tier1???????????????????? 1402? 1402 0???? 0 >> jtreg:test/jdk:tier1?????????????????????????????? 1871 1870???? 1???? 0 <> jtreg:test/jdk:tier3?????????????????????????????? 1108 1102???? 5???? 1 <