Camunda-modeler: Open file from Explorer on Windows does not work if modeler already started

Created on 14 May 2021  路  12Comments  路  Source: camunda/camunda-modeler

__Describe the Bug__

If you are using Windows and try to open a BPMN-Model from the Explorer, it only works if the modeler is closed. If the modeler is open it will pop to the top and blink for a moment, but will not show the model.

__Steps to Reproduce__

  1. Install Modeler 4.8.1
  2. Execute supportregister_fileassoc.bat
  3. Double click a bpmn-file to check if it is openend.
  4. Close the file but not the modeler
  5. Double click the bpmn-file (or any other)

__Expected Behavior__

The modeler shows the content of the clicked model. (I validated this behaviour with version 4.3.0)

__Environment__

  • OS: Windows 10
  • Camunda Modeler Version: 4.8.1
  • Installed plug-ins: -
bug

Most helpful comment

I haven't seen any other flags that are not our own. Another alternative would be to sort the list of arguments so all flags are moved to the end of the list. Chromium switches are always added at the front.

All 12 comments

@philippfromme Could you have a look and see if you can reproduce it with v4.8.1?

I can reproduce this. Double-clicking the BPMN file focuses the Camunda Modeler but doesn't open the file.

I can reproduce it on MacOS 10.15.7

I've checked again and the bug appears only under certain conditions:

  1. Open Camunda Modeler 4.8
  2. From the _Open with_ menu, select a Camunda Modeler distro which is not the one which is open. In my case, it can be the nightly.

https://user-images.githubusercontent.com/28307541/118949909-f9da6700-b959-11eb-8111-89d0a323f360.mov

Need to verify if this is the same case on Windows.

@philippfromme Specifically https://github.com/camunda/camunda-modeler/blob/develop/app/lib/index.js#L103 could be the place to look into to debug further.

Analysis

The issue is caused by a --allow-file-access-from-files argument that is part of the arguments. This flag is a Chromium switch that allows file:// URIs to read other file:// URIs. I'm not sure why this flag is present.

The list of arguments:

[
  "C:\\camunda\\camunda-modeler\\dist\\win-ia32-unpacked\\Camunda Modeler.exe",
  "--allow-file-access-from-files",
  "C:\\Users\\John\\Desktop\\foo.bpmn"
]

The presence of the --allow-file-access-from-files argument leads to an unexpected result when parsing the arguments using mri. The result:

{
  "_": [],
  "allow-file-access-from-files": "C:\Users\John\Desktop\foo.bpmn"
}

The file that's supposed to be opened ends up as the value of the --allow-file-access-from-files argument.

This CodeSandbox reproduces the issue: https://codesandbox.io/s/camunda-modeler2268-hrm58?file=/src/index.js:37-195

Solution Approaches

  1. Ignore arguments that are known Chromium switches
const chromiumSwitches = ["--allow-file-access-from-files"];

function isChromiumSwitch(argument) {
  return chromiumSwitches.includes(argument);
}

console.log(
  mri(args.filter((argument) => !isChromiumSwitch(argument)).slice(1))
);
  1. Make files named argument
"Camunda Modeler.exe" --files foo.bpmn

My preferred solution would be 1. since it wouldn't introduce a breaking change. It would also be interesting to understand why the --allow-file-access-from-files argument is present in the first place.

@barmac @marstamm @MaxTru @nikku @pinussilvestrus What are your thoughts on this?

Solution 1 sounds reasonable to me 馃憤 Do you know of any other switches that may appear?

I haven't seen any other flags that are not our own. Another alternative would be to sort the list of arguments so all flags are moved to the end of the list. Chromium switches are always added at the front.

Nice investigation 馃憤 How likely would it be that we have similar problems with upcoming upgrades, e.g. Chromium adds more flags on top we don't know about?

Another alternative would be to sort the list of arguments so all flags are moved to the end of the list

Maybe that's a better solution, so we ensure our expected arguments structure

How likely would it be that we have similar problems with upcoming upgrades, e.g. Chromium adds more flags on top we don't know about?

Since I don't know their roadmap it's hard to say.

I'll go for the proposed solution of sorting the list of arguments.

I ended up going for the first proposed solution:

Ignore arguments that are known Chromium switches

Sorting the list of arguments proved to be to error-prone.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mschoe picture mschoe  路  4Comments

StephenOTT picture StephenOTT  路  5Comments

pinussilvestrus picture pinussilvestrus  路  5Comments

NPDeehan picture NPDeehan  路  5Comments

philippfromme picture philippfromme  路  4Comments