On Mon, 15 Jul 2024 09:53:59 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> Marked as reviewed by prr (Reviewer). > > @prrace Need your re-review please..I guess skara is modified to ask for > reapproval after PR change (added AIOBE check) Hey @prsadhuk, we've found a regression in the JTable. After investigating I found out that it was introduced with the fix that you've provided for this issue. Your fix sets the "resizingColumn" of the JTableHeader. That field is documented as "the column being resized. <code>null</code> if not resizing.", which means that is is the column that is resized _right now_, e.g. by the user using the mouse. Besides your fix, the method `JTableHeader.setResizingColumn` is only called by `BasicHeaderTableUI` which sets the column actively being resized in a mousePressed event, and clears the value (back to `null`) in the corresponding mouseReleased event. As a result, your fix does not really work. After the user resized any column using the mouse, the `resizingColunm` is `null` again, so the previous behavior is back (all columns are resized, when you resize the dialog). And whats worse: It seems like it introduces a regression, where the `TableCellEditor.cancelCellEditing` is called immediately after the editor was added to the table, making it impossible to edit the cell. I need to investigate further, but is is related to the "resizingColumnn", that isn't `null` when the editor should show up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20107#issuecomment-4788138981
