Re: RFR: 8260719: Input method character moves with caret

On Tue, 2 Feb 2021 12:35:52 GMT, Dmitry Markov wrote: >> @dmarkov20 please take a look > > If I got it right the problem takes place only on MacOS. I could not > reproduce the issue on Windows. However the fix is located at common code. I > would recommend moving it to

Re: RFR: 8260719: Input method character moves with caret

On Mon, 1 Feb 2021 22:06:06 GMT, Sergey Bylokhov wrote: >> I've fixed annoying behaviour of input methods in text components. >> Code checks caret position before submitting composed text. > > @dmarkov20 please take a look If I got it right the problem takes place only on MacOS. I could not rep

Re: [16] RFR 8136363: Nimbus-LaF: background color cleared when setting component name of JToolBar

+1 Regards, Dmitry > On 24 Aug 2020, at 20:20, Alexey Ivanov wrote: > > Looks fine to me too. > > Regards, > Alexey > > On 24/08/2020 00:02, Sergey Bylokhov wrote: >> Looks fine. >> >> On 17.08.2020 12:26, Kumar Abhishek wrote: >>> Hi Sergey/Alexey, >>> >>> Thank you for the suggestion. >>>

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

Thank you, Magnus! Dmitry > On 4 Nov 2019, at 10:24, Magnus Ihse Bursie > wrote: > > > > On 2019-11-03 16:38, Dmitry Markov wrote: >> Alexey and Sergey, thank you for the approval! >> I wonder whether it is enough or I need one more “+1” from build-folk. > Y

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

The changes look good to me. >> On 01/11/2019 13:09, Dmitry Markov wrote: >>> Hi Alexey, >>> >>> I have updated the fix. Please find the new version here: >>> http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ >>> >>> Thanks, >>&g

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

gt; > I'd recommend adding quotes around the option to look for: > 448 in the right-side pane look for "Turn off Windows key hotkeys" and double > click on it; > > Consider adding an empty line before this line > 450 Note: restart is required to make the settings

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

, i.e. no backticks. > > (For my understanding, "Turn keyboard access on or off" turns off only one > specific shortcut, i.e. Ctrl+F1?) Yes, that’s right. I have added clarification to the doc. > > > Regards, > Alexey > > On 28/10/2019 17:23, Dmit

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

an provide CTRL+F1 which is used > > > On 10/25/19 3:27 am, Dmitry Markov wrote: >> Hello, >> Could you review the fix for jdk14, please? >> bug: https://bugs.openjdk.java.net/browse/JDK-8232880 >> <https://bugs.openjdk.java.net/browse/JDK-8232880>

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

Thank you for the review, Erik! I will update the fix as you suggested before push if you do not mind. Thanks, Dmitry > On 25 Oct 2019, at 14:00, Erik Joelsson wrote: > > Looks good. I would put in a "the" before "operating system". > > /Erik > >

RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

Hello, Could you review the fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8232880 webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/ So

Re: [14] RFR 8232605: [macos] There is no Tooltip message displayed when Ctrl+F1 is clicked.

> On 24 Oct 2019, at 02:36, Sergey Bylokhov wrote: > > On 10/23/19 3:17 am, Dmitry Markov wrote: >> I agree the generic documentation should be updated. I have opened >> https://bugs.openjdk.java.net/browse/JDK-8232880 >> <https://bugs.openjdk.java.net/bro

Re: [14] RFR 8232605: [macos] There is no Tooltip message displayed when Ctrl+F1 is clicked.

est. > It is applicable to the manual and automatic tests. > Probably it is time to add a new block related to client to > open/doc/testing.md? > > On 10/22/19 3:45 am, Dmitry Markov wrote: >> Hi Sergey, >> You are right, if the system reservation for “CTRL” + “F1” key se

Re: [14] RFR 8232605: [macos] There is no Tooltip message displayed when Ctrl+F1 is clicked.

