Skip to content

8387267: Editor for the last column in JTable is hard to activate after AUTO_RESIZE_LAST_COLUMN was configured#31704

Open
prsadhuk wants to merge 1 commit into
openjdk:masterfrom
prsadhuk:JDK-8387267
Open

8387267: Editor for the last column in JTable is hard to activate after AUTO_RESIZE_LAST_COLUMN was configured#31704
prsadhuk wants to merge 1 commit into
openjdk:masterfrom
prsadhuk:JDK-8387267

Conversation

@prsadhuk

@prsadhuk prsadhuk commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

When JTable.setAutoResizeMode is called with JTable.AUTO_RESIZE_LAST_COLUMN,
it is supposed to adjust the delta width to the last column only when table itself changes width
but before JDK-8234071 fix, AUTO_RESIZE_LAST_COLUMN, was behaving exactly as if user specified AUTO_RESIZE_ALL_COLUMNS
so width of all columns of table gets adjusted.

JDK-8234071 fixes this issue by setting "resizingColumn" to last column when AUTO_RESIZE_LAST_COLUMN is specified so that only last column gets resized
but the fix was wrongly instructing the JTable that the user is currently resizing the last column with the mouse
so JTable started believing a header resize was active even during normal layout, window resizing or cell editing
thus it caused side-effects like initial preferred column widths was ignored as seen in JDK-8375573
and real mouse resizing of another column was conflicting with the “last column is resizing” state as mousePressed/Released uses "resizingColumn" to ensure a certain column is getting resized
and editing is disturbed because JTable thought column resizing/layout activity is happening as seen in this particular issue.

The issue is that a left click on an editable cell starts editing and then selects the cell.
Selecting the cell scrolls it into view, which revalidates the table and runs doLayout().
Because the header now permanently reports a resizing column, the layout pass adjusts a column's preferred width
and fires TableColumnModelListener.columnMarginChanged(). JTable.columnMarginChanged() stops the active cell editor.

Also, after a user drags the first column header divider, resizingColumn is reset to null in BasicTableHeaderUI.mouseReleased and
JTable then syncs preferred widths from actual widths using setWidthsFromPreferredWidths(true).
Later, when the dialog is resized, setWidthsFromPreferredWidths(false) runs again and all columns are recalculated so AUTO_RESIZE_LAST_COLUMN was not honoured

Fix is made to handle AUTO_RESIZE_LAST_COLUMN in the layout code
so the width distribution logic ensures that
During normal window/dialog resize: change is made only to the last column.
During initial layout: honors the user’s preferred widths, then let the last column absorbs extra space.
During real header drag: allows the dragged column to resize, and uses the last column to compensate.
and it doesn't hamper editing of any cell in last column when double-clicked



Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

  • JDK-8387267: Editor for the last column in JTable is hard to activate after AUTO_RESIZE_LAST_COLUMN was configured (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/31704/head:pull/31704
$ git checkout pull/31704

Update a local copy of the PR:
$ git checkout pull/31704
$ git pull https://git.openjdk.org/jdk.git pull/31704/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31704

View PR using the GUI difftool:
$ git pr show -t 31704

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/31704.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper

bridgekeeper Bot commented Jun 29, 2026

Copy link
Copy Markdown

👋 Welcome back psadhukhan! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk

openjdk Bot commented Jun 29, 2026

Copy link
Copy Markdown

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk Bot added the client client-libs-dev@openjdk.org label Jun 29, 2026
@openjdk

openjdk Bot commented Jun 29, 2026

Copy link
Copy Markdown

@prsadhuk The following label will be automatically applied to this pull request:

  • client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk

openjdk Bot commented Jun 29, 2026

Copy link
Copy Markdown

The total number of required reviews for this PR has been set to 2 based on the presence of this label: client. This can be overridden with the /reviewers command.

@openjdk openjdk Bot added the rfr Pull request is ready for review label Jun 29, 2026
@mlbridge

mlbridge Bot commented Jun 29, 2026

Copy link
Copy Markdown

Webrevs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

client client-libs-dev@openjdk.org rfr Pull request is ready for review

Development

Successfully merging this pull request may close these issues.

1 participant