Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events

Rename a JavaScript Window


Level 2

Does anyone know of a way to 'rename' a JavaScript window to something other than 'JavaScript' window ?

We have a forms that pop us a window with possible user names from an LDAP query. The clients were confused by the term "JavaScript Window".

10 Replies


Level 10


I am afraid you can't. I believe it is intended to "warn" the user that the dialog was scripted by the form developer and is not a standard Adobe dialog.

I agree that "JavaScript Window" is not very intuitive and can confuse users. However if you use messageBox (see help) you can add a title to the dialog, which will appear after the JavaScript Window string.

Good luck,



Level 10


you can remove the dialogs warning prefix only if the dialog is executed from a trusted enviroment.


This could be a folder level script for example...

var MyDialog = app.trustedFunction(function(doc, Msg, Icon, Type, Title)



          app.alert({ cMsg: Msg, nIcon: Icon, nType: Type, cTitle: Title});



...which can be called from a buttons click event.

Form1.#subform[0].Button1::click - (JavaScript, client)

var Msg = "Hello, \r\rthis is a test.";

var Icon = "3"; //0 — Error (default) // 1 — Warning // 2 — Question // 3 — Status

var Type = "0"; //0 — OK (default) // 1 — OK, Cancel // 2 — Yes, No // 3 — Yes, No, Cancel

var Title = "Information for User";

event.target.MyDialog(event.target, Msg, Icon, Type, Title);


Level 10

Oops, I forgot that approach - good catch Radzmar



Level 2

Hi Radzma/Niall

Thanks for your answers on this thread - came up on a search and was very useful. Niall: thanks for your excellent suggestion at http://forums.adobe.com/message/2657538, which looks like a very good solution for creating a dialogue with the form user whilst submitting a more appropriate email with completed form data: I'm looking to combine this method with Radzma's suggestion on this thread to make the JavaScript window originate from a 'trusted environment' in order to delete the 'JavaScript Window' label, but am still trying to get my head round JavaScript I'm afraid! I was wondering if you had any suggestions for doing this please?

Essentially, it's to create the following sequence of events: user clicks 'submit' > JavaScript window pops up with message informing user what will happen next ('your email client will open and automatically compose a message, etc.'; also, this window to be 'renamed' as per this thread if possible) > Email message is composed with completed mailto, subject line, and body message

Your thoughts would be very much appreciated! Thanks


Level 10


I'll give my thoughts. Popups are useful and can be used successfully in a form. But on balance, if you can fulfill the purpose within the form itself, then the flow is much better for the user WITHOUT popups.

For example, I used to have a popup that warned the user when they were about to delete a row:


Now I am more inclined to use toot tips and highlight the object that is going to be deleted (normally it would be white):

Highlight object to be deleted.png

The Submit be email tends to bring up an explanatory dialog box already, so I don't think it is a good idea to have an additional one. I would be inclined to have fields on the form to collect the email address(s), and user inputs for subject line and body message. Then this information can be used in the script to form a custom email.

You could place a static text next to the Submit button, supporting the user by give instructions as to what will happen next. This could be italics and in a small font.

There are a couple of email solutions here: http://assure.ly/eUR4wJ, which may help.

Radzmar has some solutions here:



Hope that helps,



Level 2

Hi Niall,

Thanks very much for your response, especially being so swift! Appreciate your thoughts on this.

Oddly enough I found your suggestion below previously too, which was really good but just slightly different to the form that will be created here: essentially, it's a form which will have both paper and on-screen versions, so although normally I'd prefer to utilise tooltips for explanitory notes, as they of course wouldn't be visible on a printed version, I'll be using the design itself to show 'supporting information' (such as a consistent column on the layout dedicated to 'hints' on the respective question), so that both printed and on-screen versions have assistance on completing the forms.

In order to make the process of submitting the form as streamlined as possible for the user, I found your previous suggestion excellent as it populates all the fields in the email message for the user, allowing greater flexibility to customise the message and subject line of the email, saving the user the process of editing the email message themselves prior to sending or being confused with the default message that is generated with the standard 'submit' button. As there will only be one predefined email address, subject, and body message required, the intention is to reduce the work the user has to do in order to submit the form.

As the paper version will have instructions on how to post the form through the mail (an element that will be visible only when printed), I thought that perhaps the extra information relating to what would happen with the users' email client when the 'submit' button (an element that will be visible on-screen only) was pressed would be best suited to an explanitory message box, hence desiring to edit the message box's title as per this thread. But this could simply be information designed to sit within the form itself, using a visual heirachy to define it as 'supporting information, as you suggest. It's just an intention to simplify the design as much as possible and to create a dialogue, embedding an explanitory note specific to a process within that process itself.

There may be further instances too when a script may be required to be utilised to generate a message, such as this one: do you have any suggestions on assigning the 'trusted' function above to these instances (in order to remove the 'JavaScript warning' prefix)?

Many thanks


Level 10


Just a quick view, as I am heading out of the office.

On the basis of visible (screen only)/ visible (print only), as you suggest. If you have a small zone for the submission, can you set the Submit be email and electronic notes to visible (screen only) AND then overlay these with the snail main submission instructions as visible (print only).

This is the only trusted unction discussion I can find now: http://forums.adobe.com/message/2266799#2266799. It is quite long and talks about a save as function. However it does describe the trusted function and has screenshots.

I think you should clearly set out what the call to action is for the user in the submit button. Instead of "Submit", have "Submit by email", with a tooltip "Click here to submit your completed form by email. This will open a new email with the form already attached. Please make sure you send the email. Thank you!".

I have tried many approaches with dialog boxes, and here are my (current) views:

  1. I no longer worry about the JavaScript warning. It is a pain trying to maintain the scripted function for such a small issue. Yes, trusted functions can be very useful for meaningful interactions, but they are a bit too much effort just to remove this warning (imho). You can also certifiy the form with a digital signature, but this also has maintenance issues, as the user has to trust the certificate for the warning to be dropped.
  2. Try and avoid modal windows, but when do need them, I use WindJack Solutions AcroDialogs. These are much more flexible and give greater ability to easily customise the dialog. See: http://www.windjack.com/product/acrodialogs/. For example, you can add logos, to offset the negative aspect of the warning and provide some assurance to the user. Also it is a brand touch point.

Another option may be to DISTRIBUTE the form through Acrobat/Acrobat.com. The built-in submit button brings up a dialog for the user to complete. Maybe do a test run of this in a simple/test form.

Radzmar's blog also has examples.

Here are some discussions:



I hope that helps,



Level 2

Hi Niall,

Thanks very much for your suggestions and your comprehensive responses; appreciated. It's now just a case of getting down to the nitty gritty of LiveCycle (and JavaScript!) and applying good design principles and composing in a semantic way.




Level 1

Hello Radzma,

I would very much like to implement your proposed solution about starting the PDF in a trusted environment to get rid of the annoying alert title. Unfortunately I am new with Javascript programming (besides configuring an alert box in the action tab of a link in Acrobat Pro X) and not too familiar with programming in general. I would need a few more hints to realize your solution. Could you give it a try, please?

I understood that I have to enter the first code portion in a .js file and copy this to the javascripts directory beyond the Acrobat directory. The question: what should be the name of this file? (I actually did not understand where in the second code portion this first one is invoked...)

Additional remark: When I deliver the pdf to users, would they have to copy this file to their directory? (Probably a stupid question as they have only the Acrobat Reader...) How would I get this script or the whole functionality on their computer?

Concerning the second code portion: I do not know where to enter this code and which parts to adjust. I understood that this is related to a Mouse up event, but how do I connect this with my PDF file (If it is in the action wizard of Acrobat, how would I do this? Or else?)

I am happy that you came back to the forum after more than a year and hope that you can help me.

Many thanks in advance!