If it is reserved by operation from System Preferences -> Keyboard -> > Shortcuts, > then the right thing to do is to disable all system shortcuts. It is > applicable to > all test systems win/lin/mac/etc. > > On 10/21/19 2:51 am, Dmitry Markov wrote: >> The key sequen

[14] RFR 8232605: [macos] There is no Tooltip message displayed when Ctrl+F1 is clicked.

Hello, Could you review a fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8232605 webrev: http://cr.openjdk.java.net/~dmarkov/8232605/webrev.00/ The key sequence “

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

t; On 8/20/19 2:18 am, Dmitry Markov wrote: >> Any feedback regarding the test? > > I guess you need to rephrase the text(to select the element by the keyboard) > because if the user > will select the menu item by the mouse the tooltip will be visible even > before the fix. &

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Thank you, Prasanta. Sergey, Any feedback regarding the test? Thanks, Dmitry > On 20 Aug 2019, at 09:01, Prasanta Sadhukhan > wrote: > > +1 > > Regards > Prasanta > On 19-Aug-19 8:44 PM, Dmitry Markov wrote: >> Hi Prasanta, >> >> Thank you for th

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Prasanta Sadhukhan > wrote: > > Fix looks ok to me but I think a testcase is required, even if manual. > > Regards > Prasanta > On 16-Aug-19 2:23 PM, Dmitry Markov wrote: >> I still need a second reviewer. Any volunteers? >> >> Thank you in advance, >>

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

I still need a second reviewer. Any volunteers? Thank you in advance, Dmitry > On 8 Aug 2019, at 08:37, Dmitry Markov wrote: > > Thank you, Sergey! > Looking for the second “+1”. > > Dmitry > >> On 8 Aug 2019, at 00:25, Sergey Bylokhov > <mailto:s

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Thank you, Sergey! Looking for the second “+1”. Dmitry > On 8 Aug 2019, at 00:25, Sergey Bylokhov wrote: > > Looks fine. > > - dmitry.mar...@oracle.com wrote: > > > > Hi Sergey, > > > > I looked into your suggestion again and found that it is possible t

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Hi Sergey, I looked into your suggestion again and found that it is possible to use MenuKeyListener inside ToolTipManager without new event generation. So I updated the fix based on your recommendation. Please find the new version here: http://cr.openjdk.java.net/~dmarkov/8225505/webrev.02/

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Hi Sergey, > On 2 Aug 2019, at 01:12, Sergey Bylokhov wrote: > > Hi, Dmitry. > > On 01.08.2019 06:26, Dmitry Markov wrote: >> I agree it is not a good practice to use keyPressed event without >> corresponding keyReleased. So I added its generation. Please find

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Hi Sergey, Thank you for your feedback. Please find my answer inline. Thanks, Dmitry > On 1 Aug 2019, at 05:20, Sergey Bylokhov wrote: > > Hi, Dmitry. > > On 27.06.2019 02:59, Dmitry Markov wrote: >> BasicPopupMenuUI.MenuKeyboardHelper should detect tool tip key sequen

Re: [14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Friendly reminder. Thanks, Dmitry > On 27 Jun 2019, at 12:59, Dmitry Markov wrote: > > Hello, > > Could you review a fix for jdk14, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8225505 > <https://bugs.openjdk.java.net/browse/JDK-82

[14] RFR 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)

Hello, Could you review a fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8225505 webrev: http://cr.openjdk.java.net/~dmarkov/8225505/webrev.00/ Prob

Re: [macos] regression in dialog modality in High Sierra and Mojave

> It was Java 8 > > Thanks, > Vlad > > On Thu, Jan 31, 2019 at 5:25 PM Dmitry Markov <mailto:dmitry.mar...@oracle.com>> wrote: > Hi Vlad, > > I cannot reproduce the issue on High Sierra with JDK11 and JDK12. What > version of java do you use? > > Thanks,

Re: [macos] regression in dialog modality in High Sierra and Mojave

