From duke at openjdk.org Sat Jun 1 09:23:04 2024 From: duke at openjdk.org (lawrence.andrews) Date: Sat, 1 Jun 2024 09:23:04 GMT Subject: RFR: 8280990: [XWayland] XTest emulated mouse click does not bring window to front In-Reply-To: References: Message-ID: <7kqjnsgPPqCjp0YKm16qNdSnQbTKe6yVu0xP_eAXei4=.be0537a7-a733-4b36-b64f-a8d91dc97ced@github.com> On Tue, 28 May 2024 02:25:46 GMT, Alexander Zvegintsev wrote: > Some of the modal tests fail in X11 compatibility mode on Wayland, because a mouse click emulated with XTEST does not not cause the windows to be reordered. > > This is a known limitation because these click events do not leave the XWayland server and are not reported to the Wayland compositor. > > There is a [libei](https://gitlab.freedesktop.org/libinput/libei) that can be used to emulate input events in Wayland. > And there is a [bridge that allows emulated events from XTEST to be passed to the compositor](https://gitlab.freedesktop.org/libinput/libei/-/blob/main/README.md?ref_type=heads#xwayland-and-xtest). > Support for this has been added in [Gnome 45 and XWayland 23.2](https://gitlab.gnome.org/GNOME/mutter/-/issues/3194#note_1937109), but it is optional and not yet enabled in Ubuntu. > > This change adds `toFront` calls for mouse clicks that are only intended to bring a window to the front in the window stacking order. > > The testing is green on all platforms. According to https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/java/awt/Window.html#toFront() some platforms does not support toFront() , how are we handling this case ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19417#issuecomment-2143376444 From azvegint at openjdk.org Sat Jun 1 13:08:00 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 1 Jun 2024 13:08:00 GMT Subject: RFR: 8280990: [XWayland] XTest emulated mouse click does not bring window to front In-Reply-To: <7kqjnsgPPqCjp0YKm16qNdSnQbTKe6yVu0xP_eAXei4=.be0537a7-a733-4b36-b64f-a8d91dc97ced@github.com> References: <7kqjnsgPPqCjp0YKm16qNdSnQbTKe6yVu0xP_eAXei4=.be0537a7-a733-4b36-b64f-a8d91dc97ced@github.com> Message-ID: On Sat, 1 Jun 2024 09:20:28 GMT, lawrence.andrews wrote: > According to https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/java/awt/Window.html#toFront() some platforms does not support toFront() , how are we handling this case ? AFAIK, we do not test on such platforms/window managers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19417#issuecomment-2143442854 From duke at openjdk.org Sun Jun 2 11:38:07 2024 From: duke at openjdk.org (Abdelhak Zaaim) Date: Sun, 2 Jun 2024 11:38:07 GMT Subject: RFR: 8325435: [macos] Menu or JPopupMenu not closed when main window is resized [v2] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 12:24:42 GMT, Prasanta Sadhukhan wrote: >> Issue is in macosx, when a JMenu or JPopupmenu is opened and then window is resized from the lower right corner, then the Menu / JPopupmenu stays open unlike in native osx apps like Notes, Mail etc.. >> >> This is because when LMouseButton is pressed on non-client area, the window should get a UngrabEvent for it to close/cancel the popupmenu (as is done in [windows](https://github.com/openjdk/jdk/blob/f608918df3f887277845db383cf07b0863bba615/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L618-L620)) but it was seen that the mac AWTWindow code only recognizes the title-bar as the non-client area so [notifyNCMouseDown](https://github.com/openjdk/jdk/blob/f608918df3f887277845db383cf07b0863bba615/src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java#L797-L804) is not called. >> Fix is made to recognize the edges of the window as non-client area > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Non-client aread edge area modified, test format Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/19474#pullrequestreview-2092280069 From abhiscxk at openjdk.org Mon Jun 3 05:52:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 3 Jun 2024 05:52:31 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v5] In-Reply-To: References: Message-ID: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> > bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always > failed which is captured in the JBS. > The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). > In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). > JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). > Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. > > Test verified in both single and dual screen linux machines. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Code formatting update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19381/files - new: https://git.openjdk.org/jdk/pull/19381/files/69fedf28..f94e4b0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19381&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19381&range=03-04 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19381/head:pull/19381 PR: https://git.openjdk.org/jdk/pull/19381 From abhiscxk at openjdk.org Mon Jun 3 05:52:32 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 3 Jun 2024 05:52:32 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v3] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 20:47:52 GMT, Alexey Ivanov wrote: >> Updated. > > Previous formatting was less confusing and aligned with Java Coding Style Guidelines. > > The parameters to the method are aligned to the opening parenthesis; the `throws` clause is not part of the parameters and it's placed on another line according to rules of wrapping lines (it should've used double-indentation of 8 spaces rather than 4 spaces to indicate a continuation line). Reverted back to previous formatting with double-indentation. Hopefully this should be ok now. > To make the continuation line stand out as continuation line, place the || at the start of wrapped line. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1623813651 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1623814147 From psadhukhan at openjdk.org Mon Jun 3 06:05:31 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jun 2024 06:05:31 GMT Subject: RFR: 8325435: [macos] Menu or JPopupMenu not closed when main window is resized [v3] In-Reply-To: References: Message-ID: > Issue is in macosx, when a JMenu or JPopupmenu is opened and then window is resized from the lower right corner, then the Menu / JPopupmenu stays open unlike in native osx apps like Notes, Mail etc.. > > This is because when LMouseButton is pressed on non-client area, the window should get a UngrabEvent for it to close/cancel the popupmenu (as is done in [windows](https://github.com/openjdk/jdk/blob/f608918df3f887277845db383cf07b0863bba615/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L618-L620)) but it was seen that the mac AWTWindow code only recognizes the title-bar as the non-client area so [notifyNCMouseDown](https://github.com/openjdk/jdk/blob/f608918df3f887277845db383cf07b0863bba615/src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java#L797-L804) is not called. > Fix is made to recognize the edges of the window as non-client area Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Access in EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19474/files - new: https://git.openjdk.org/jdk/pull/19474/files/d2f9256b..78b3e70f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19474&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19474&range=01-02 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19474.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19474/head:pull/19474 PR: https://git.openjdk.org/jdk/pull/19474 From psadhukhan at openjdk.org Mon Jun 3 06:10:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jun 2024 06:10:07 GMT Subject: RFR: 8325435: [macos] Menu or JPopupMenu not closed when main window is resized [v2] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 14:49:45 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Non-client aread edge area modified, test format > > src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1031: > >> 1029: (p.x >= (frame.origin.x + contentRect.size.width - 3)) || >> 1030: (fabs(frame.origin.x - p.x) < 3) || >> 1031: (fabs(frame.origin.y - p.y) < 3)) { > > Does `fabs` use float? It makes code more compact but it may be imprecise and less performant than integer arithmetics. Yes..https://man7.org/linux/man-pages/man3/fabs.3.html and [CGFLoat ](https://developer.apple.com/documentation/corefoundation/cgfloat?language=objc) can be double/float and fabs can accomodate both, in this case it uses double...We have tested on 3 different systems without any issue so would keep it for now until we find any adverse effect.. > test/jdk/javax/swing/JMenu/TestUngrab.java line 101: > >> 99: robot.delay(1000); >> 100: System.out.println("isPopupMenuVisible " + menu.isPopupMenuVisible()); >> 101: if (menu.isPopupMenuVisible()) { > > `menu.isPopupMenuVisible()` should also be accessed on EDT. Yes...done.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19474#discussion_r1623826880 PR Review Comment: https://git.openjdk.org/jdk/pull/19474#discussion_r1623825295 From psadhukhan at openjdk.org Mon Jun 3 06:28:07 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jun 2024 06:28:07 GMT Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute extension [v9] In-Reply-To: References: <7wzxo7wmUljRmRt2RmPEZq0OOiveLtC_QclkxUFTDvk=.5591e941-72d3-42ab-81a6-bc3305f66e81@github.com> <5m_uJdf3btpdmML-y3LkmHAQerzTzpIcco9O7F45SJw=.995c955e-38c3-4201-8877-a38f31f6556b@github.com> Message-ID: On Fri, 31 May 2024 18:57:03 GMT, Alexander Scherbatiy wrote: >> If it's only about adding tray-1 to tray-11 in the above list and not about whole lot of changes in other areas, so that supported list contains those "tray-N" values, I guess we should add them.. >> I guess isSupportedAttributedValues(tray-N) will not return false in that case.. > > Suppose `getSupportedAttributeValues(OutputBin.class, null, null)` returns [`top`, `face-down`] output bins. > `isSupportedAttributedValues(...)` returns `true` for `OutputBin.TOP` and `OutputBin.FACE_DOWN` constants and `false` for `OutputBin.TRAY_1` if it was added in current implementation. > > To make a one to one correspondence between `OutputBin.TOP` and `OutputBin.TRAY_1` constants it needs to add some logic and may be even make them equal in terms of `OutputBin` class which extends `EnumSyntax` class. > It is not clear should such logic be provided in the current release or it is better to provide its proper implementation in the next release if necessary. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1623839809 From psadhukhan at openjdk.org Mon Jun 3 06:28:06 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jun 2024 06:28:06 GMT Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute extension [v17] In-Reply-To: <4g8cfr0P4vmH4JEoBeRvCkIFeZSsjoTZTkBa98VMJsw=.11368194-d185-4213-abb4-2e7c38f0b165@github.com> References: <4g8cfr0P4vmH4JEoBeRvCkIFeZSsjoTZTkBa98VMJsw=.11368194-d185-4213-abb4-2e7c38f0b165@github.com> Message-ID: On Thu, 30 May 2024 18:45:38 GMT, Alexander Scherbatiy wrote: >> The fix adds new public `OutputBin` print attribute class which allow to set a printer output bin in a `PrinterJob` class. The corresponding internal `CustomOutputBin` class is added as well. >> >> - Constants used in `OutputBin` class are based on [Internet Printing Protocol (IPP): ?output-bin? attribute extension](https://ftp.pwg.org/pub/pwg/candidates/cs-ippoutputbin10-20010207-5100.2.pdf) document. >> - `CUPSPrinter.getOutputBins(String printer)` method uses PPD `ppdFindOption(..., "OutputBin")` function to get supported output bins for the given printer on native level. >> - The fix propagates the `OutputBin` attribute from the printer job attributes to `NSPrintInfo` print settings with `OutputBin` key on macOS. >> >> The fix was tested on `Kyocera ECOSYS M8130cidn` printer where `ppdFindOption(..., "OutputBin")` call returns 4 output bins (text, choice): >> - Printer settings, None >> - Inner tray, INNERTRAY >> - Separator tray, SEPARATORTRAY >> - Finisher (face-down), Main >> >> if `Printer settings`, `Inner tray`, or `Finisher (face-down)` CustomOutputBins is set to `PrinterJob.print(...)` attributes a test page is printed to the Main tray of the `Kyocera ECOSYS M8130cidn` printer. If `Separator tray` is used a page is printed to the Separator tray. This is consistent with the printer behavior when a native print dialog is used from a native Preview app to print a document on macOS. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Add Skip test option to the OutputBinAttributePrintDialogTest with the native dialog Overall Looks good to me although I could not test it fully to my liking owing to non-support of output-bin in my printer.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16166#pullrequestreview-2092883186 From psadhukhan at openjdk.org Mon Jun 3 06:38:02 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jun 2024 06:38:02 GMT Subject: RFR: 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled In-Reply-To: References: Message-ID: On Fri, 24 May 2024 08:37:25 GMT, Jayathirth D V wrote: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is disabled and we don't see this issue) to enable printing of memory trace logs when we have OOM. But if we enable it we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. > > This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in imageioJPEG.c->imageio_dispose() function. > > Moved the logic to delete error handler after we are done with deleting IJG stored objects, after this change there is no crash. There is no regression test because this issue is seen only when we enable MEM_STATS flag in IJG library. Ran jtreg ImageIO tests with code update and i don't see any regressions. > > I have verified that this issue doesn't effect SplashScreen code path and disposing of IJG objects is handled differently in SplashScreen. Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19386#pullrequestreview-2092897041 From kizune at openjdk.org Mon Jun 3 07:03:04 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 3 Jun 2024 07:03:04 GMT Subject: RFR: 8280990: [XWayland] XTest emulated mouse click does not bring window to front In-Reply-To: References: Message-ID: On Tue, 28 May 2024 02:25:46 GMT, Alexander Zvegintsev wrote: > Some of the modal tests fail in X11 compatibility mode on Wayland, because a mouse click emulated with XTEST does not not cause the windows to be reordered. > > This is a known limitation because these click events do not leave the XWayland server and are not reported to the Wayland compositor. > > There is a [libei](https://gitlab.freedesktop.org/libinput/libei) that can be used to emulate input events in Wayland. > And there is a [bridge that allows emulated events from XTEST to be passed to the compositor](https://gitlab.freedesktop.org/libinput/libei/-/blob/main/README.md?ref_type=heads#xwayland-and-xtest). > Support for this has been added in [Gnome 45 and XWayland 23.2](https://gitlab.gnome.org/GNOME/mutter/-/issues/3194#note_1937109), but it is optional and not yet enabled in Ubuntu. > > This change adds `toFront` calls for mouse clicks that are only intended to bring a window to the front in the window stacking order. > > The testing is green on all platforms. Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19417#pullrequestreview-2092939542 From azvegint at openjdk.org Mon Jun 3 07:15:05 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 3 Jun 2024 07:15:05 GMT Subject: Integrated: 8280990: [XWayland] XTest emulated mouse click does not bring window to front In-Reply-To: References: Message-ID: On Tue, 28 May 2024 02:25:46 GMT, Alexander Zvegintsev wrote: > Some of the modal tests fail in X11 compatibility mode on Wayland, because a mouse click emulated with XTEST does not not cause the windows to be reordered. > > This is a known limitation because these click events do not leave the XWayland server and are not reported to the Wayland compositor. > > There is a [libei](https://gitlab.freedesktop.org/libinput/libei) that can be used to emulate input events in Wayland. > And there is a [bridge that allows emulated events from XTEST to be passed to the compositor](https://gitlab.freedesktop.org/libinput/libei/-/blob/main/README.md?ref_type=heads#xwayland-and-xtest). > Support for this has been added in [Gnome 45 and XWayland 23.2](https://gitlab.gnome.org/GNOME/mutter/-/issues/3194#note_1937109), but it is optional and not yet enabled in Ubuntu. > > This change adds `toFront` calls for mouse clicks that are only intended to bring a window to the front in the window stacking order. > > The testing is green on all platforms. This pull request has now been integrated. Changeset: d2d78ad1 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/d2d78ad18e0b5d2a6a62f9c97ceec5592fa1de2e Stats: 27 lines in 3 files changed: 23 ins; 0 del; 4 mod 8280990: [XWayland] XTest emulated mouse click does not bring window to front Reviewed-by: avu, psadhukhan, kizune ------------- PR: https://git.openjdk.org/jdk/pull/19417 From rgupta at openjdk.org Mon Jun 3 12:28:11 2024 From: rgupta at openjdk.org (Ravi Gupta) Date: Mon, 3 Jun 2024 12:28:11 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly Message-ID: This testcase checks for the following assertions for Component events: 1. When components are resized, moved, hidden and shown the respective events are triggered. 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. 4. When a window is minimized/restored then hidden and shown component events should be triggered. Testing: Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ------------- Commit messages: - 8333403: Write a test to check various components events are triggered properly Changes: https://git.openjdk.org/jdk/pull/19521/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333403 Stats: 371 lines in 1 file changed: 371 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19521.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19521/head:pull/19521 PR: https://git.openjdk.org/jdk/pull/19521 From psadhukhan at openjdk.org Mon Jun 3 13:03:09 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 3 Jun 2024 13:03:09 GMT Subject: Integrated: 8325435: [macos] Menu or JPopupMenu not closed when main window is resized In-Reply-To: References: Message-ID: <5M-rKKhpAXSFFpne3iVnDt49KEClcxYOQnNNcyWW6PQ=.f4dd6934-8faf-4259-bb75-3800fa361ac7@github.com> On Thu, 30 May 2024 12:05:25 GMT, Prasanta Sadhukhan wrote: > Issue is in macosx, when a JMenu or JPopupmenu is opened and then window is resized from the lower right corner, then the Menu / JPopupmenu stays open unlike in native osx apps like Notes, Mail etc.. > > This is because when LMouseButton is pressed on non-client area, the window should get a UngrabEvent for it to close/cancel the popupmenu (as is done in [windows](https://github.com/openjdk/jdk/blob/f608918df3f887277845db383cf07b0863bba615/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L618-L620)) but it was seen that the mac AWTWindow code only recognizes the title-bar as the non-client area so [notifyNCMouseDown](https://github.com/openjdk/jdk/blob/f608918df3f887277845db383cf07b0863bba615/src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java#L797-L804) is not called. > Fix is made to recognize the edges of the window as non-client area This pull request has now been integrated. Changeset: 1c514b34 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/1c514b34c0260823e70f209996ac933a76ac34c2 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod 8325435: [macos] Menu or JPopupMenu not closed when main window is resized Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/19474 From alexsch at openjdk.org Mon Jun 3 16:19:07 2024 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Mon, 3 Jun 2024 16:19:07 GMT Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute extension [v17] In-Reply-To: References: <4g8cfr0P4vmH4JEoBeRvCkIFeZSsjoTZTkBa98VMJsw=.11368194-d185-4213-abb4-2e7c38f0b165@github.com> Message-ID: <5xSHxgxGdm80GElobRs2Ijm6fjaPazoH2DoCXr0lkHY=.5d6014a2-dda3-4e2f-bd11-77bb74ddc7de@github.com> On Thu, 30 May 2024 18:53:49 GMT, Alexander Scherbatiy wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Skip test option to the OutputBinAttributePrintDialogTest with the native dialog > > The `OutputBinAttributePrintDialogTest` is updated for the native dialog to have the `Skip Test` button and description that if the native print dialog on MacOS does not contain `Finishing Options` then the test should be skipped. > @AlexanderScherbatiy please note that if you get one approval and have resolved all issues and believe it just needs the 2nd reviewer to formally approve it that the integrate command has some useful options https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate @prrace Should I use the integrate command with the `auto` or `delegate` parameter? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16166#issuecomment-2145620080 From serb at openjdk.org Mon Jun 3 20:04:36 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 3 Jun 2024 20:04:36 GMT Subject: RFR: 8332103: since-checker - Add missing `@since` tags to `java.desktop` [v2] In-Reply-To: References: <3DWE5GBi2tqZa4Kn-7roHwggZuubdIrVpZ5BGdJE0K0=.c41040ba-8370-4d26-a028-21c3c184ce0a@github.com> Message-ID: On Wed, 29 May 2024 11:51:34 GMT, Alexey Ivanov wrote: >> When mapping methods and when they first appeared (by using the historical record built into javac) I use an id in the form of >> `method: .()` so for covariant overrides in general, when the return type changes I consider it to be a new method. >> >> Looking at the contents of the dictionnary: >> This explicit constructor existed for a long time but then this new was added a new one was added in JDK 16 >> | Key | Value | >> | ------------- | ------------- | >> | `method: void javax.swing.plaf.basic.BasicSliderUI.(javax.swing.JSlider):` | 9 | >> | `method: void javax.swing.plaf.basic.BasicSliderUI.():` | 16 | >> >> Note: JDK 9 is used as the "base" as that's how far I can reliably use the `--release` info, so if something was added in JDK 2,5.7,9. It has a value of "9" in the dictionnary. I mainly check for errors in newer code. > >> Hmm, the _explicit_ default constructor was added in JDK 16, but it was implicit before then. So I am not 100% sure what the right answer is - the same as the class, or when it was explicitly added. > > I believe there was no default constructor in `BasicSliderUI()` because there was a constructor with a parameter `BasicSliderUI(JSlider b)`. > > Thus, this case seem to be correct `BasicSliderUI()` is available since 16. > > At the same time, `BasicSliderUI(JSlider b)` has existed since at least 7, the constructor is present in the history of the file. The history in GitHub goes up to 1st December 2007 which corresponds to Java 7 timeline. I'm pretty sure this constructor existed in previous releases, and you have to dig further to find when it was added. > > Very much likely, the constructor `BasicSliderUI(JSlider b)` was added when the `BasicSliderUI` class was added. The class does not have `@since` tag, so it's inherited from the package, isn't it? The same rule applies to the constructor, doesn't it? It seems that BasicSliderUI() was added by the mistake? it was not mentioned in the bug report...Seems it is too late to delete it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19192#discussion_r1624976828 From prr at openjdk.org Mon Jun 3 23:11:21 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 3 Jun 2024 23:11:21 GMT Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute extension [v17] In-Reply-To: <4g8cfr0P4vmH4JEoBeRvCkIFeZSsjoTZTkBa98VMJsw=.11368194-d185-4213-abb4-2e7c38f0b165@github.com> References: <4g8cfr0P4vmH4JEoBeRvCkIFeZSsjoTZTkBa98VMJsw=.11368194-d185-4213-abb4-2e7c38f0b165@github.com> Message-ID: On Thu, 30 May 2024 18:45:38 GMT, Alexander Scherbatiy wrote: >> The fix adds new public `OutputBin` print attribute class which allow to set a printer output bin in a `PrinterJob` class. The corresponding internal `CustomOutputBin` class is added as well. >> >> - Constants used in `OutputBin` class are based on [Internet Printing Protocol (IPP): ?output-bin? attribute extension](https://ftp.pwg.org/pub/pwg/candidates/cs-ippoutputbin10-20010207-5100.2.pdf) document. >> - `CUPSPrinter.getOutputBins(String printer)` method uses PPD `ppdFindOption(..., "OutputBin")` function to get supported output bins for the given printer on native level. >> - The fix propagates the `OutputBin` attribute from the printer job attributes to `NSPrintInfo` print settings with `OutputBin` key on macOS. >> >> The fix was tested on `Kyocera ECOSYS M8130cidn` printer where `ppdFindOption(..., "OutputBin")` call returns 4 output bins (text, choice): >> - Printer settings, None >> - Inner tray, INNERTRAY >> - Separator tray, SEPARATORTRAY >> - Finisher (face-down), Main >> >> if `Printer settings`, `Inner tray`, or `Finisher (face-down)` CustomOutputBins is set to `PrinterJob.print(...)` attributes a test page is printed to the Main tray of the `Kyocera ECOSYS M8130cidn` printer. If `Separator tray` is used a page is printed to the Separator tray. This is consistent with the printer behavior when a native print dialog is used from a native Preview app to print a document on macOS. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Add Skip test option to the OutputBinAttributePrintDialogTest with the native dialog Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16166#pullrequestreview-2095011097 From prr at openjdk.org Mon Jun 3 23:11:21 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 3 Jun 2024 23:11:21 GMT Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute extension [v17] In-Reply-To: <5xSHxgxGdm80GElobRs2Ijm6fjaPazoH2DoCXr0lkHY=.5d6014a2-dda3-4e2f-bd11-77bb74ddc7de@github.com> References: <4g8cfr0P4vmH4JEoBeRvCkIFeZSsjoTZTkBa98VMJsw=.11368194-d185-4213-abb4-2e7c38f0b165@github.com> <5xSHxgxGdm80GElobRs2Ijm6fjaPazoH2DoCXr0lkHY=.5d6014a2-dda3-4e2f-bd11-77bb74ddc7de@github.com> Message-ID: On Mon, 3 Jun 2024 16:16:23 GMT, Alexander Scherbatiy wrote: > @prrace Should I use the integrate command with the `auto` or `delegate` parameter? Academic now, since I just approved it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16166#issuecomment-2146273729 From nbenalla at openjdk.org Mon Jun 3 23:37:07 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 3 Jun 2024 23:37:07 GMT Subject: RFR: 8332103: since-checker - Add missing `@since` tags to `java.desktop` [v2] In-Reply-To: References: Message-ID: On Wed, 15 May 2024 03:38:29 GMT, Nizar Benalla wrote: >> If you're currently reviewing this PR, thank you! >> Most fixes here are according to the reports by the since checker tool in #18934 and are pretty simple. >> >> To make reviewing easier >> - `BasicSliderUI` has the constructor `public BasicSliderUI(JSlider b)` for a long time so the default constructor (without parameters) didn't exist until JDK 16 >> >> For the `package-info` files, it is pretty hard to find source code of JDK 1-5 so I used the `grep` command to find the oldest instance of an `@since` in those packages. >> >> I found instances of `@since 1.1` in the other packages but `javax/swing/plaf/synth/package-info.java` might be worth checking as most classes there had no `@since`. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Swing was added in JDK 1.2 here is the `@since` checker tool report for `java.desktop` SinceChecker java.desktop STDERR: method: void java.awt.geom.Path2D.Double.trimToSize(): `@since` version is 9 instead of 10 method: void java.awt.geom.Path2D.Float.trimToSize(): `@since` version is 9 instead of 10 Unable to retrieve `@since` for Package: package: java.beans Unable to retrieve `@since` for Package: package: javax.swing method: void javax.swing.DefaultListModel.addAll(java.util.Collection): `@since` version is 9 instead of 11 method: void javax.swing.DefaultListModel.addAll(int,java.util.Collection): `@since` version is 9 instead of 11 method: void javax.swing.JSlider.AccessibleJSlider.stateChanged(javax.swing.event.ChangeEvent): `@since` version is 9 instead of 16 method: int javax.swing.JSlider.AccessibleJSlider.getAccessibleActionCount(): `@since` version is 9 instead of 17 method: java.lang.String javax.swing.JSlider.AccessibleJSlider.getAccessibleActionDescription(int): `@since` version is 9 instead of 17 method: boolean javax.swing.JSlider.AccessibleJSlider.doAccessibleAction(int): `@since` version is 9 instead of 17 method: void javax.swing.DefaultComboBoxModel.addAll(java.util.Collection): `@since` version is 9 instead of 11 method: void javax.swing.DefaultComboBoxModel.addAll(int,java.util.Collection): `@since` version is 9 instead of 11 method: void javax.swing.plaf.basic.BasicSliderUI.(): `@since` version is 9 instead of 16 Unable to retrieve `@since` for Package: package: javax.swing.plaf.synth field: javax.swing.text.DefaultEditorKit:beginLineUpAction: `@since` version is 9 instead of 20 field: javax.swing.text.DefaultEditorKit:endLineDownAction: `@since` version is 9 instead of 20 java.lang.Exception: The `@since` checker found 16 problems at SinceChecker.checkModule(SinceChecker.java:262) at SinceChecker.main(SinceChecker.java:123) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1575) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: The `@since` checker found 16 problems ------------- PR Comment: https://git.openjdk.org/jdk/pull/19192#issuecomment-2146298763 From nbenalla at openjdk.org Tue Jun 4 00:05:02 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Jun 2024 00:05:02 GMT Subject: RFR: 8332103: since-checker - Add missing @ since` tags to java.desktop [v2] In-Reply-To: References: <3DWE5GBi2tqZa4Kn-7roHwggZuubdIrVpZ5BGdJE0K0=.c41040ba-8370-4d26-a028-21c3c184ce0a@github.com> Message-ID: <_7E4c7iaU0LWVHYAB7mEcSj7D7fKCn3q2crFwQAy0-4=.c7440f12-05fb-40da-9222-60ffcd680f8c@github.com> On Mon, 3 Jun 2024 20:02:12 GMT, Sergey Bylokhov wrote: >>> Hmm, the _explicit_ default constructor was added in JDK 16, but it was implicit before then. So I am not 100% sure what the right answer is - the same as the class, or when it was explicitly added. >> >> I believe there was no default constructor in `BasicSliderUI()` because there was a constructor with a parameter `BasicSliderUI(JSlider b)`. >> >> Thus, this case seem to be correct `BasicSliderUI()` is available since 16. >> >> At the same time, `BasicSliderUI(JSlider b)` has existed since at least 7, the constructor is present in the history of the file. The history in GitHub goes up to 1st December 2007 which corresponds to Java 7 timeline. I'm pretty sure this constructor existed in previous releases, and you have to dig further to find when it was added. >> >> Very much likely, the constructor `BasicSliderUI(JSlider b)` was added when the `BasicSliderUI` class was added. The class does not have `@since` tag, so it's inherited from the package, isn't it? The same rule applies to the constructor, doesn't it? > > It seems that BasicSliderUI() was added by the mistake? it was not mentioned in the bug report...Seems it is too late to delete it? I'm sorry but `method: void javax.swing.plaf.basic.BasicSliderUI.()` refers to the constructor, as I use [this method](https://docs.oracle.com/en/java/javase/22/docs/api/java.compiler/javax/lang/model/element/ExecutableElement.html#getSimpleName()) to get a method's name. I am saying that there was no default constructor before JDK 16 as it doesn't appear in the compiler's historical data until then and therefore warrants an `@since` I am stealing my colleagues words but here is the general rule for when we want to add an `@since` until we publish a doc with rules for `@since` > As a practical rule for deciding whether any declaration is new or not, imagine writing a test program that refers to the most specific form of the declaration. If that test program does not compile on JDK version N-1 and does compile on version N, then it warrants having `@since N`. Put another way, `@since N` should identify the first release in which the declaration can be used in the given form ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19192#discussion_r1625176050 From alexsch at openjdk.org Tue Jun 4 03:15:22 2024 From: alexsch at openjdk.org (Alexander Scherbatiy) Date: Tue, 4 Jun 2024 03:15:22 GMT Subject: Integrated: 8314070: javax.print: Support IPP output-bin attribute extension In-Reply-To: References: Message-ID: On Thu, 12 Oct 2023 15:39:45 GMT, Alexander Scherbatiy wrote: > The fix adds new public `OutputBin` print attribute class which allow to set a printer output bin in a `PrinterJob` class. The corresponding internal `CustomOutputBin` class is added as well. > > - Constants used in `OutputBin` class are based on [Internet Printing Protocol (IPP): ?output-bin? attribute extension](https://ftp.pwg.org/pub/pwg/candidates/cs-ippoutputbin10-20010207-5100.2.pdf) document. > - `CUPSPrinter.getOutputBins(String printer)` method uses PPD `ppdFindOption(..., "OutputBin")` function to get supported output bins for the given printer on native level. > - The fix propagates the `OutputBin` attribute from the printer job attributes to `NSPrintInfo` print settings with `OutputBin` key on macOS. > > The fix was tested on `Kyocera ECOSYS M8130cidn` printer where `ppdFindOption(..., "OutputBin")` call returns 4 output bins (text, choice): > - Printer settings, None > - Inner tray, INNERTRAY > - Separator tray, SEPARATORTRAY > - Finisher (face-down), Main > > if `Printer settings`, `Inner tray`, or `Finisher (face-down)` CustomOutputBins is set to `PrinterJob.print(...)` attributes a test page is printed to the Main tray of the `Kyocera ECOSYS M8130cidn` printer. If `Separator tray` is used a page is printed to the Separator tray. This is consistent with the printer behavior when a native print dialog is used from a native Preview app to print a document on macOS. This pull request has now been integrated. Changeset: c7d2a5c1 Author: Alexander Scherbatiy URL: https://git.openjdk.org/jdk/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f Stats: 1479 lines in 25 files changed: 1476 ins; 0 del; 3 mod 8314070: javax.print: Support IPP output-bin attribute extension Reviewed-by: psadhukhan, prr ------------- PR: https://git.openjdk.org/jdk/pull/16166 From psadhukhan at openjdk.org Tue Jun 4 03:31:13 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 4 Jun 2024 03:31:13 GMT Subject: RFR: 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled In-Reply-To: References: Message-ID: On Fri, 24 May 2024 08:37:25 GMT, Jayathirth D V wrote: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is disabled and we don't see this issue) to enable printing of memory trace logs when we have OOM. But if we enable it we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. > > This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in imageioJPEG.c->imageio_dispose() function. > > Moved the logic to delete error handler after we are done with deleting IJG stored objects, after this change there is no crash. There is no regression test because this issue is seen only when we enable MEM_STATS flag in IJG library. Ran jtreg ImageIO tests with code update and i don't see any regressions. > > I have verified that this issue doesn't effect SplashScreen code path and disposing of IJG objects is handled differently in SplashScreen. Please update the copyright year when you integrate ------------- PR Comment: https://git.openjdk.org/jdk/pull/19386#issuecomment-2146515779 From abhiscxk at openjdk.org Tue Jun 4 04:51:17 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jun 2024 04:51:17 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v5] In-Reply-To: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> References: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> Message-ID: On Mon, 3 Jun 2024 05:52:31 GMT, Abhishek Kumar wrote: >> bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always >> failed which is captured in the JBS. >> The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). >> In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). >> JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). >> Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. >> >> Test verified in both single and dual screen linux machines. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Code formatting update @aivanov-jdk @alisenchung All review comments are addressed. Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19381#issuecomment-2146604743 From jdv at openjdk.org Tue Jun 4 05:15:26 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Jun 2024 05:15:26 GMT Subject: RFR: 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled [v2] In-Reply-To: References: Message-ID: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is disabled and we don't see this issue) to enable printing of memory trace logs when we have OOM. But if we enable it we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. > > This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in imageioJPEG.c->imageio_dispose() function. > > Moved the logic to delete error handler after we are done with deleting IJG stored objects, after this change there is no crash. There is no regression test because this issue is seen only when we enable MEM_STATS flag in IJG library. Ran jtreg ImageIO tests with code update and i don't see any regressions. > > I have verified that this issue doesn't effect SplashScreen code path and disposing of IJG objects is handled differently in SplashScreen. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19386/files - new: https://git.openjdk.org/jdk/pull/19386/files/abe4de70..69e9d1c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19386&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19386&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19386/head:pull/19386 PR: https://git.openjdk.org/jdk/pull/19386 From jdv at openjdk.org Tue Jun 4 05:15:26 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 4 Jun 2024 05:15:26 GMT Subject: Integrated: 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled In-Reply-To: References: Message-ID: On Fri, 24 May 2024 08:37:25 GMT, Jayathirth D V wrote: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag is disabled and we don't see this issue) to enable printing of memory trace logs when we have OOM. But if we enable it we get crash while disposing IJG stored objects in jmemmgr->free-pool() function. > > This is happening because we delete the error handler before we actually start deleting IJG stored objects and while freeing the IJG objects we try to access cinfo->err->trace_level of error handler. This early deletion of error handler is happening in imageioJPEG.c->imageio_dispose() function. > > Moved the logic to delete error handler after we are done with deleting IJG stored objects, after this change there is no crash. There is no regression test because this issue is seen only when we enable MEM_STATS flag in IJG library. Ran jtreg ImageIO tests with code update and i don't see any regressions. > > I have verified that this issue doesn't effect SplashScreen code path and disposing of IJG objects is handled differently in SplashScreen. This pull request has now been integrated. Changeset: ca307263 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/ca3072635215755766575b4eb70dc6267969a550 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled Reviewed-by: abhiscxk, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/19386 From duke at openjdk.org Tue Jun 4 05:42:11 2024 From: duke at openjdk.org (lawrence.andrews) Date: Tue, 4 Jun 2024 05:42:11 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly In-Reply-To: References: Message-ID: <-9pNOJjhwYsxaKFttjdbK90NLuK_h7_zdfJF34V-JX4=.238be8bf-13aa-4477-b84c-9dae6247d5a5@github.com> On Mon, 3 Jun 2024 12:22:53 GMT, Ravi Gupta wrote: > This testcase checks for the following assertions for Component events: > > 1. When components are resized, moved, hidden and shown the respective events are triggered. > 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. > 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. > 4. When a window is minimized/restored then hidden and shown component events should be triggered. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Copyright is missing. Please add the Copyright. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19521#issuecomment-2146654476 From aivanov at openjdk.org Tue Jun 4 11:30:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 11:30:12 GMT Subject: RFR: 8325435: [macos] Menu or JPopupMenu not closed when main window is resized [v2] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 06:07:37 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1031: >> >>> 1029: (p.x >= (frame.origin.x + contentRect.size.width - 3)) || >>> 1030: (fabs(frame.origin.x - p.x) < 3) || >>> 1031: (fabs(frame.origin.y - p.y) < 3)) { >> >> Does `fabs` use float? It makes code more compact but it may be imprecise and less performant than integer arithmetics. > > Yes..https://man7.org/linux/man-pages/man3/fabs.3.html and [CGFLoat ](https://developer.apple.com/documentation/corefoundation/cgfloat?language=objc) can be double/float and fabs can accomodate both, in this case it uses double...We have tested on 3 different systems without any issue so would keep it for now until we find any adverse effect and also it is better to accommodate double in hi-dpi environment which is the case in OSX I see, the coordinates are floats, then it's perfectly fine. I assumed the coordinates were integers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19474#discussion_r1625831262 From rkannathpari at openjdk.org Tue Jun 4 12:14:18 2024 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 4 Jun 2024 12:14:18 GMT Subject: RFR: JDK-8333360 : PrintNullString.java doesn't use float arguments Message-ID: Hi Reviewers, I have updated the test case with passing float value for evaluation and a typo. Please review and let me know your suggestions if any. ------------- Commit messages: - JDK-8333360 : PrintNullString.java doesn't use float arguments Changes: https://git.openjdk.org/jdk/pull/19540/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19540&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333360 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19540/head:pull/19540 PR: https://git.openjdk.org/jdk/pull/19540 From aivanov at openjdk.org Tue Jun 4 13:06:08 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 13:06:08 GMT Subject: RFR: JDK-8333360 : PrintNullString.java doesn't use float arguments In-Reply-To: References: Message-ID: <7whstDavtA1e0HqmbQyI0sjvvlAH10Ao3U9riFGRyEI=.88c84270-26c9-45b1-89ba-1c9b1ae5632b@github.com> On Tue, 4 Jun 2024 12:07:40 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > I have updated the test case with passing float value for evaluation and a typo. Please review and let me know your suggestions if any. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19540#pullrequestreview-2096332476 From aivanov at openjdk.org Tue Jun 4 13:48:17 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 13:48:17 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v5] In-Reply-To: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> References: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> Message-ID: On Mon, 3 Jun 2024 05:52:31 GMT, Abhishek Kumar wrote: >> bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always >> failed which is captured in the JBS. >> The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). >> In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). >> JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). >> Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. >> >> Test verified in both single and dual screen linux machines. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Code formatting update Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java line 1: > 1: /* You should update the copyright year. test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 64: > 62: } catch (Exception e) { > 63: throw new SkippedException("GTK LAF is not supported on this system;" + > 64: " test passes"); Suggestion: throw new SkippedException("GTK LAF is not supported on this system"); I'd remove the additional message. I believe it was `println` before. test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 116: > 114: } > 115: > 116: private void onBackgroundThread20() { This method should run on EDT because it accesses the state of the components. test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 124: > 122: Point loc = ref.getLocationOnScreen(); > 123: Rectangle refRect = > 124: new Rectangle(loc.x, loc.y, ref.getWidth(), ref.getHeight()); Suggestion: Rectangle refRect = new Rectangle(loc, ref.getSize()); test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 133: > 131: Rectangle testRect = > 132: new Rectangle(loc.x, loc.y, > 133: test.getWidth(), test.getHeight()); Suggestion: loc = test.getLocationOnScreen(); Rectangle testRect = new Rectangle(test.getLocationOnScreen(), test.getSize()); Choose one style and adjust both statements, `refRect` and `testRect`. test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 136: > 134: BufferedImage testimg = robot.createScreenCapture(testRect); > 135: > 136: if (refimg.getWidth() != testimg.getWidth() I suggest moving the part that compares the images into a helper method. Alternatively, you can use [`Util.compareBufferedImages`](https://github.com/openjdk/jdk/blob/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2/test/jdk/javax/swing/regtesthelpers/Util.java#L59-L80). test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 137: > 135: > 136: if (refimg.getWidth() != testimg.getWidth() > 137: || refimg.getHeight() != testimg.getHeight()) Suggestion: if (refimg.getWidth() != testimg.getWidth() || refimg.getHeight() != testimg.getHeight()) One more space, it should be aligned to the inside of the parenthesis. test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 148: > 146: if (refPixel != testPixel) { > 147: fail("Image comparison failed at (" + > 148: x + "," + y + ") for image " + index); Adding `count` and `k` to diagnostic message could help identifying the failing case quicker. ------------- PR Review: https://git.openjdk.org/jdk/pull/19381#pullrequestreview-2096399951 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626048836 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626007721 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626017821 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626017048 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626024722 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626046506 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626023890 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626048214 From aivanov at openjdk.org Tue Jun 4 13:48:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 13:48:18 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v3] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 05:48:18 GMT, Abhishek Kumar wrote: >> Previous formatting was less confusing and aligned with Java Coding Style Guidelines. >> >> The parameters to the method are aligned to the opening parenthesis; the `throws` clause is not part of the parameters and it's placed on another line according to rules of wrapping lines (it should've used double-indentation of 8 spaces rather than 4 spaces to indicate a continuation line). > > Reverted back to previous formatting with double-indentation. Hopefully this should be ok now. This formatting looks good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626008412 From abhiscxk at openjdk.org Tue Jun 4 14:49:24 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jun 2024 14:49:24 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v6] In-Reply-To: References: Message-ID: <1JF5RewsCw_XfdStWsssMu22XcOxprr19nmbvZ5F8b0=.283b07ff-fdf4-4515-acd1-bb836f9b200f@github.com> > bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always > failed which is captured in the JBS. > The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). > In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). > JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). > Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. > > Test verified in both single and dual screen linux machines. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19381/files - new: https://git.openjdk.org/jdk/pull/19381/files/f94e4b0c..0afa8d87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19381&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19381&range=04-05 Stats: 32 lines in 1 file changed: 4 ins; 14 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/19381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19381/head:pull/19381 PR: https://git.openjdk.org/jdk/pull/19381 From abhiscxk at openjdk.org Tue Jun 4 14:49:25 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jun 2024 14:49:25 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v5] In-Reply-To: References: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> Message-ID: On Tue, 4 Jun 2024 13:45:44 GMT, Alexey Ivanov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Code formatting update > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java line 1: > >> 1: /* > > You should update the copyright year. Updated. > test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 64: > >> 62: } catch (Exception e) { >> 63: throw new SkippedException("GTK LAF is not supported on this system;" + >> 64: " test passes"); > > Suggestion: > > throw new SkippedException("GTK LAF is not supported on this system"); > > I'd remove the additional message. I believe it was `println` before. Updated. > test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 116: > >> 114: } >> 115: >> 116: private void onBackgroundThread20() { > > This method should run on EDT because it accesses the state of the components. Updated to run this on EDT. > test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 133: > >> 131: Rectangle testRect = >> 132: new Rectangle(loc.x, loc.y, >> 133: test.getWidth(), test.getHeight()); > > Suggestion: > > loc = test.getLocationOnScreen(); > Rectangle testRect = new Rectangle(test.getLocationOnScreen(), > test.getSize()); > > Choose one style and adjust both statements, `refRect` and `testRect`. Updated to use same style for both places. > test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 136: > >> 134: BufferedImage testimg = robot.createScreenCapture(testRect); >> 135: >> 136: if (refimg.getWidth() != testimg.getWidth() > > I suggest moving the part that compares the images into a helper method. Alternatively, you can use [`Util.compareBufferedImages`](https://github.com/openjdk/jdk/blob/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2/test/jdk/javax/swing/regtesthelpers/Util.java#L59-L80). Ok.. Updated [Util.compareBufferedImages](https://github.com/openjdk/jdk/blob/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2/test/jdk/javax/swing/regtesthelpers/Util.java#L59-L80) to compare images. > test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 137: > >> 135: >> 136: if (refimg.getWidth() != testimg.getWidth() >> 137: || refimg.getHeight() != testimg.getHeight()) > > Suggestion: > > if (refimg.getWidth() != testimg.getWidth() > || refimg.getHeight() != testimg.getHeight()) > > One more space, it should be aligned to the inside of the parenthesis. Used Util to compare images, so these lines are removed now. > test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 148: > >> 146: if (refPixel != testPixel) { >> 147: fail("Image comparison failed at (" + >> 148: x + "," + y + ") for image " + index); > > Adding `count` and `k` to diagnostic message could help identifying the failing case quicker. Don't find adding `k` to diagnostic message useful.. failure message is more relevant now about the images which are compared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626152744 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626146072 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626148142 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626150340 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626150884 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626149792 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626152392 From aivanov at openjdk.org Tue Jun 4 15:27:21 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 15:27:21 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v5] In-Reply-To: References: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> Message-ID: <43nTjWQ2WpU3nVlZ_kqrFseab8jIMR0VetMiS_4RGYM=.1292528d-41ed-4e53-b98c-1d2b9edabe17@github.com> On Tue, 4 Jun 2024 14:46:37 GMT, Abhishek Kumar wrote: >> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java line 1: >> >>> 1: /* >> >> You should update the copyright year. > > Updated. I can't see it in the PR. Didn't push? >> test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java line 148: >> >>> 146: if (refPixel != testPixel) { >>> 147: fail("Image comparison failed at (" + >>> 148: x + "," + y + ") for image " + index); >> >> Adding `count` and `k` to diagnostic message could help identifying the failing case quicker. > > Don't find adding `k` to diagnostic message useful.. failure message is more relevant now about the images which are compared. The images themselves are more useful for sure. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626209941 PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626214172 From abhiscxk at openjdk.org Tue Jun 4 15:37:00 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jun 2024 15:37:00 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v7] In-Reply-To: References: Message-ID: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> > bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always > failed which is captured in the JBS. > The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). > In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). > JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). > Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. > > Test verified in both single and dual screen linux machines. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19381/files - new: https://git.openjdk.org/jdk/pull/19381/files/0afa8d87..649c3ad8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19381&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19381&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19381/head:pull/19381 PR: https://git.openjdk.org/jdk/pull/19381 From abhiscxk at openjdk.org Tue Jun 4 15:37:04 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 4 Jun 2024 15:37:04 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v5] In-Reply-To: <43nTjWQ2WpU3nVlZ_kqrFseab8jIMR0VetMiS_4RGYM=.1292528d-41ed-4e53-b98c-1d2b9edabe17@github.com> References: <8hZIogqzuK-8k1f86o78ZN1hVGirUuoX6R_XY75rNAQ=.850b0447-6774-49ae-bb52-75c4c5020716@github.com> <43nTjWQ2WpU3nVlZ_kqrFseab8jIMR0VetMiS_4RGYM=.1292528d-41ed-4e53-b98c-1d2b9edabe17@github.com> Message-ID: On Tue, 4 Jun 2024 15:21:30 GMT, Alexey Ivanov wrote: >> Updated. > > I can't see it in the PR. Didn't push? Oh my bad, I missed to add that changes. Pushed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19381#discussion_r1626228348 From aivanov at openjdk.org Tue Jun 4 15:53:34 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 15:53:34 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v7] In-Reply-To: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> References: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> Message-ID: On Tue, 4 Jun 2024 15:37:00 GMT, Abhishek Kumar wrote: >> bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always >> failed which is captured in the JBS. >> The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). >> In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). >> JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). >> Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. >> >> Test verified in both single and dual screen linux machines. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19381#pullrequestreview-2096810770 From aivanov at openjdk.org Tue Jun 4 16:06:20 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 16:06:20 GMT Subject: RFR: 8332103: since-checker - Add missing @ since tags to java.desktop [v2] In-Reply-To: <_7E4c7iaU0LWVHYAB7mEcSj7D7fKCn3q2crFwQAy0-4=.c7440f12-05fb-40da-9222-60ffcd680f8c@github.com> References: <3DWE5GBi2tqZa4Kn-7roHwggZuubdIrVpZ5BGdJE0K0=.c41040ba-8370-4d26-a028-21c3c184ce0a@github.com> <_7E4c7iaU0LWVHYAB7mEcSj7D7fKCn3q2crFwQAy0-4=.c7440f12-05fb-40da-9222-60ffcd680f8c@github.com> Message-ID: On Tue, 4 Jun 2024 00:02:56 GMT, Nizar Benalla wrote: >> It seems that BasicSliderUI() was added by the mistake? it was not mentioned in the bug report...Seems it is too late to delete it? > > I'm sorry but `method: void javax.swing.plaf.basic.BasicSliderUI.()` refers to the constructor, > as I use [this method](https://docs.oracle.com/en/java/javase/22/docs/api/java.compiler/javax/lang/model/element/ExecutableElement.html#getSimpleName()) to get a method's name. > > I am saying that there was no default constructor before JDK 16 as it doesn't appear in the compiler's historical data until then and therefore warrants an `@since` > > I am stealing my colleagues words but here is the general rule for when we want to add an `@since` until we publish a doc with rules for `@since` > >> As a practical rule for deciding whether any declaration is new or not, imagine writing a test program that refers to the most specific form of the declaration. If that test program does not compile on JDK version N-1 and does compile on version N, then it warrants having `@since N`. Put another way, `@since N` should identify the first release in which the declaration can be used in the given form > It seems that BasicSliderUI() was added by the mistake? it was not mentioned in the bug report...Seems it is too late to delete it? I agree. It shouldn't have been added. Instead of adding `@since`, the constructor should be removed. It requires a CSR. The longer it exists, the more chances there are that it's used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19192#discussion_r1626272799 From aivanov at openjdk.org Tue Jun 4 16:32:48 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 16:32:48 GMT Subject: RFR: 8332103: since-checker - Add missing @ since tags to java.desktop [v2] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 23:33:53 GMT, Nizar Benalla wrote: > method: void java.awt.geom.Path2D.Double.trimToSize(): `@since` version is 9 instead of 10 > method: void java.awt.geom.Path2D.Float.trimToSize(): `@since` version is 9 instead of 10 In JDK 10, a new method `trimToSize` was added to Path2D. It is marked with `@since 10`. `Path2D.Float` and `Path2D.Double` override the method or rather implement it. Does this require an explicit `@since` tag? I'm unsure about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19192#issuecomment-2147928711 From aivanov at openjdk.org Tue Jun 4 16:33:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 4 Jun 2024 16:33:07 GMT Subject: RFR: 8332103: since-checker - Add missing @ since tags to java.desktop [v2] In-Reply-To: References: Message-ID: On Wed, 15 May 2024 03:38:29 GMT, Nizar Benalla wrote: >> If you're currently reviewing this PR, thank you! >> Most fixes here are according to the reports by the since checker tool in #18934 and are pretty simple. >> >> To make reviewing easier >> - `BasicSliderUI` has the constructor `public BasicSliderUI(JSlider b)` for a long time so the default constructor (without parameters) didn't exist until JDK 16 >> >> For the `package-info` files, it is pretty hard to find source code of JDK 1-5 so I used the `grep` command to find the oldest instance of an `@since` in those packages. >> >> I found instances of `@since 1.1` in the other packages but `javax/swing/plaf/synth/package-info.java` might be worth checking as most classes there had no `@since`. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Swing was added in JDK 1.2 src/java.desktop/share/classes/java/awt/geom/Path2D.java line 297: > 295: /** > 296: * @since 10 > 297: */ Not sure it's required? If it is, you should also add explicit `{@inheritDoc}`: Suggestion: /** * {@inheritDoc} * * @since 10 */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19192#discussion_r1626298196 From dnguyen at openjdk.org Tue Jun 4 17:05:03 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 4 Jun 2024 17:05:03 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v7] In-Reply-To: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> References: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> Message-ID: On Tue, 4 Jun 2024 15:37:00 GMT, Abhishek Kumar wrote: >> bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always >> failed which is captured in the JBS. >> The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). >> In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). >> JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). >> Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. >> >> Test verified in both single and dual screen linux machines. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year update Ran bug6492108.java with changes. LGTM. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/19381#pullrequestreview-2096958201 From abhiscxk at openjdk.org Wed Jun 5 04:56:55 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jun 2024 04:56:55 GMT Subject: RFR: JDK-8333360 : PrintNullString.java doesn't use float arguments In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 12:07:40 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > I have updated the test case with passing float value for evaluation and a typo. Please review and let me know your suggestions if any. test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 172: > 170: > 171: try { > 172: g2d.drawString(emptyIterator, 20.0f, 180.0f); Does the line below also need to change ? `g2d.drawString("FAILURE: No IAE for empty iterator, float", 20.0f 180.0f);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19540#discussion_r1626943802 From tr at openjdk.org Wed Jun 5 05:05:06 2024 From: tr at openjdk.org (Tejesh R) Date: Wed, 5 Jun 2024 05:05:06 GMT Subject: RFR: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F [v7] In-Reply-To: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> References: <9kXE2aEVIsdI4gfi8PjJedxGczhDvs96CsDkvB8xDXg=.3a55cf17-6398-4994-ba66-def5242ab271@github.com> Message-ID: On Tue, 4 Jun 2024 15:37:00 GMT, Abhishek Kumar wrote: >> bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always >> failed which is captured in the JBS. >> The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). >> In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). >> JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). >> Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. >> >> Test verified in both single and dual screen linux machines. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year update LGTM. ------------- Marked as reviewed by tr (Committer). PR Review: https://git.openjdk.org/jdk/pull/19381#pullrequestreview-2098039565 From rgupta at openjdk.org Wed Jun 5 08:29:11 2024 From: rgupta at openjdk.org (Ravi Gupta) Date: Wed, 5 Jun 2024 08:29:11 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly [v2] In-Reply-To: References: Message-ID: > This testcase checks for the following assertions for Component events: > > 1. When components are resized, moved, hidden and shown the respective events are triggered. > 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. > 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. > 4. When a window is minimized/restored then hidden and shown component events should be triggered. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: 8333403: Copyright Header added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19521/files - new: https://git.openjdk.org/jdk/pull/19521/files/21f65db1..6af855c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=00-01 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19521.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19521/head:pull/19521 PR: https://git.openjdk.org/jdk/pull/19521 From duke at openjdk.org Wed Jun 5 08:29:11 2024 From: duke at openjdk.org (Vanitha B P) Date: Wed, 5 Jun 2024 08:29:11 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly [v2] In-Reply-To: References: Message-ID: <9LmCKnL16ABcNk0Ye3bcq75RKbGUWotBQGOI76pHvRo=.c7f747a9-3139-4f26-b15d-c2c06d7ff0c8@github.com> On Wed, 5 Jun 2024 08:26:45 GMT, Ravi Gupta wrote: >> This testcase checks for the following assertions for Component events: >> >> 1. When components are resized, moved, hidden and shown the respective events are triggered. >> 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. >> 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. >> 4. When a window is minimized/restored then hidden and shown component events should be triggered. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8333403: Copyright Header added test/jdk/java/awt/event/ComponentEvent/ComponentEventTest.java line 1: > 1: import java.awt.Button; Copyright header is missing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19521#discussion_r1624632842 From abhiscxk at openjdk.org Wed Jun 5 08:43:57 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jun 2024 08:43:57 GMT Subject: RFR: 8331619: TabbedPane's contentOpaque, tabsOpaque and setOpaque doesn't work properly in Aqua LAF In-Reply-To: References: Message-ID: On Fri, 10 May 2024 17:33:53 GMT, Sergey Bylokhov wrote: >> JTabbedPane's contentOpaque and tabsOpaque properties are not honored in Aqua L&F. JTabbedPane's content area and tab background color are not as expected when tabbedpane opacity is set to true or false. Fix is to handle the opacity behavior correctly and inline with other LAF as well. >> >> Existing test `TestBackgroundScrollPolicy.java` failed with the proposed fix and it is updated to run only for linux and windows platform because the content area for tabbedpane is rendered to the width and height of tabbedpane starting from (0, 0) position (https://github.com/openjdk/jdk/blob/cf7c97732320d70de5f5725c920d5c3861a2c9c8/src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java#L684C16-L684C16) and that leaves no place for tab area behind tabs. >> >> CI testing is green after this test update and link posted in JBS. > > The Aqua L&F mimics the behavior of the native UI on macOS. Is it possible to change all these properties in the native apps? @mrserb I am going to close this bug as "Not an issue" as I couldn't find any ways to check this behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19170#issuecomment-2149224348 From duke at openjdk.org Wed Jun 5 09:29:57 2024 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 5 Jun 2024 09:29:57 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 08:29:11 GMT, Ravi Gupta wrote: >> This testcase checks for the following assertions for Component events: >> >> 1. When components are resized, moved, hidden and shown the respective events are triggered. >> 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. >> 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. >> 4. When a window is minimized/restored then hidden and shown component events should be triggered. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8333403: Copyright Header added test/jdk/java/awt/event/ComponentEvent/ComponentEventTest.java line 57: > 55: private static boolean componentShown = false; > 56: private static boolean componentMoved = false; > 57: private static boolean componentResized = false; Can you add volatile to this fields ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19521#discussion_r1627354560 From aivanov at openjdk.org Wed Jun 5 12:22:57 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 5 Jun 2024 12:22:57 GMT Subject: RFR: JDK-8333360 : PrintNullString.java doesn't use float arguments In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 04:53:56 GMT, Abhishek Kumar wrote: >> Hi Reviewers, >> I have updated the test case with passing float value for evaluation and a typo. Please review and let me know your suggestions if any. > > test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 172: > >> 170: >> 171: try { >> 172: g2d.drawString(emptyIterator, 20.0f, 180.0f); > > Does the line below also need to change ? > `g2d.drawString("FAILURE: No IAE for empty iterator, float", 20.0f 180.0f);` No, it does not. It may though. The test declares it verifies `drawString(Iterator, float, float)` ? the test does it now. How the error message is output on the screen isn't important: either `int` or `float` version will do the same thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19540#discussion_r1627655778 From abhiscxk at openjdk.org Wed Jun 5 16:05:58 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jun 2024 16:05:58 GMT Subject: RFR: JDK-8333360 : PrintNullString.java doesn't use float arguments In-Reply-To: References: Message-ID: <2TRvuBRajhVFaTfPFvEH1a4CGBnJCgQ86MfIWjJ-Jks=.d3ab95f4-3842-4a0c-bb3e-0a8f00953772@github.com> On Wed, 5 Jun 2024 12:20:00 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/print/PrinterJob/PrintNullString.java line 172: >> >>> 170: >>> 171: try { >>> 172: g2d.drawString(emptyIterator, 20.0f, 180.0f); >> >> Does the line below also need to change ? >> `g2d.drawString("FAILURE: No IAE for empty iterator, float", 20.0f 180.0f);` > > No, it does not. It may though. > > The test declares it verifies `drawString(Iterator, float, float)` ? the test does it now. How the error message is output on the screen isn't important: either `int` or `float` version will do the same thing. @aivanov-jdk Thank you for clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19540#discussion_r1628050634 From abhiscxk at openjdk.org Wed Jun 5 16:06:08 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jun 2024 16:06:08 GMT Subject: Integrated: 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F In-Reply-To: References: Message-ID: <_4ST0sd_pscsrooh9EEgaJks3MRFh6wpdV-2VEXDphI=.dc55420e-c55f-4051-9864-b07b35a50f6e@github.com> On Fri, 24 May 2024 06:44:06 GMT, Abhishek Kumar wrote: > bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "_headful_" in it's initial version, it never failed but after the fix of [JDK-8287051](https://bugs.openjdk.org/browse/JDK-8287051) this test was problem listed as it always > failed which is captured in the JBS. > The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at [L767](https://github.com/kumarabhi006/jdk/blob/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L767). > In initial load JEditorPane, JTextArea and JTextPane components are opaque at [L718](https://github.com/kumarabhi006/jdk/blame/6c7656678916ff3f5c9fc70efcbb69ce76801458/jdk/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L718) but after the fix for [JDK-8145547](https://bugs.openjdk.org/browse/JDK-8145547) the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the [GTK version is not 3](https://github.com/kumarabhi006/jdk/blame/73d2181d56063f6015e4fc42e130591bee39bc36/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L746C21-L746C21). > JTextPane's issue was observed by [JDK-8218479](https://bugs.openjdk.org/browse/JDK-8218479) and then the default opacity is set to true for JTextPane [irrespective of GTK version](https://github.com/kumarabhi006/jdk/blame/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java#L750C16-L750C16). > Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue. > > Test verified in both single and dual screen linux machines. This pull request has now been integrated. Changeset: 5dcb7a62 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/5dcb7a627e1cfb360719a25722588180e5de9d09 Stats: 150 lines in 2 files changed: 146 ins; 1 del; 3 mod 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F Reviewed-by: aivanov, dnguyen, tr ------------- PR: https://git.openjdk.org/jdk/pull/19381 From abhiscxk at openjdk.org Wed Jun 5 16:09:57 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jun 2024 16:09:57 GMT Subject: RFR: JDK-8333360 : PrintNullString.java doesn't use float arguments In-Reply-To: References: Message-ID: <-QgO5tn3zVWDQHgBQoqqIsS3_X0PQDSuzIctZ7KpIEM=.fce75697-4095-46a6-b937-aaa30723b716@github.com> On Tue, 4 Jun 2024 12:07:40 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > I have updated the test case with passing float value for evaluation and a typo. Please review and let me know your suggestions if any. Ran the updated test and looks good to me. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/19540#pullrequestreview-2099660380 From abhiscxk at openjdk.org Wed Jun 5 16:14:11 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 5 Jun 2024 16:14:11 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v2] In-Reply-To: References: Message-ID: > "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. > > Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). > CI testing is green and link is mentioned in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19391/files - new: https://git.openjdk.org/jdk/pull/19391/files/7443451c..03671372 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19391&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19391&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19391/head:pull/19391 PR: https://git.openjdk.org/jdk/pull/19391 From achung at openjdk.org Wed Jun 5 22:30:50 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 5 Jun 2024 22:30:50 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 16:14:11 GMT, Abhishek Kumar wrote: >> "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. >> >> Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). >> CI testing is green and link is mentioned in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year update src/java.desktop/share/classes/javax/swing/table/JTableHeader.java line 1368: > 1366: try { > 1367: parentLocation = parent.getLocationOnScreen(); > 1368: } catch (IllegalComponentStateException icse) { should we be preventing the exception by checking if the JTableHeader is visible or not instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19391#discussion_r1628508394 From duke at openjdk.org Wed Jun 5 23:35:52 2024 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Wed, 5 Jun 2024 23:35:52 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v11] In-Reply-To: <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com> References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com> Message-ID: On Sun, 5 May 2024 10:17:40 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Update to lastest > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Remove tab > - Update to latest and make code safer > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea Keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2151124130 From achung at openjdk.org Thu Jun 6 00:02:47 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 00:02:47 GMT Subject: RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF [v5] In-Reply-To: <1co-Ps6TTyOt_Ldn_7NOPJ34K-LMFNyMKdkM9BepHNs=.4fe5cfcf-ebdf-4bd9-bc04-d7dd1583597e@github.com> References: <1co-Ps6TTyOt_Ldn_7NOPJ34K-LMFNyMKdkM9BepHNs=.4fe5cfcf-ebdf-4bd9-bc04-d7dd1583597e@github.com> Message-ID: On Fri, 31 May 2024 08:49:17 GMT, Abhishek Kumar wrote: >> In GTK LAF, the menu mnemonics are always displayed which is different from the native behavior. In native application **(tested with gedit**), the menu mnemonics toggle on press of `ALT` key. Menu mnemonics are hidden initially and then toggles between show/hide on `ALT` press. >> Proposed fix is to handle the `ALT` key press for GTK LAF and mimic the native behavior. Fix is similar to the `ALT` key processing in Windows LAF. Automated test case is added to verify the fix and tested in Ubuntu and Oracle linux. >> >> CI testing is green and link attached in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fix Marked as reviewed by achung (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18992#pullrequestreview-2100484965 From achung at openjdk.org Thu Jun 6 00:08:53 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 00:08:53 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup Message-ID: Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup ------------- Commit messages: - fix trailing whitespace in instructions string - fix line ender - fix whitespaces and newline - fix whitespaces and newline - init commit Changes: https://git.openjdk.org/jdk/pull/19569/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315655 Stats: 85 lines in 2 files changed: 84 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From honkar at openjdk.org Thu Jun 6 05:07:43 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 6 Jun 2024 05:07:43 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 23:33:21 GMT, Alisen Chung wrote: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Fix works as expected and similar to native apps. test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 53: > 51: 3) Observe that the popup menu assigned to the inner JPanel appears > 52: (macOS) or does not appear (Windows, Linux) > 53: """; Pass or Fail condition not clear from the instructions. rephrase? ------------- PR Review: https://git.openjdk.org/jdk/pull/19569#pullrequestreview-2100801401 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1628777810 From abhiscxk at openjdk.org Thu Jun 6 05:14:45 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jun 2024 05:14:45 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 22:27:43 GMT, Alisen Chung wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright year update > > src/java.desktop/share/classes/javax/swing/table/JTableHeader.java line 1368: > >> 1366: try { >> 1367: parentLocation = parent.getLocationOnScreen(); >> 1368: } catch (IllegalComponentStateException icse) { > > should we be preventing the exception by checking if the JTableHeader is visible or not instead? As per the spec, getLocationOnScreen() API can throw ICSE and it should be right to catch this exception rather than preventing it upfront by checking JTableHeader's visibility. Moreover, I tried checking with the visibility, still got the ICSE while performing the testing. So, I think this should be an ideal way to handle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19391#discussion_r1628783298 From achung at openjdk.org Thu Jun 6 05:26:53 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 05:26:53 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v2] In-Reply-To: References: Message-ID: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' of github.com:openjdk/jdk into 8315655 - fix trailing whitespace in instructions string - fix line ender - fix whitespaces and newline - fix whitespaces and newline - init commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19569/files - new: https://git.openjdk.org/jdk/pull/19569/files/d8758e03..bf890aa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=00-01 Stats: 589 lines in 11 files changed: 487 ins; 2 del; 100 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From tr at openjdk.org Thu Jun 6 05:31:48 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 6 Jun 2024 05:31:48 GMT Subject: RFR: 8333403: Write a test to check various components events are triggered properly [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 08:29:11 GMT, Ravi Gupta wrote: >> This testcase checks for the following assertions for Component events: >> >> 1. When components are resized, moved, hidden and shown the respective events are triggered. >> 2. When the components are hidden/disabled also,the component events like resized/moved are triggered. >> 3. When a hidden component is hidden again, or a visible component is shown again, the events should not be fired. >> 4. When a window is minimized/restored then hidden and shown component events should be triggered. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8333403: Copyright Header added test/jdk/java/awt/event/ComponentEvent/ComponentEventTest.java line 54: > 52: private static Frame frame; > 53: private static Component[] components; > 54: private static boolean componentHidden = false; These boolean variables should be volatile since they are set in Listener. test/jdk/java/awt/event/ComponentEvent/ComponentEventTest.java line 152: > 150: currentComponent.setVisible(false); > 151: frame.invalidate(); > 152: frame.validate(); frame.invalidate(); frame.validate(); Can move these two into separate method and call it since its been used in several places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19521#discussion_r1628779521 PR Review Comment: https://git.openjdk.org/jdk/pull/19521#discussion_r1628794155 From psadhukhan at openjdk.org Thu Jun 6 07:19:44 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 6 Jun 2024 07:19:44 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 05:26:53 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' of github.com:openjdk/jdk into 8315655 > - fix trailing whitespace in instructions string > - fix line ender > - fix whitespaces and newline > - fix whitespaces and newline > - init commit I guess it needs to be understood why it is not failing in windows and linux and only reproducible in macos. The fix in BasicLookAndFeel is not appropriate in my opinion as that shared code will be exercised in windows and linux too.. I guess we need to find out why `BasicLookAndFeel.evenDIspatched` is called for MOUSE_PRESSED in macos and not in windows/linux (ie only called for MOUSE_RELEASED event), maybe something needs to be done in macos JDK native event processing to ensure it is only called for "mouse release" event for showing popup. Also, the test can be automated as it is about popup being shown or not which can be easily checked by `isPopupMenuVIsible/isVisible` method ------------- PR Comment: https://git.openjdk.org/jdk/pull/19569#issuecomment-2151571243 From kizune at openjdk.org Thu Jun 6 07:31:44 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 6 Jun 2024 07:31:44 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 05:11:41 GMT, Abhishek Kumar wrote: >> src/java.desktop/share/classes/javax/swing/table/JTableHeader.java line 1368: >> >>> 1366: try { >>> 1367: parentLocation = parent.getLocationOnScreen(); >>> 1368: } catch (IllegalComponentStateException icse) { >> >> should we be preventing the exception by checking if the JTableHeader is visible or not instead? > > As per the spec, getLocationOnScreen() API can throw ICSE and it should be right to catch this exception. Moreover, I tried checking with the JTableHeader's visibility, still got the ICSE while performing the testing. So, I think this should be an ideal way to handle. That is very strange - the only reason getLocationOnScreen should throw ICSE is when component is not showing on the screen. So if you ask parent.isShowing() and it returns true but you still getting the exception - you need to investigate what is going on, this is not a normal behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19391#discussion_r1628913998 From abhiscxk at openjdk.org Thu Jun 6 08:47:44 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jun 2024 08:47:44 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 07:28:59 GMT, Alexander Zuev wrote: >> As per the spec, getLocationOnScreen() API can throw ICSE and it should be right to catch this exception. Moreover, I tried checking with the JTableHeader's visibility, still got the ICSE while performing the testing. So, I think this should be an ideal way to handle. > > That is very strange - the only reason getLocationOnScreen should throw ICSE is when component is not showing on the screen. So if you ask parent.isShowing() and it returns true but you still getting the exception - you need to investigate what is going on, this is not a normal behavior. Actually I was checking visibility with `parent.isVisible()` and this is always `true` but I was getting exception for getLocationOnScreen method. But when checked with `parent.isShowing()` then it behaves correctly, whenever it returns `false`, there is no exception as it doesn't go inside condition and when it returns `true`, `getLocationOnScreen` works as expected. So, I guess `parent.isShowing` check should be sufficient to handle the exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19391#discussion_r1629036998 From abhiscxk at openjdk.org Thu Jun 6 09:05:10 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jun 2024 09:05:10 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v3] In-Reply-To: References: Message-ID: > "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. > > Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). > CI testing is green and link is mentioned in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Condition check updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19391/files - new: https://git.openjdk.org/jdk/pull/19391/files/03671372..edb02c06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19391&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19391&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19391/head:pull/19391 PR: https://git.openjdk.org/jdk/pull/19391 From abhiscxk at openjdk.org Thu Jun 6 09:17:13 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jun 2024 09:17:13 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v4] In-Reply-To: References: Message-ID: <6gcd_G2G4pNCShkaSsh_bdXm4PS22cei33d-JFBIPOQ=.a7b1c3d8-db65-47f6-b9e3-98b89305ee55@github.com> > "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. > > Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). > CI testing is green and link is mentioned in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Remove unused import and added null check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19391/files - new: https://git.openjdk.org/jdk/pull/19391/files/edb02c06..e902496d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19391&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19391&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19391/head:pull/19391 PR: https://git.openjdk.org/jdk/pull/19391 From duke at openjdk.org Thu Jun 6 09:48:59 2024 From: duke at openjdk.org (Nikita Provotorov) Date: Thu, 6 Jun 2024 09:48:59 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v11] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com> Message-ID: On Wed, 5 Jun 2024 23:33:32 GMT, ??? wrote: >> ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Update to lastest >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Remove tab >> - Update to latest and make code safer >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea > > Keep alive @quantum6, could you take a look at https://github.com/openjdk/jdk/pull/13055#issuecomment-2100914601? I believe it's a quite serious problem ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2151863055 From achung at openjdk.org Thu Jun 6 15:27:58 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 15:27:58 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v3] In-Reply-To: References: Message-ID: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8315655' of github.com:alisenchung/jdk into 8315655 - fix broken test, add MOUSE_RELEASED ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19569/files - new: https://git.openjdk.org/jdk/pull/19569/files/bf890aa9..ab7e71fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From achung at openjdk.org Thu Jun 6 15:30:44 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 15:30:44 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 07:16:42 GMT, Prasanta Sadhukhan wrote: > I guess it needs to be understood why it is not failing in windows and linux and only reproducible in macos. The fix in BasicLookAndFeel is not appropriate in my opinion as that shared code will be exercised in windows and linux too.. > > I guess we need to find out why `BasicLookAndFeel.evenDIspatched` is called for MOUSE_PRESSED in macos and not in windows/linux (ie only called for MOUSE_RELEASED event), maybe something needs to be done in macos JDK native event processing to ensure it is only called for "mouse release" event for showing popup. > > Also, the test can be automated as it is about popup being shown or not which can be easily checked by `isPopupMenuVIsible/isVisible` method I guess the root of the issue is that MOUSE_ENTERED is a popup trigger in macos only. I can look into NSEvent isPopupTrigger and change the code to require the event to be MOUSE_PRESSED/MOUSE_RELEASED ------------- PR Comment: https://git.openjdk.org/jdk/pull/19569#issuecomment-2152817659 From kizune at openjdk.org Thu Jun 6 15:35:46 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 6 Jun 2024 15:35:46 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v4] In-Reply-To: <6gcd_G2G4pNCShkaSsh_bdXm4PS22cei33d-JFBIPOQ=.a7b1c3d8-db65-47f6-b9e3-98b89305ee55@github.com> References: <6gcd_G2G4pNCShkaSsh_bdXm4PS22cei33d-JFBIPOQ=.a7b1c3d8-db65-47f6-b9e3-98b89305ee55@github.com> Message-ID: On Thu, 6 Jun 2024 09:17:13 GMT, Abhishek Kumar wrote: >> "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. >> >> Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). >> CI testing is green and link is mentioned in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import and added null check Looks good now. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19391#pullrequestreview-2102324774 From achung at openjdk.org Thu Jun 6 15:50:44 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 15:50:44 GMT Subject: RFR: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location [v4] In-Reply-To: <6gcd_G2G4pNCShkaSsh_bdXm4PS22cei33d-JFBIPOQ=.a7b1c3d8-db65-47f6-b9e3-98b89305ee55@github.com> References: <6gcd_G2G4pNCShkaSsh_bdXm4PS22cei33d-JFBIPOQ=.a7b1c3d8-db65-47f6-b9e3-98b89305ee55@github.com> Message-ID: On Thu, 6 Jun 2024 09:17:13 GMT, Abhishek Kumar wrote: >> "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. >> >> Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). >> CI testing is green and link is mentioned in JBS. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import and added null check LGTM ------------- Marked as reviewed by achung (Committer). PR Review: https://git.openjdk.org/jdk/pull/19391#pullrequestreview-2102360969 From abhiscxk at openjdk.org Thu Jun 6 15:55:48 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 6 Jun 2024 15:55:48 GMT Subject: Integrated: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location In-Reply-To: References: Message-ID: On Fri, 24 May 2024 11:38:30 GMT, Abhishek Kumar wrote: > "java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location" is thrown when getLocationOnScreen method is invoked for JTableHeader while testing JFileChooser demo. It seems that in getLocationOfScreen method we are trying to access the parent location but that is not visible and ICSE is thrown. > > Fix is to handle the exception and can be verified using the steps mentioned in [JDK-8332550](https://bugs.openjdk.org/browse/JDK-8332550). > CI testing is green and link is mentioned in JBS. This pull request has now been integrated. Changeset: 054362ab Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/054362abe040938b87eb1a1cab8a0a94540e0667 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location Reviewed-by: asemenov, kizune, achung ------------- PR: https://git.openjdk.org/jdk/pull/19391 From achung at openjdk.org Thu Jun 6 16:08:31 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 16:08:31 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: References: Message-ID: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: add event check in popup trigger ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19569/files - new: https://git.openjdk.org/jdk/pull/19569/files/ab7e71fe..fb89d2f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=02-03 Stats: 11 lines in 4 files changed: 5 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From achung at openjdk.org Thu Jun 6 16:13:53 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 16:13:53 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 07:16:42 GMT, Prasanta Sadhukhan wrote: >> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' of github.com:openjdk/jdk into 8315655 >> - fix trailing whitespace in instructions string >> - fix line ender >> - fix whitespaces and newline >> - fix whitespaces and newline >> - init commit > > I guess it needs to be understood why it is not failing in windows and linux and only reproducible in macos. The fix in BasicLookAndFeel is not appropriate in my opinion as that shared code will be exercised in windows and linux too.. > > I guess we need to find out why `BasicLookAndFeel.evenDIspatched` is called for MOUSE_PRESSED in macos and not in windows/linux (ie only called for MOUSE_RELEASED event), maybe something needs to be done in macos JDK native event processing to ensure it is only called for "mouse release" event for showing popup. > > Also, the test can be automated as it is about popup being shown or not which can be easily checked by `isPopupMenuVIsible/isVisible` method @prsadhuk I've updated the fix to only affect macOS code. I changed NSEvent isPopupTrigger to check for MOUSE_PRESSED or MOUSE_RELEASED java events. Please take a look ------------- PR Comment: https://git.openjdk.org/jdk/pull/19569#issuecomment-2152906675 From achung at openjdk.org Thu Jun 6 18:28:12 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 18:28:12 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v5] In-Reply-To: References: Message-ID: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: - update copyright years - automated test - changed test to automatic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19569/files - new: https://git.openjdk.org/jdk/pull/19569/files/fb89d2f7..ed5d5393 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=03-04 Stats: 68 lines in 3 files changed: 41 ins; 2 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From dnguyen at openjdk.org Thu Jun 6 18:28:12 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 6 Jun 2024 18:28:12 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 16:08:31 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > add event check in popup trigger Don't forget to update the years for the copyrights at the top of each file changed. src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java line 276: > 274: && jeventType != MouseEvent.MOUSE_RELEASED) { > 275: return false; > 276: } Just to double check, are the only jeventTypes to trigger popups using mouse? Could there be other event types, maybe using keyboard for example with tab/arrows & enter? ------------- PR Review: https://git.openjdk.org/jdk/pull/19569#pullrequestreview-2102841943 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630012827 From achung at openjdk.org Thu Jun 6 18:28:12 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 18:28:12 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: References: Message-ID: <0N70Sl9tXODuPzjve8gA6o3EPfFQBAtkoUMz_ufo95k=.305f8739-0ff0-413f-8b1d-dedd648afb75@github.com> On Thu, 6 Jun 2024 16:08:31 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > add event check in popup trigger I've automated the test and confirmed that it fails before the fix and passes after the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19569#issuecomment-2153140229 From achung at openjdk.org Thu Jun 6 18:43:45 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 18:43:45 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 18:18:14 GMT, Damon Nguyen wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> add event check in popup trigger > > src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java line 276: > >> 274: && jeventType != MouseEvent.MOUSE_RELEASED) { >> 275: return false; >> 276: } > > Just to double check, are the only jeventTypes to trigger popups using mouse? Could there be other event types, maybe using keyboard for example with tab/arrows & enter? I believe only MouseEvents can be popup triggers. I checked in MouseEvent that there is a field for popup triggers and no such field in KeyEvent. The isPopupTrigger method here also previously checked button down masks already, so adding a check for the correct mouse events shouldn't be an issue even if there was a way to show a popup menu with a different event type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630039417 From achung at openjdk.org Thu Jun 6 21:39:29 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 21:39:29 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v11] In-Reply-To: <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com> References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com> Message-ID: On Sun, 5 May 2024 10:17:40 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Update to lastest > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Remove tab > - Update to latest and make code safer > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea src/java.desktop/unix/classes/sun/awt/X11/XInputMethod.java line 61: > 59: } > 60: > 61: @Override why do these functions need the override tag now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13055#discussion_r1630286038 From achung at openjdk.org Thu Jun 6 23:37:27 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 6 Jun 2024 23:37:27 GMT Subject: RFR: 8185429: [macos] After the dialog is closed, there is no window become active Message-ID: Add a check for previous focused window on modal unblocking. If the owner of a closing dialog was the last focused window, then the owner of the dialog should regain focus. ------------- Commit messages: - update copyright years - init commit Changes: https://git.openjdk.org/jdk/pull/19588/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19588&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8185429 Stats: 8 lines in 2 files changed: 6 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19588/head:pull/19588 PR: https://git.openjdk.org/jdk/pull/19588 From psadhukhan at openjdk.org Fri Jun 7 07:26:19 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jun 2024 07:26:19 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v5] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 18:28:12 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update copyright years > - automated test > - changed test to automatic test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 44: > 42: */ > 43: public class MouseDragPopupTest { > 44: static boolean failed; volatile test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 48: > 46: static JPanel panel; > 47: static JPanel innerPanel; > 48: static JPopupMenu menu; guess these 2 can be local vars.. test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 54: > 52: public static void main(String[] args) throws Exception { > 53: SwingUtilities.invokeAndWait(() -> { > 54: createAndShowGUI(); normally after frame is created, we do robot.waitForIdle and robot.delay(1000) before accessing the frame location or test other things.. test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 83: > 81: > 82: if (failed) { > 83: throw new RuntimeException("Popup was shown, Test Failed."); frame needs to be disposed at end.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630760974 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630762974 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630761930 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630763411 From psadhukhan at openjdk.org Fri Jun 7 07:26:17 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jun 2024 07:26:17 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: References: Message-ID: <7c_ooHjDs9wukNxIZ4gdyGJZh0AiSYEXcv1DF5z5IrM=.25d6b8c4-ef3d-4a91-b1a2-5ecd4e75bad7@github.com> On Thu, 6 Jun 2024 18:41:16 GMT, Alisen Chung wrote: >> src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java line 276: >> >>> 274: && jeventType != MouseEvent.MOUSE_RELEASED) { >>> 275: return false; >>> 276: } >> >> Just to double check, are the only jeventTypes to trigger popups using mouse? Could there be other event types, maybe using keyboard for example with tab/arrows & enter? > > I believe only MouseEvents can be popup triggers. I checked in MouseEvent that there is a field for popup triggers and no such field in KeyEvent. > > The isPopupTrigger method here also previously checked button down masks already, so adding a check for the correct mouse events shouldn't be an issue even if there was a way to show a popup menu with a different event type. looks good.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630760813 From psadhukhan at openjdk.org Fri Jun 7 07:38:13 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jun 2024 07:38:13 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v5] In-Reply-To: References: Message-ID: <1iBr694ztsYUBhWywfkZWuvs3zS4liAIhhHapxTVWUQ=.0c416a5d-0b38-4ca9-a891-aa62967e3ff9@github.com> On Thu, 6 Jun 2024 18:28:12 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update copyright years > - automated test > - changed test to automatic test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 39: > 37: * @test > 38: * @bug 8315655 > 39: * @requires (os.family == "mac") Also, is there any need to restrict it to mac as I guess in other platforms, this test should anyway pass...Did you check? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630776745 From psadhukhan at openjdk.org Fri Jun 7 07:42:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 7 Jun 2024 07:42:12 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: <7c_ooHjDs9wukNxIZ4gdyGJZh0AiSYEXcv1DF5z5IrM=.25d6b8c4-ef3d-4a91-b1a2-5ecd4e75bad7@github.com> References: <7c_ooHjDs9wukNxIZ4gdyGJZh0AiSYEXcv1DF5z5IrM=.25d6b8c4-ef3d-4a91-b1a2-5ecd4e75bad7@github.com> Message-ID: On Fri, 7 Jun 2024 07:20:35 GMT, Prasanta Sadhukhan wrote: >> I believe only MouseEvents can be popup triggers. I checked in MouseEvent that there is a field for popup triggers and no such field in KeyEvent. >> >> The isPopupTrigger method here also previously checked button down masks already, so adding a check for the correct mouse events shouldn't be an issue even if there was a way to show a popup menu with a different event type. > > looks good.. Although there's one more issue it seems where in native, after popup is shown when right mouse button (or CTRL+left mouse button) is pressed, if you release the mouse the popup vanishes which I noticed in Notes, Mail but it does not happen in JDK and popup remains open...but it seems not related to this...did you notice? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1630781731 From serb at openjdk.org Fri Jun 7 18:14:13 2024 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 7 Jun 2024 18:14:13 GMT Subject: RFR: 8185429: [macos] After the dialog is closed, there is no window become active In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 23:28:07 GMT, Alisen Chung wrote: > Add a check for previous focused window on modal unblocking. If the owner of a closing dialog was the last focused window, then the owner of the dialog should regain focus. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 1062: > 1060: > 1061: Window currFocus = LWKeyboardFocusManagerPeer.getInstance().getCurrentFocusedWindow(); > 1062: if (!blocked && target.equals(currFocus)) { it is better to use "==" instead of "equals" which might be overridden by the app. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19588#discussion_r1631545097 From achung at openjdk.org Fri Jun 7 20:34:23 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 7 Jun 2024 20:34:23 GMT Subject: RFR: 8185429: [macos] After the dialog is closed, there is no window become active [v2] In-Reply-To: References: Message-ID: > Add a check for previous focused window on modal unblocking. If the owner of a closing dialog was the last focused window, then the owner of the dialog should regain focus. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: use == over .equals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19588/files - new: https://git.openjdk.org/jdk/pull/19588/files/ff754beb..310af4b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19588&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19588&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19588.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19588/head:pull/19588 PR: https://git.openjdk.org/jdk/pull/19588 From achung at openjdk.org Fri Jun 7 21:06:13 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 7 Jun 2024 21:06:13 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: References: <7c_ooHjDs9wukNxIZ4gdyGJZh0AiSYEXcv1DF5z5IrM=.25d6b8c4-ef3d-4a91-b1a2-5ecd4e75bad7@github.com> Message-ID: <1dT3joPoBn4Qi2wSM6I49F5-LLZsGx_vMTzMn6GIyfo=.7aa1ce37-fab8-43d4-8b5a-64b007d6b8d0@github.com> On Fri, 7 Jun 2024 07:40:01 GMT, Prasanta Sadhukhan wrote: >> looks good.. > > Although there's one more issue it seems where in native, after popup is shown when right mouse button (or CTRL+left mouse button) is pressed, if you release the mouse the popup vanishes which I noticed in Notes, Mail but it does not happen in JDK and popup remains open...but it seems not related to this...did you notice? Hmm, not sure why. I doubt it's related to this since both MOUSE_PRESSED and MOUSE_RELEASED are still popuptriggers before and after the fix. I can make a new issue for this to match native behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1631688661 From achung at openjdk.org Fri Jun 7 21:10:13 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 7 Jun 2024 21:10:13 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v4] In-Reply-To: <1dT3joPoBn4Qi2wSM6I49F5-LLZsGx_vMTzMn6GIyfo=.7aa1ce37-fab8-43d4-8b5a-64b007d6b8d0@github.com> References: <7c_ooHjDs9wukNxIZ4gdyGJZh0AiSYEXcv1DF5z5IrM=.25d6b8c4-ef3d-4a91-b1a2-5ecd4e75bad7@github.com> <1dT3joPoBn4Qi2wSM6I49F5-LLZsGx_vMTzMn6GIyfo=.7aa1ce37-fab8-43d4-8b5a-64b007d6b8d0@github.com> Message-ID: On Fri, 7 Jun 2024 21:03:58 GMT, Alisen Chung wrote: >> Although there's one more issue it seems where in native, after popup is shown when right mouse button (or CTRL+left mouse button) is pressed, if you release the mouse the popup vanishes which I noticed in Notes, Mail but it does not happen in JDK and popup remains open...but it seems not related to this...did you notice? > > Hmm, not sure why. I doubt it's related to this since both MOUSE_PRESSED and MOUSE_RELEASED are still popuptriggers before and after the fix. I can make a new issue for this to match native behavior. I've tested that interaction before and after the fix and it's the same behavior. The initial MOUSE_PRESSED will open a popup, then the subsequent MOUSE_RELEASED will do nothing. When the popup is already open, the MOUSE_PRESSED will close the popup, but the MOUSE_RELEASED will do nothing. So it's unrelated to this fix but it might be something to do with MOUSE_RELEASED or maybe MOUSE_DRAGGED/MOUSE_CLICKED cancelling the popup behavior. I can look to make a fix separate from this issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1631694648 From achung at openjdk.org Fri Jun 7 21:19:41 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 7 Jun 2024 21:19:41 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v6] In-Reply-To: References: Message-ID: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: update test based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19569/files - new: https://git.openjdk.org/jdk/pull/19569/files/ed5d5393..452dcac9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=04-05 Stats: 52 lines in 1 file changed: 21 ins; 9 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From achung at openjdk.org Fri Jun 7 22:29:16 2024 From: achung at openjdk.org (Alisen Chung) Date: Fri, 7 Jun 2024 22:29:16 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v5] In-Reply-To: <1iBr694ztsYUBhWywfkZWuvs3zS4liAIhhHapxTVWUQ=.0c416a5d-0b38-4ca9-a891-aa62967e3ff9@github.com> References: <1iBr694ztsYUBhWywfkZWuvs3zS4liAIhhHapxTVWUQ=.0c416a5d-0b38-4ca9-a891-aa62967e3ff9@github.com> Message-ID: On Fri, 7 Jun 2024 07:35:19 GMT, Prasanta Sadhukhan wrote: >> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: >> >> - update copyright years >> - automated test >> - changed test to automatic > > test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 39: > >> 37: * @test >> 38: * @bug 8315655 >> 39: * @requires (os.family == "mac") > > Also, is there any need to restrict it to mac as I guess in other platforms, this test should anyway pass...Did you check? I've removed the restriction, the test passes on all platforms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1631752491 From dnguyen at openjdk.org Fri Jun 7 23:18:12 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 7 Jun 2024 23:18:12 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v6] In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 21:19:41 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > update test based on feedback Tested with and without the fix. Automating it does relieve the need to give a detailed pass/fail condition. Small nit suggestion. test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 59: > 57: }); > 58: robot.waitForIdle(); > 59: robot.delay(1000); Suggestion: robot.setAutoDelay(100); robot.setAutoWaitForIdle(true); SwingUtilities.invokeAndWait(() -> { createAndShowGUI(); }); robot.delay(1000); I was able to remove all the individual `waitForIdle()` calls and replaced it with `setAutoWaitForIdle()`. Still seemed to work fine on macOS. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/19569#pullrequestreview-2105491407 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1631772988 From achung at openjdk.org Sat Jun 8 00:52:17 2024 From: achung at openjdk.org (Alisen Chung) Date: Sat, 8 Jun 2024 00:52:17 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v6] In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 23:14:47 GMT, Damon Nguyen wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> update test based on feedback > > test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 59: > >> 57: }); >> 58: robot.waitForIdle(); >> 59: robot.delay(1000); > > Suggestion: > > robot.setAutoDelay(100); > robot.setAutoWaitForIdle(true); > > SwingUtilities.invokeAndWait(() -> { > createAndShowGUI(); > }); > robot.delay(1000); > > > I was able to remove all the individual `waitForIdle()` calls and replaced it with `setAutoWaitForIdle()`. Still seemed to work fine on macOS. Most tests i've looked at aren't using setAutoWaitForIdle(). Are there any issues with test stability? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1631797841 From psadhukhan at openjdk.org Mon Jun 10 06:01:18 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jun 2024 06:01:18 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v6] In-Reply-To: References: Message-ID: <7A1Ksuc-vA9JrrS_gJHU0Vc4onOTWfKBFXucW7C8eqQ=.00ef3291-d451-4e72-ad93-376a0e44e313@github.com> On Fri, 7 Jun 2024 21:19:41 GMT, Alisen Chung wrote: >> Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. >> The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > update test based on feedback test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 40: > 38: * @bug 8315655 > 39: * @key headful > 40: * @run main MouseDragPopupTest summary tag missing test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 45: > 43: static volatile boolean failed; > 44: static volatile JFrame frame; > 45: static volatile JPanel panel; frame and panel are/should be accessed in EDT only so no need for volatile test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 51: > 49: public static void main(String[] args) throws Exception { > 50: try { > 51: failed = false; By default boolean class variable is false, no need to set explicitly.. test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 71: > 69: dstPoint.translate(4 * d.width / 15, 0); > 70: > 71: unnecessary line test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java line 84: > 82: robot.waitForIdle(); > 83: > 84: robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK); Better to release in `finally` block so that if unexpectedly any exception occurs it will not hamper any other test if tun as part of CI job.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1632616431 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1632616227 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1632615767 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1632616684 PR Review Comment: https://git.openjdk.org/jdk/pull/19569#discussion_r1632618131 From psadhukhan at openjdk.org Mon Jun 10 06:04:14 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 10 Jun 2024 06:04:14 GMT Subject: RFR: 8233177: Remove testcase for JDK-8001470 as fix has been reverted [v3] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 07:50:15 GMT, Prasanta Sadhukhan wrote: >> Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters. >> Tried block character in the test which is now being loaded properly leading to correct height.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test removed as corresponding fix is reverted keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/17528#issuecomment-2157333247 From nbenalla at openjdk.org Mon Jun 10 12:34:16 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 10 Jun 2024 12:34:16 GMT Subject: RFR: 8332099: since-checker - Add @ since to package-info in jdk.jsobject In-Reply-To: References: Message-ID: On Sun, 12 May 2024 00:37:26 GMT, Nizar Benalla wrote: > Simple code cleanup. > If you're reviewing this, thanks. keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/19197#issuecomment-2158219905 From jwaters at openjdk.org Mon Jun 10 13:07:48 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 10 Jun 2024 13:07:48 GMT Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v3] In-Reply-To: References: Message-ID: > WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Capstone Support - Add check for compiler in configure - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18915/files - new: https://git.openjdk.org/jdk/pull/18915/files/09fb3d65..b0b088e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=01-02 Stats: 121745 lines in 2137 files changed: 85534 ins; 24227 del; 11984 mod Patch: https://git.openjdk.org/jdk/pull/18915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915 PR: https://git.openjdk.org/jdk/pull/18915 From achung at openjdk.org Mon Jun 10 20:01:47 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 10 Jun 2024 20:01:47 GMT Subject: RFR: 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup [v7] In-Reply-To: References: Message-ID: > Issue is a mouse drag will trigger a popup in macos, but not in linux or windows. > The solution is to add a check for a mouse pressed event to show popup and prevent mouse entered events from triggering the popup Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: updated test, removed robot waitForIdles, jtreg summary, release in finally ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19569/files - new: https://git.openjdk.org/jdk/pull/19569/files/452dcac9..06a7c212 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19569&range=05-06 Stats: 16 lines in 1 file changed: 3 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19569/head:pull/19569 PR: https://git.openjdk.org/jdk/pull/19569 From dnguyen at openjdk.org Mon Jun 10 20:05:33 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update Message-ID: This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: https://cr.openjdk.org/~dnguyen/output2/ ------------- Commit messages: - Review comment edits - Initial localization changes Changes: https://git.openjdk.org/jdk/pull/19609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333827 Stats: 239 lines in 39 files changed: 133 ins; 57 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/19609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609 PR: https://git.openjdk.org/jdk/pull/19609 From achung at openjdk.org Mon Jun 10 20:05:33 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. > > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. > > Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: > https://cr.openjdk.org/~dnguyen/output2/ Just a question about the reverted translations, otherwise LGTM > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated? ------------- PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2105526180 PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2155723513 From jlu at openjdk.org Mon Jun 10 20:05:33 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com> On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. > > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. > > Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: > https://cr.openjdk.org/~dnguyen/output2/ Cannot speak to the translations themselves, but in general the changes LGTM pending the comments. src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1: > 1: # It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions. src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66: > 64: label.size=??(&Z): > 65: label.source=??(&C): > 66: label.outputbins=????(&P)? Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278: > 276: UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}". > 277: UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden. > 278: ENTITYFailedInitializeGrammar = ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool. src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285: > 283: VIRTUAL_MACHINE=Virtuelle Maschine > 284: VM_ARGUMENTS=VM-Argumente > 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183: > 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts > 182: > 183: help.usage = Verwendung: jshell