Custom Input Blocked content BUG after update (Bugreport)

after Updating “UiPath.System.Activities” with a version newer than 18.4.2, we will see blocked content message prompt, which Force user to Allow the content every time, also there is a more visual problem like, the disappearance of Ui icon of the custom input window.
I tried to turn off ActiveX control in the “internet option” setting of IE but looks like the problem is somewhere else.
As soon as I downgrading to 18.4.2 the problem will solve.
I believe its related to window size fixes in newer versions. (or maybe I’m wrong)

To reproduce this error just use “official custom input example” for receiving HTML output results.

P.S
this custom input activity is not mature as the UiPath system is. its like a small and clumsy stitch to a big wound.
it was a real bottleneck for my entire project since the beginning.

Hi @ali_fath

Could you see with our support if there is a workaround to your issue?

Otherwise, could you post a screenshot of the issue?

Of course.
this happen on 19.3.0

this happen on 18.4.2

Hi @ali_fath

Any chance it is resolved with the per-release beta package?

If not, could you share the sample form HTML or even the sample project that causes you this headache? It would speed up the process of debugging the issue :slight_smile:

1 Like

First of all I should thank you for your attention.
The html file is the exact sample provided by uipath documents.
It tested in new and clean and empty project.
The only thing I didn’t checked is installing uipath on other desktop. To isolate windows environment

Thank you for pointing me again in the right direction (I missed your sentence from the first post).

I’ve tested it myself and then added it to our bug tracker.

1 Like

So, I assume it as a Removed Bug, hope to see a Fix soon.
otherwise, please have a look at this topic too: Custom Input Appearance

1 Like

Hi @ali_fath

There is a workaround found. The warning will be suppressed if you add this at the beginning of your HTML file:
<!-- saved from url=(0014)about:internet -->

The problem seems to be the this child process runs with different permissions. The thing is, this is the correct behavior. A warning SHOULD be displayed when loading dubious HTML files from disk.

If instead of a file a legitimate HTTP/S URL is used, this warning will not be shown.

Very late EDIT with som more options:
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/> - this is forcing to use Edge engine (allows for HTML5 features)
<!-- saved from url=(0016)http://localhost --> - this enables automatic sandbox mode which additionally skips the security

13 Likes

This is perfect. Thank you.

2 Likes

This Code solved the Problem. Thankyou :smile::smile:

1 Like

SImply amazing! Works like a charm. Thank you very much!

1 Like

this should be noted as solution ! Thank you

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.