I am not sure this could be considered a bug. When you start LibreOffice *in any mode*, it uses *some* user profile. Unless you explicitly specify some specific user profile, it uses what is defined by default (in its install location's program/bootstrap.ini); and that is the same profile that is used by default by interactive and headless mode.

When LibreOffice starts and uses a profile, it tries to detect if there is already an instance that uses *that profile*. If there is, the new instance of LibreOffice *does not* run itself, but passes its command line to the existing instance, so that that one would process and return the result (no two instances of LibreOffice should ever access a single user profile at the same time).

This results in normal GUI instance trying to handle your files in your described situation. The proper way to handle this is to explicitly use some temporary (or simply different) profile for your headless commands - see -env:VAR under command line parameters in Help [1].

Maybe Stephan may correct me if I am mistaken?

[1] https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html

Adding "-env:UserInstallation=file:///tmp/test" works fine, thank you!

This is the full command line statement: `libreoffice --headless --norestore --language=de -env:UserInstallation=file:///tmp/test --convert-to png Report.xlsm`

A side effect is the longer run time: from 1 second without to 5 seconds with the additional parameter. This is OK in my case and I just write it here for the case that someone else runs into the same situation.

I understand your explanation (from a technical point of view).
From the CLI-user view I still think that "headless" should always mean "headless".
Maybe a hint in the help message would be nice.

(In reply to liboffbugz from comment #2)
> A side effect is the longer run time: from 1 second without to 5 seconds
> with the additional parameter. This is OK in my case and I just write it
> here for the case that someone else runs into the same situation.

This is expected that *creating a new profile* takes long. But note the "(or simply different)" in comment 1, where I meant that you created (at the first run) and then reused a dedicated profile, which would not need to be re-created each time.

> I understand your explanation (from a technical point of view).
> From the CLI-user view I still think that "headless" should always mean
> "headless".
> Maybe a hint in the help message would be nice.

Something should be improved, yes. A message stating that it is being processed something from a secondary headless instance; also documentation about command line; and maybe even the handling of the headless option when passing to a non-headless instance (e.g., we could block such a scenario, and return "Error: trying to execute headless operations in a non-headless instance; aborting" to the stderr where headless operation was attempted)...

(In reply to Mike Kaganski from comment #1)
> Maybe Stephan may correct me if I am mistaken?

Your explanation is completely correct.

(In reply to liboffbugz from comment #2)
> A side effect is the longer run time: from 1 second without to 5 seconds
> with the additional parameter. This is OK in my case and I just write it
> here for the case that someone else runs into the same situation.

The longer run time should only happen for the first time you use a fresh --env:UserInstallation=file:///... argument (it populates that user installation and restarts LO).  It should be quick if you reuse any existing user installation.

(In reply to Mike Kaganski from comment #3)
> and maybe even the handling of the headless option when
> passing to a non-headless instance (e.g., we could block such a scenario,
> and return "Error: trying to execute headless operations in a non-headless
> instance; aborting" to the stderr where headless operation was attempted)...

or maybe detecting such an attempt, copy the profile to a temporary profile, use it for this headless instance, and remove it. But that could be dangerous - to copy a profile that is being in use; and also potentially much longer than creation of a new profile (an existing profile may have installed extensions, etc.). OTOH if a user runs a command with default profile, it would be unexpected to perform the command with a clear profile without user modifications that could affect the result (say, PDF export options).

So I suppose that interrupting the operation could be something to consider (how much breakage would it be for users?), but not "copy profile" approach.

Possible outcomes here, Mike please mark:
1. Notabug
2.New,for message from Comment 3
3. New for Documentation - but I'd rather add conclusion to bug 133932.

I find this rare and of lowest priority.

(In reply to Timur from comment #6)

Notabug + amendment to 133932 :-) I'd not add texts to messages (that would require to pass the information about the secondary process command line details very deeply to unexpected parts of the code), but just block such attempts at all (then it would be easy to provide relevant message in console), but I don't dare to do that because of fear that many users would complain that their normal headless operations stop working.

Stephan: maybe we still could put something to the context stack of the handling component to tell that this is a headless component, even in the GUI instance? To let the interaction get that information from the context, and behave as if it were headless? In the end, that looks like proper use of the context stack. We have some examples like use of comphelper::SetFlagContext, e.g. to block interaction for Java missing cases, and context-dependent Basic error handling?