Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Smartclient Js files are not getting loaded in Edge broswer

    We are seeing issue in our automation environment, some of the js files of Smartclient are not loaded causing issue as shown in attachment.

    We have upgraded to Smartclient version SmartClient_v131p_2025-10-18_Enterprise. Issue is mostly observed in automation. It is not browser specific but more consistently seen in Edge v/s other browsers.

    There are some warning in the console.

    "7:33:25.814:WARN:Log:Patch for SmartClient 6.5 build included in this application. You are currently running SmartClient verion 'v13.1p_2025-10-18/Enterprise Development Only'. This patch is not compatible with this build and will have no effect. It should be removed from your application source."

    This is warning message but still wanted to check if it can cause some issue? Why does it log for 6.5 build patch?

    Also, some of the Smarclient js files (e.g. ISC_History.js) are loaded with parameter isc_version=10.0.js or isc_version=8.2.js? This does not look to be version number as there is .js added to it. Do change this to v13.1p_2025-10-18?
    Attached Files

    #2
    Some errors related to mime type
    Attached Files

    Comment


      #3
      Looks like your server is returning the wrong mime-type for .js files, and you have the browser configured to refuse to execute such scripts, so you are, in effect, not loading our software at all. Then, the call to isc.FileLoader in your application code fails, because you haven't loaded SmartClient.

      Whether you are trying to load .js files through our software (FileDownload servlet) or just directly via a Java or Apache servlet, you probably have a missing or corrupt mime.types file, so the wrong mime type is being sent in HTTP response headers, causing this problem.

      HTTP Code "0" is basically a "fake" HTTP code that means that the browser either refused to send a request at all, or got a response that wasn't valid HTTP. This may indicate that you are trying to load files across different host names or ports and have configured the browser to disallow this.

      None of this can possibly be related to the upgrade of SmartClient. You just broke the basic server environment somewhere in the midst of trying to upgrade.

      Comment


        #4
        Thanks for your response. Yes I understand that the js file corresponding to FileLoader (or couple of other files) are not loaded and that's why the referencing file give issue.
        This issue was intermittent and could not enable the Devtools. Now on one instance we are able reproduce it consistently and we could check error devtools. Error ERR_CERT_AUTHORITY_INVALID and ERR_SSL_PROTOCOL_ERROR are shown which is blocking the load of the js files. Surprisingly, we use the same host and port and same certs for other app which is not using smartclient, that loads properly. Does Smartclient 13.1 enforces full certification validation or any other strict rules, which were not present in 12.1.2024?
        Which could have cause these issue?

        Comment


          #5
          SmartClient has no functionality related to SSL or certificates. There is absolutely no SmartClient involvement in this error.

          Again, you are just trying to download ordinary .js files from a server and this error occurs before any code in SmartClient executes at all (server or client).

          This has nothing to do with SmartClient. You simply happened to break your server environment in an unrelated matter, at the same time you were installing the new version of SmartClient.

          Comment


            #6
            Thanks for the clarification. Agree that SSL errors are not related to Smarclient. While I was debugging the issue, I found certain discrepancies. Could you please look into and confirm this is nothing of concern. This may not be related to current error at all.

            1. Warn in Devtools
            "7:33:25.814:WARN:Log:Patch for SmartClient 6.5 build included in this application. You are currently running SmartClient verion 'v13.1p_2025-10-18/Enterprise Development Only'. This patch is not compatible with this build and will have no effect. It should be removed from your application source."

            2. Error in Devtools
            The image showing wrong mimetyes for ISC_RichTextEditor.js and ISC_calendar.js are not loaded by our code. They are loaded through some smartclient js [probably ISC_Core.js]
            The new file added in 13.1 ISC_Reify.js [line number 730 of version SmartClient_v131p_2025-10-18_Enterprise] having content-type="text/html. ISC_core.js is loaded by our code. It is showing mime type issue to only these 2 files. You can see the image attached previously.

            3. Error in smartclient logs.
            ERROR BaseTag - LoadSystemSchemaTag.getFrameworkDataSources(): the following path configured for framework.datasources
            is not a directory: {our application webapp path}/isomorphic/../tools/datasources

            There is no tools directory in isomorphic folder or top level folder. Out application datasources are in shared/ds and they are loaded properly.

            Please let us know which of these are issues or not

            Comment


              #7
              1. You should read the warning message - it says what's going on and what to do about it

              2. Our files cannot load themselves, so yes, you are loading those files. Also, again, mime.types and the returned mime type are controlled by the web server and not by the web browser - please see our previous response

              Also, why are you trying to load ISC_Reify.js? You should probably look at the docs for Reify so you understand what that is. There would be no reason for a typical application to try to load that resource.

              3. Multiple things here:

              a. are you trying to use the LoadSystemSchemaTag JSP tag? Why? That's for the Dashboards & Tools framework, which is a framework building web applications that can build other web applications - it would generally not be in a normal web application

              b. your project.datasources setting, controlled via server.properties, points to a path that does not exist on disk. However, with that path - tools/datasources/ - it again looks as though someone was trying to use the Dashboards & Tools framework, which doesn't make much sense. That, or people were just randomly copying and pasting things without reading the docs or installation instructions.

              Comment


                #8
                2. Yes obviously, Smartclient ISC_core.js is loaded by our code but we are not explicitly loading ISC_Reify.js in our code. Which I mentioned earlier also in my second point.
                ISC_Reify.js is new file added and we came to know about it only when we scanned Smartclient code for mime type error. Only 2 specific js file are giving mime type error and they are referenced in this ISC_Reify.js. Did you check line number 730 of this file?

                This is NOT causing any issue in our code otherwise the application wouldn't work as the mime type error is not loading these files.

                3. LoadSystemSchemaTag is already part of the webapp that we have and is there since 8.2 version, I guess. Only the log at 'Error' is new between previous version and new version. Also, it looks to be logged at wrong level [Error instead of Info]. Other than that there is no issue. System datasource and application datasources are in the same place as before and they are loaded correctly.

                I have given all this information in previous post as well. It appears as if you pick a keyword and answer instead of reading the whole thing.

                Good news is we have identified and fixed the original issue which was JDK problem. Seeking clarification on these points so that we don't have any inconsistencies in our integration for current and future upgrades

                Thank you for all your help

                Comment


                  #9
                  Are you saying you solved the mime.types issue and you think it was to do with the JDK? That doesn't actually make any sense, and is almost certainly not what solved the problem - more likely, you also reinstalled something else at the same time. This is important for you to understand since if the problem comes back, and you think it's a JDK issue, you'll likely go in circles!

                  Beyond that, we can only be more emphatic about what we said before, which was already correct and which you need to understand:

                  1) you definitely should not be loading ISC_Reify.js and it is definitely not being auto-loaded by our software

                  Reify is a low-code platform, kind of analogous to an IDE. You're loading something like an IDE into your app. That's nonsensical.

                  ISC_Reify.js is never auto-loaded by our software because that's nonsensical.

                  Furthermore, it is impossible for your application to need Reify because Reify didn't exist when your application was created.

                  What has likely happened is that many years ago, someone added some code to your app that just tries to load anything named ISC_*.js, which is a really weird hack, and you should find that hack and get rid of it.


                  2) you also almost certainly should not be using the LoadSystemSchemaTag

                  What this tag does is load hundreds of Component Schema, so that you can do things like easily create a PropertySheet for editing properties of a ListGrid. That doesn't make any sense in a normal app, and it sounds like you broke it anyway.

                  Similar to whatever is loading ISC_Reify.js, it seems like way back when your app was created, someone just skipped reading the docs and took a "load absolutely everything" approach, possibly by copying the .jsp for what used to be called Visual Builder (now Reify).

                  Beyond being a hack and a waste of resources, you shouldn't be loading these files because you aren't even licensed to do that - you're basically accidentally shipping chunks of our SDK in your product.

                  --

                  And just as a final note, the log is at the correct level. The LoadSystemSchemaTag is completely broken because your .properties config is wrong, and if you were actually using that functionality, this would totally break your application, and that's what ERROR-level logs are for.

                  Comment

                  Working...
                  X