__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__
__Expected Behavior__
The modeler shows the content of the clicked model. (I validated this behaviour with version 4.3.0)
__Environment__
@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:
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.
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
const chromiumSwitches = ["--allow-file-access-from-files"];
function isChromiumSwitch(argument) {
return chromiumSwitches.includes(argument);
}
console.log(
mri(args.filter((argument) => !isChromiumSwitch(argument)).slice(1))
);
"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.
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.