Coherent JS, can it be more robust?

Dear Asobo, Maybe you guys are not aware, maybe you are… but I thought I
better post this here asking for an improvement to the entire Coherent .JS
ecosystem. Until today and since release, we all 3rd party developers keep
facing support tickets due to HTML/JS controls, panels, gauges and displays
failing all the sudden, and the reason in all cases is due to a conflict with
another 3rd party product which contains .JS errors on their code, causing not
only official Asobo / Working Title Garmin’s, panels, html .js gauges, custom
HTML/JS we controls such as tablets, and in fact anything using HTML/JS to
stops executing and working at that stage… The only solution we can offer to
customers is to instruct them to clear their community folder and re-test and
if this fails, they have to uninstall all their Market Place official content
and re-test… once they confirm our units are working again, they have to
install 1 add-on at a time until they find the culprit with the problem. You
guys can appreciate how time consuming that is for end users, they not only
get supper frustrated, with the majority landing at our door asking for
support thinking we have done something wrong with our products, but also a
good number of customers just think in many cases our products are faulty and
instead of coming to ask for help, they just leave bad reviews and ratings via
MP, or they proceed to post negative reviews about our products not realising
the cause of the issue is an unknown 3rd party not related to the product in
question. We need some change on this, why is it that 1 external add-on not
related to our products can cause such havoc? ideally, it should only break
the simulation or behaviour of that add-on only instead of preventing all add-
on’s dependant on Coherent / .JS from operating properly surely. This is
causing lots of troubles recently and as the number of add-on’s increases over
time, is just getting worse, personally get asked this now weekly by a minimum
of 5 users per week having issues with Garmin units not working, or the
tablet’s implemented in our airplanes misbehaving to then they find some
freeware or external tool was the cause. Would it be possible to implement
some or a combination of the solutions below:

  • Not load add-on’s which have faulty .JS code, allowing all the rest of coherent to operate correctly?
  • Report easily to end users a particular add-on has .JS errors? so they are aware which is the add-on with problems on their system?
  • Make Coherent more robust against .JS errors, so if an add-on has some .JS mistakes, it would not cause add-on’s with perfectly fine HTML / JS code to work without interruptions?

Happy also to hear suggestion regarding how to reduce this issue, but I think
this is something that really needs attention, it is getting out of control.
Kind Regards, Raul

Ya would be nice if ASOBO gave us a debug mode where the file that errors out
is reported, and maybe the line number. Then ask the user to turn on debug
(P3D Content error reporting!!!) and see the error. - at least a start.
Perhaps a mode where the user can enable/disable the community folder addons
(and sim default/premium addons). A list of all the addon’s and then a
checkbox to disable them, restart the sim and enable each addon, restart sim
to do the addon checking. Rework the content manager to add this checkbox. I
mean there is tons of wasted space in that list of addons. Then the user has
the power to find the issue.

@DA40CGDFQ problem is, it is starting to happen
even with some official Market Place content… so we really need means to make
this more robust… having the entire ecosystem failing due to 1 single add-on
is really bad… R.

This sounds a serious issue but I’ve written tens of thousands of lines of
MSFS html/js code and I’m still unclear what your failure scenario is. Are you
talking about 4th-parties making mods to your add-ons? Specifically it sounds
like you mean some 4th-party code is making JS calls that have ‘faults’ ? Can
you be a bit more specific, like what are they actually calling or what is
your gauge(?) doing that then fails? Are you using some to some
fragile bit of MSFS, like the flightplan/nav stuff, and another completely
independent addon is breaking that? Or is this more to do with add-ons camping
on the ‘official’ VFS and providing broken substitutes for html/js assets you
are importing?

Nope, no mods. If a 3rd party add-on (non related to your code or product) has
JavaScript failures that affects coherent, most of the MSFS java-script code
will stops executing inside MSFS… not sure how more clear I can put it.
Another failure I have seen is developers adding .JS files with the same name
as base navigation files using a non compatible file direcotry structure…
causing the entire coherent JS system to break. This is not an issue isolated
to my add-on only. Read public forums, every single developer is suffering
from this… we have seem many times Garmin units remaining black on multiple
airplanes (even default ones) because users installed a freeware that breaks
key base .JS files. My units are using working title framework, other units
the Asobo framework, and my tabler (an EFB) the standard Asobo HTML / JS
coherent framework… all are affected by this issue… just google Working
Title G1000 not working / black… most forums results will advise to clear the
community folder from any add-on… exactly as I explained on my post. Here is
a particular example… another support ticket raised:

After advising to clear his
community folder and test each add-on… took him hours and hours… Result:
We really need means to stop
this madness… why a faulty 3rd party add-on should affect the running on my
HTML/JS code? it is just fundamentally wrong… R.

My JS life got significantly easier when I discovered
A very
convenient , and easy to use , online JS Validator It would get even easier,
if the Dev Console gave more specific error message, identifing what file, and
even line, had caused the error. (ie a Verbose option). **** Currently, way to
many of the error messages are of teh form:- " Hey, we have found an error,
but we are not going to tell you what or where – Go figure that out yourself
**It’s just a BIG TEASE I **

Yea… As an example, I’m able to override the coherent.js file from a
package. For obvious reasons, I feel like it’s one of those files that
shouldn’t be overridable outside of the dev environment.

it’s the “javascript errors” part that lacks clarity, that’s about on par with
“not working”. Most of your post is describing the pain from the issue, rather
than the cause, and I absolutely understand how painful it is to have some
other mod break your add-on. Is your primary issue actually with the VFS which
allows mod developers to substitute their code for core parts of the Asobo
system that you have dependencies on in your html/js gauge?

This doesn’t seem to be much to do with Coherent but rather the VFS and the
ability it gives to replace/override files from other packages (one of the
most powerful features which has made many mods possible when used carefully
IMO). This is a more general problem rather than one confined to HTML gauges.
Coherent doesn’t see the files from individual packages AFAIK; it is
abstracted from the underlying packages by the VFS, and all three of your
bullet points are not really compatible with this. What do you suggest in that
context? Perhaps some clearer documentation for those that don’t understand
what they’re doing when they override files like this; also suggesting that
they should only touch files in their own subdirectory in the VFS? A blacklist
for known “bad” packages (who is the arbiter of that?)? Perhaps it is possible
for the debugger to ask the VFS which exact package a particular file
originates from and make that information available in the debugger UI to
assist with debugging issues when they do occur. runshotgun’s suggestion to
dissallow overiding coherent.js makes a lot of sense to me, but beyond those
absolute basics that you can’t avoid depending on I don’t think it makes sense
to extend this any further and doing so would necessarily get very murky and
limit the possibilities for “legitimate” mods. There is a strategy to make
your own add-ons more robust: don’t depend on code outside your subdirectories
any more than strictly necessary. This has worked quite well for us at
FlyByWire (and we did experience pain in the past prior to that), but I
understand this is more difficult if you’re re-using/extending default
instruments provided by the sim. Beyond that you can contact your fellow devs
directly when you notice they’ve made a mistake and touched a file in the VFS
that they really shouldn’t have. Education is the key when it comes to shared

I think it would be possible to have zero Asobo files overridden - I’ve done a
fair amount of work creating custom Nav panels and right at the beginning it
seemed easiest to simply override some file deep in the Asobo nav html/js tree
so you still get the same basic instrument but the behaviour is tweaked, but
quite quickly I restructured my code so it became a separate instrument with
some dependencies on the Asobo code (e.g. the Bing Map). It seems obvious that
a bunch of devs are taking the easier approach and now probably will argue it
is essential they do that, but I don’t think that is actually correct.