Office.js 16.0.20619 silently removes eight documented Word.LineFormat properties

Eight properties vanished from Word.LineFormat

Office.js build 16.0.20619.15190 completed its rollout on 30 October 2026, and according to an analysis published on dev.to, it removed eight properties from Word.LineFormat, the object that governs shape and text box outlines in Word add-ins. The affected members are backgroundColor, foregroundColor, pattern, beginArrowheadLength, beginArrowheadStyle, beginArrowheadWidth, endArrowheadLength, endArrowheadStyle and endArrowheadWidth. Their siblings on the same class — dashStyle, weight, style, transparency, isVisible and insetPen — are untouched.

The dev.to post also notes that set() and toJSON() on the class changed in the same build, which points to the properties being deleted outright rather than relocated elsewhere.

The properties are still documented

All eight belong to the WordApiDesktop 1.3 requirement set. Per the dev.to report, Microsoft's requirement set page lists every one of them and labels WordApiDesktop 1.3 as production-ready on Word for Windows and Mac. The Word.LineFormat reference documentation still carried them too, with no deprecation note, as of the 30 October check.

The removal reached word-win32-16.01.js and word-mac-16.00.js on the production CDN, so desktop Word add-ins are exposed, not just the iOS and web hosts.

A removal, not a rename

The API surface diff came from reflection, so the author cross-checked the archived host files directly. In every Word host file of the new build, beginArrowheadLength is absent entirely, while dashStyle — a sibling property on the same class — is still present. The Word host file shrank by roughly 1.1 KB, whereas host files for other apps in the same build grew by about 1.8 KB. The conclusion: the code backing these properties was cut out of Word's Office.js files, not renamed or hidden from reflection.

What add-ins should expect

The author has not tested runtime behaviour in every Word version, so the following is likely behaviour to watch for rather than a confirmed result:

• Reading a removed property, such as beginArrowheadStyle on a loaded shape's line format, is expected to yield undefined instead of a value.
• Writing one is the dangerous case. Assigning to an Office.js property normally routes the change through a setter on the class. With the property gone, setting pattern on a line format simply creates a plain JavaScript property: no error is thrown, and nothing changes in the document.
• Calling set() with a removed key such as endArrowheadStyle goes through the modified set(), so it may ignore the key or throw, depending on the host.

To find affected code, the post suggests searching source and bundles for the begin/end Arrowhead property names and for lineFormat pattern or backgroundColor references. Where an add-in depends on these members, it recommends probing for the property on Word.LineFormat.prototype before use, instead of relying solely on requirement set checks.

A three-day staggered rollout

The new build first appeared on 26 October at 18:50 UTC on production, with the beta track showing up a minute later. For most of 27 October it sat at roughly 1% of sampled CDN edges before advancing again. It completed on OneCDN at 01:50 UTC on 30 October, with the legacy appsforoffice.microsoft.com endpoint finishing at 03:10 UTC; host files on both endpoints were byte-identical once done.

During those three days, the same add-in in the same Word installation could load either the old or the new build depending on which CDN edge answered, so shape-formatting bugs could come and go between reloads.

Not an isolated change

Word's API surface has moved for the second consecutive week, the post notes: build 16.0.20612 renamed the preview SensitivityLabelUpdateResult to SensitivityLabelUpdateStatus, after Excel and PowerPoint had seen the same rename the week before. The remaining changes in 16.0.20619 — an undocumented OfficeCore.FlightingService.getABConfigs and a new immersiveReader value in the undocumented OneNote.ServiceId — are described as internal and not affecting add-ins.

Why it matters

Requirement sets are supposed to be the contract between Microsoft and add-in developers: if documentation lists a property in a production requirement set, code can depend on it. This build broke that contract without an announcement or deprecation notice, and the failure mode is quiet — writes become no-ops instead of throwing, so bugs can ship inside documents unnoticed. The staggered CDN rollout removed any clean signal about when behaviour changed. Developers whose Word add-ins touch shape outlines should audit their code, replace requirement set checks with direct property probes where it matters, and keep an eye on the host files — a second undocumented API change in as many weeks suggests more may follow.