Fix worksheet dimension after cell writes#2295
Open
rootsec1 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This change keeps worksheet
<dimension>metadata in sync when cell writes expand the used range.Today the cell-writing paths grow
SheetData, but they do not updatews.Dimension. As a result, the serialized worksheet can keep an old<dimension ref="...">even after writing cells outside that range.A simple repro before this change:
The saved worksheet still reports
A1as its dimension instead ofC5.The same problem shows up for existing workbooks too. If a worksheet starts with
B2:E61and a write lands atG64, the saved worksheet still reportsB2:E61.Some readers and validators trust worksheet dimensions as the authoritative used range. When that metadata stays stale, the sheet can be interpreted as truncated, and stricter consumers may treat the workbook as inconsistent.
Root Cause
All of the common cell write paths eventually call
prepareSheetXML(col, row)so that the target row and cell nodes exist before writing.prepareSheetXMLcurrently:But it does not expand
ws.Dimension.That means the actual worksheet data grows while the dimension element remains frozen at its previous value.
Fix
This patch adds
expandSheetDimension(col, row)and calls it fromprepareSheetXML.Behavior:
col < 1orrow < 1)A1starting bounds when the worksheet already has a non-default used rangeThis keeps dimension updates centralized in the same helper that already owns worksheet growth, so all cell-writing APIs benefit without duplicating logic.
Tests
The change adds coverage for the two cases above:
C5in a new workbook updates the worksheet dimension toC5G64to a sheet whose dimension isB2:E61updates it toB2:G64It also updates
TestWorksheetWriterto reflect that a worksheet modified throughSetCellValuenow serializes with a maintained<dimension>element.Validation
I validated this in three ways:
go test ./....xlsxfiles where writes outside the prior used range previously left stale dimensions in the saved XMLCompatibility Notes
This does not change how cell values are written. It only keeps the worksheet metadata aligned with the cells that were actually prepared and written.
For new workbooks, the resulting dimension is the exact used range (
C5, notA1:C5) which matches the worksheet's real populated bounds.