Hi Vlad, I cannot reproduce the issue on High Sierra with JDK11 and JDK12. What version of java do you use? Thanks, Dmitry > On 19 Nov 2018, at 10:52, Vladislav Protasov > wrote: > > Hi All, > > Please see > https://bugs.openjdk.java.net/browse/JDK-8182638 >

Re: [12] Review request for 8187364: Unable to enter zero width non-joiner (ZWNJ) symbol in Swing text component

Hi Anton, The fix looks good. Thanks, Dmitry > On 9 Nov 2018, at 16:09, Anton Litvinov wrote: > > Hello reviewers, > > This is a kind reminder. Could anybody please look at this review request? > > Thank you, > Anton > > On 02/11/2018 22:32, Anton Litvinov wrote: >> Hello, >> >> Could you

Re: Swing dev>[12] Review request for JDK-8189253: [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu

Hi Manajit, Please find my answer inline. Thanks, Dmitry > On 5 Nov 2018, at 17:29, Manajit Halder wrote: > > Hi Dmitry, > > Thanks for you reply. Please find my reply inline. > > Regards, > Manajit > > On 01/11/18 4:59 PM, Dmitry Markov wrote: >

Re: Mouse click cause MOUSE_EXITED and MOUSE_ENTERED event on macOS

Hi Reto, I guess, the problem you observed and JDK-8050478 may have the same root cause. The fix for JDK-8050478 was integrated into jdk9-b137 and jdk8u152 (not released yet). I recommend tha

Re: [9] Review request for 8157322: Several typos in javadoc

(UnsupportedAudioFileException.java for example). It is not necessary to send a new webrev. On 19.05.16 13:35, dmitry markov wrote: Hello, Could you review a simple fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8157322 webrev: http://cr.openjdk.java.net/~dmarkov/8157322/webrev.00/ Fixed

[9] Review request for 8157322: Several typos in javadoc

Hello, Could you review a simple fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8157322 webrev: http://cr.openjdk.java.net/~dmarkov/8157322/webrev.00/ Fixed several typos in client libraries javadoc. Thanks, Dmitry

Re: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument

I ran related JCK and regression tests and did not observe any failures. Thanks, Dmitry On 08/10/2014 16:04, Alexander Scherbatiy wrote: The fix looks good to me. Could you also test the fix with the JCK and regression tests? Thanks, Alexandr. On 10/8/2014 2:08 PM, dmitry markov

Re: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument

, we can not position the caret before the inserted fragment without this change. I do not think it should depend on insertInBody value. Thanks, Dmitry On 08/10/2014 12:29, Alexander Scherbatiy wrote: On 10/8/2014 10:32 AM, dmitry markov wrote: Hello, Any volunteers to review the fix? Could

Re: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument

Hello, Any volunteers to review the fix? Thanks, Dmitry On 03/10/2014 09:58, dmitry markov wrote: Hello, Friendly reminder... Could anyone review the fix, please? Thanks, Dmitry On 29/09/2014 11:10, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https

Re: [9] Review request for 8058120: Rendering / caret errors with HTMLDocument

Hello, Friendly reminder... Could anyone review the fix, please? Thanks, Dmitry On 29/09/2014 11:10, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8058120 webrev: http://cr.openjdk.java.net/~dmarkov/8058120/jdk9

[9] Review request for 8058120: Rendering / caret errors with HTMLDocument

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8058120 webrev: http://cr.openjdk.java.net/~dmarkov/8058120/jdk9/webrev.00/ Problem description: if some text (not wrapped by HTML tags) is inserted via insertAfterEnd() method, the text is

Re: JRE version for the fix of JDK-8042465

Hello Lily, You are right JDK-8042465 was fixed. Unfortunately the fix was not integrated in JRE 1.7.67. It was included into JRE 1.7.76 and JRE 1.7.80-b02. As far as I know these JREs should be released in the beginning of 2015. Also JRE 1.8.20 contains the fix. It was released several weeks

Re: [9] Review request for 8048110: Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow

Hi Alexandr, I have added updateAfterChange() method as you suggested. New version is located at http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.03/ Thanks, Dmitry On 08/09/2014 14:44, Alexander Scherbatiy wrote: On 8/27/2014 2:44 PM, dmitry markov wrote: Hello Alexandr, Thank you

Re: [9] Review request for 8048110: Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow

Friendly reminder Thanks, Dmitry On 27/08/2014 14:44, dmitry markov wrote: Hello Alexandr, Thank you for the review. I have updated the fix according to your comments. Please find new version here - http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.02/ Now FlowView.forwardUpdate

Re: [9] Review request for 8048110: Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow

ld be considered when forwarding (i.e. new child views should not get notified)." Does it mean that new views will be updated twice first in the FlowView.forwardUpdate() method and second during initialization? Thanks, Alexandr. On 8/21/2014 1:03 PM, dmitry markov wrote: Hello,

Re: [9] Review request for 8048110: Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow

Hello, Reminder. Could you review this, please? Thanks, Dmitry On 18/08/2014 12:10, dmitry markov wrote: Hello Sergey, LogicalView.forwardUpdate() sends update event to all views followed by the changed place. This event will cause view to drop the cache and re-calculate its break points

Re: [9] Review request for 8048110: Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow

Hello Sergey, LogicalView.forwardUpdate() sends update event to all views followed by the changed place. This event will cause view to drop the cache and re-calculate its break points. This method was added under JDK-8024395 and intended for t

[9] Review request for 8048110: Using tables in JTextPane leads to infinite loop in FlowLayout.layoutRow

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8048110 webrev: http://cr.openjdk.java.net/~dmarkov/8048110/jdk9/webrev.00/ The LogicalView.forwardUpdate() should send an update event to the views followed by the changed place, only when

Re: [9] Review request for 8048506: [macosx] javax.swing.PopupFactory issue with null owner

hanks, Dmitry On 30/06/2014 12:23, Petr Pchelko wrote: Hello, Dmitry. Why are you making the test mac-specific? Why should it fail on other platforms? Could you please replace the anonymous inner class with a method reference in the test. With best regards. Petr. On 30 июня 2014 г., at 11:19, d

[9] Review request for 8048506: [macosx] javax.swing.PopupFactory issue with null owner

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8048506 webrev: http://cr.openjdk.java.net/~dmarkov/8048506/jdk9/webrev.00/ Problem description: this is regression caused by the changes for JDK-8042465 Fix: added null check to PopupFactor

Re: [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac

when an app is running with the default L&F. What is the solution for custom L&Fs? Can we move the logic for cache disabling to the shared popup-related code somewhere so that the issue is fixed for all L&Fs at once? -- best regards, Anthony On 5/26/2014 4:08 PM, dmitry markov w

Re: [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac

/2014 11:04, dmitry markov wrote: Hi Petr, Anthony, Thank you for looking at this. I really missed the case pointed out by Petr. If the test app is running in browser instead of IDE or appletviewer, the situation is much worse - the opened popup does not hide at all when we switch to another

Re: [9] Review request for 8032874: ArrayIndexOutOfBoundsException in JTable while clearing data in JTable

On 14/04/2014 17:06, Alexander Scherbatiy wrote: On 4/14/2014 4:33 PM, dmitry markov wrote: Alexandr, Please find my answer below. Thanks, Dmitry On 14/04/2014 14:12, Alexander Scherbatiy wrote: On 4/14/2014 10:59 AM, dmitry markov wrote: Hi Alexandr, Thank you for the review. According

Re: [9] Review request for 8032874: ArrayIndexOutOfBoundsException in JTable while clearing data in JTable

Alexandr, Please find my answer below. Thanks, Dmitry On 14/04/2014 14:12, Alexander Scherbatiy wrote: On 4/14/2014 10:59 AM, dmitry markov wrote: Hi Alexandr, Thank you for the review. According to the specification in ListSelectionModel: getAnchorSelectionIndex() and

Re: [9] Review request for 8032874: ArrayIndexOutOfBoundsException in JTable while clearing data in JTable

Scherbatiy wrote: On 4/11/2014 4:36 PM, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8032874 webrev: http://cr.openjdk.java.net/~dmarkov/8032874/jdk9/webrev.00/ Problem description: If JTable has Sorter and Filter and

[9] Review request for 8032874: ArrayIndexOutOfBoundsException in JTable while clearing data in JTable

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8032874 webrev: http://cr.openjdk.java.net/~dmarkov/8032874/jdk9/webrev.00/ Problem description: If JTable has Sorter and Filter and selected row is removed ArrayIndexOutOfBoundsException wi

Re: [9] Review request: 8028616 Htmleditorkit parser doesn't handle leading slash (/)

the handleText callback in the test and pass the test immediately if the check in the handleText is correct. Otherwise, the fix looks good for me. Thanks, Alexandr. On 1/10/2014 3:06 PM, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https

[9] Review request: 8028616 Htmleditorkit parser doesn't handle leading slash (/)

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8028616 webrev: http://cr.openjdk.java.net/~dmarkov/8028616/jdk9/webrev.00/ The method Parser.parseContent() should invoke legalElementContext(), if the parsed text is not wrapped by tags an

Re: [8] Review request for 8024395: Improve fix for line break calculations

You are right. I corrected the fix. The webrev is located at http://cr.openjdk.java.net/~dmarkov/8024395/jdk8/webrev.02/ Thanks, Dmitry On 10/09/2013 17:04, Alexander Scherbatiy wrote: On 9/10/2013 4:40 PM, dmitry markov wrote: Please find answer below. One more remark. The original

Re: [8] Review request for 8024395: Improve fix for line break calculations

Please find answer below. Thanks, Dmitry On 10/09/2013 13:49, Alexander Scherbatiy wrote: On 9/10/2013 12:44 PM, dmitry markov wrote: Hi Alexandr, Thanks for comments. I have updated the fix. New webrev is located at http://cr.openjdk.java.net/~dmarkov/8024395/jdk8/webrev.01/ Please find my

Re: [8] Review request for 8024395: Improve fix for line break calculations

Hi Alexandr, Thanks for comments. I have updated the fix. New webrev is located at http://cr.openjdk.java.net/~dmarkov/8024395/jdk8/webrev.01/ Please find my answer below. Thanks, Dmitry On 09/09/2013 16:59, Alexander Scherbatiy wrote: On 9/6/2013 6:38 PM, dmitry markov wrote: Hello, Could

[8] Review request for 8024395: Improve fix for line break calculations

Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024395 webrev: http://cr.openjdk.java.net/~dmarkov/8024395/jdk8/webrev.00/ The fix reverts the changes added for JDK-8014863 and override forwardUpdate() method for LogicalView class located at FlowVie

Re: [8] Review request for 8023474: First mousepress doesn't start editing in JTree

What else Swing components allow for editors? As far as I know, JTable does not have this problem. -- best regards, Anthony On 08/22/13 15:08, dmitry markov wrote: Hello, Could you review the fix, please? bug: http://bugs.sun.com/view_bug.do?bug_id=8023474 webrev: http://cr.openjdk.java.ne

[8] Review request for 8023474: First mousepress doesn't start editing in JTree

Hello, Could you review the fix, please? bug: http://bugs.sun.com/view_bug.do?bug_id=8023474 webrev: http://cr.openjdk.java.net/~dmarkov/8023474/webrev.00/ The method BasicTreeUI.startEditing() should find the first valid root for the editingComponent and call validateUnconditionally()

[8] Review request for 8016534: javax/swing/text/View/8014863/bug8014863.java failed

Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016534 webrev: http://cr.openjdk.java.net/~dmarkov/8016534/webrev.00/ The fix adds a calculation of the frame's width which is based on the font metrics for the current OS. Thanks, Dmitry

Re: jconsole exceptions

Hi Andreas, I built JDK 8 with the fix made under 8015853 and ran jconsole as you described below (connect to the process, etc.). I did not observe any ArrayIndexOutOfBoundsException. It seems to me, you have to replace the following line: index1 = getViewIndex(elem.getDocument().getLengt

Re: [8] Review request for 8015853: java.lang.ArrayIndexOutOfBoundsException when running SwingSet2 demo

HTML document 27 * @author Dmitry Markov 28 * @run main bug8015853 I suggest to remove this tags from the txt files. On 04.06.2013 17:52, dmitry markov wrote: Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015853 webrev: http

[8] Review request for 8015853: java.lang.ArrayIndexOutOfBoundsException when running SwingSet2 demo

Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015853 webrev: http://cr.openjdk.java.net/~vkarnauk/8015853/webrev.00/ The calculation of index1 variable in the View.forwardUpdate() method is not correct. The method getViewCount() should be used

Re: [7u] Review request for 8014863 Line break calculations in Java 7 are incorrect

:09 PM, dmitry markov wrote: Hello, Please review the back-port of the fix for 8014863 to jdk7u. I have changed the fix for jdk7u, corrected the calculation of the variable 'index1' to prevent an IndexOutOfBoundsException. New webrev is located at http://cr.openjdk.java.net/~alitvin

Re: [7u] Review request for 8014863 Line break calculations in Java 7 are incorrect

bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014863 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c8a0abc1fd2d technical review for jdk8: http://mail.openjdk.java.net/pipermail/swing-dev/2013-May/002709.html Thanks, Dmitry On 31/05/2013 12:53, dmitry markov wrote: Hell

[7u] Review request for 8014863 Line break calculations in Java 7 are incorrect

Hello, Please review the back-port of the fix for 8014863 to jdk7u. The changes are the same. bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014863 webrev for jdk7u-dev: http://cr.openjdk.java.net/~vkarnauk/8014863/jdk7/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt

Re: [8] Review request for 8014863 Line break calculations in Java 7 are incorrect.

Scherbatiy wrote: On 5/24/2013 11:46 AM, dmitry markov wrote: Hello, Could toy review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014863 webrev: http://cr.openjdk.java.net/~vkarnauk/8014863/webrev.00/ The fix removes break points caching from GlyphView. If some text

Re: [8] Review request for 8014863 Line break calculations in Java 7 are incorrect.

use the fixed title in your hg commit message. You shouldn't push a changeset with all-caps title in the repository. Thanks. -- best regards, Anthony On 05/24/2013 11:46 AM, dmitry markov wrote: Hello, Could toy review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=

[8] Review request for 8014863 LINE BREAK CALCULATIONS IN JAVA 7 ARE INCORRECT.

Hello, Could toy review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014863 webrev: http://cr.openjdk.java.net/~vkarnauk/8014863/webrev.00/ The fix removes break points caching from GlyphView. If some text is inserted/removed into/from the document contained several

Re: [8] Review request for 7011777 JDK 6 parses html text with script tags within comments differently from previous releases

On 4/19/2013 4:55 PM, Dmitry Markov wrote: Hello, could you please review the fix: bug: http://bugs.sun.com/view_bug.do?bug_id=7011777 webrev: http://cr.openjdk.java.net/~vkarnauk/7011777/jdk8/webrev.0/ The method parseScript() was modified, added functionality to determine the position of

[8] Review request for 7011777 JDK 6 parses html text with script tags within comments differently from previous releases

Hello, could you please review the fix: bug: http://bugs.sun.com/view_bug.do?bug_id=7011777 webrev: http://cr.openjdk.java.net/~vkarnauk/7011777/jdk8/webrev.0/ The method parseScript() was modified, added functionality to determine the position of the tag. If is located inside HTML comment,