Bug 170392 - reading a writer document the document-name shown as fieldname changes to pathname only 26.2.0.1
Summary: reading a writer document the document-name shown as fieldname changes to pat...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
26.8.0.0 alpha0+ master
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Andreas Heinisch
URL:
Whiteboard: target:26.8.0 target:26.2.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2026-01-19 22:18 UTC by gerdl
Modified: 2026-02-02 07:03 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
read in the document, suddenly pathname is in foot line. Change to documentname, save it an read in again. (14.88 KB, application/vnd.oasis.opendocument.text)
2026-01-19 22:18 UTC, gerdl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gerdl 2026-01-19 22:18:16 UTC
Created attachment 205090 [details]
read in the document, suddenly pathname is in foot line. Change to documentname, save it an read in again.

see the writer document.
Comment 1 Takenori Yasuda 2026-01-20 04:26:52 UTC
I have confirmed the behaviour.

After saving the document and reloading it, I checked the field via
Edit Fields -> Format, and found that the formatting changed as follows:

- File name -> File name without extension
- File name without extension -> Path
- Path -> Path/File name
- Path/File name -> File name

I also verified this behaviour using Japanese, Simplified Chinese,
Traditional Chinese, and UK English UIs, and the order was the same in all cases.


Version: 26.2.0.1 (X86_64)
Build ID: 620(Build:1)
CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded Jumbo
Comment 2 raal 2026-01-21 16:13:00 UTC
I can confirm with Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 8fb5be18f8febe88f7d0b72e4b30efd41891feb7
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Insert Filename without extension after reload change to path. This is read bug - when I open the file in LO 7.3.7, the field is correct.
Comment 3 raal 2026-01-21 16:18:12 UTC
This seems to have begun at the below commit in bibisect repository/OS linux-64-26.8.
Adding Cc: to Andreas Heinisch ; Could you possibly take a look at this one?
Thanks
 e88f80c7eb9cc0d0774192bb894e52e39d4d365f is the first bad commit
commit e88f80c7eb9cc0d0774192bb894e52e39d4d365f
Author: Jenkins Build User <tdf@maggie.tdf>
Date:   Fri Dec 19 02:00:39 2025 +0100

    source c44271e0f026674be9d89a33e5c37adf4f0a3568

194935: tdf#155780 - Provide correct value for FileName field | https://gerrit.libreoffice.org/c/core/+/194935
Comment 4 Andreas Heinisch 2026-01-22 06:16:40 UTC
So the settings coming from a macro and the settings coming directly from the document itself contradict each other :(

Details in Bug 155780 - FileName Field displays wrong content if IsFixed is True when inserted by Macro
Comment 5 Andreas Heinisch 2026-01-22 07:32:49 UTC
So the settings:
namespace com { namespace sun { namespace star { namespace text { namespace FilenameDisplayFormat {

static const ::sal_Int16 FULL = (sal_Int16)0;
static const ::sal_Int16 NAME = (sal_Int16)2;
static const ::sal_Int16 NAME_AND_EXT = (sal_Int16)3;
static const ::sal_Int16 PATH = (sal_Int16)1;

} } } } }

AND 

enum class SwFileNameFormat {
    // most of the constants are a regular enum
    Name,
    PathName,
    Path,
    NameNoExt,
    UIName,
    UIRange,
    End, // marker value, used for asserts
    // except for this, which is a flag
    Fixed = 0x8000
};

contradict each other.

@Mike
Can we safely adjust the order of the SwFileNameFormat enum class to match the actual constant or is it better to remove the mapping in SwFileNameField::QueryValue and SwFileNameField::PutValue?
Comment 6 Mike Kaganski 2026-01-22 08:36:17 UTC
(In reply to Andreas Heinisch from comment #5)

Given the set of elements of SwFileNameFormat, I do not see a reliable way to map between it and com.sun.star.textFilenameDisplayFormat constants. If removing the mapping in SwFileNameField::QueryValue and SwFileNameField::PutValue works, I'd do that (but a change in gerrit would be easier to discuss).
Comment 7 Commit Notification 2026-01-31 11:28:51 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f7588e928a6de891e1fbf3b4d591e7d69347813a

tdf#170392 - Align file name format constants with translate constants

It will be available in 26.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Andreas Heinisch 2026-01-31 11:30:29 UTC
Still needs an automated test.
Comment 9 Commit Notification 2026-02-01 03:25:20 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "libreoffice-26-2":

https://git.libreoffice.org/core/commit/07b9250b8870d720d9d5a58af987597d18eac25f

tdf#170392 - Align file name format constants with translate constants

It will be available in 26.2.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2026-02-02 06:56:36 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4c7a6870fca388288695d88622c517b30293e034

tdf#170392 - Align file name format constants with translate constants

It will be available in 26.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.