Adobe LiveCycle (Archived)

Zvranic · 1/10/11

It occurred couple of times while opening task in workspace: 'Expected hexadecimal digit'

Sniffing communication between client and LC server revealed that URL that should point to some temporary server file contains server path:

C:\LCGDS\doc17987987

first '\' from that path makes whole URL unparsable by IE - hence the aforementioned javascript error.

LCGDS is Global document storage directory which is, at this point, local to LC server.

It is not possible to repeat the isssue or connect it to particular document, user or workstation.

We have LC ES2 with latest SP and single server (non-clustered) configuration.

What to do?

Report · 1/11/11

Didn't think it would be on ES2 but it is so it's a bug you need to contact support to get a patch for it.

The url should end with the filename part of the path (e.g normally something like /expenses.pdf) and not included any preceding drive:/path/path info). The bug is that when the full path filename contains backslashes, the parsing didn't work.

The filename is pulled from the fileName attribute of the Document provided to the render service. This case could only happen if you are using a document variable in your process. As a workaround, you could temporarily change the process to clear the fileName attribute of doc variable containing the form before it is used in a user step. (use setvalue with Document function setDocAttribute(docvarname, "fileName", "" - note that this returns the updated document so easy to use in a setvalue).

I would not recommend trying to modify workspace to fix this.

View solution in original post

Zvranic · 1/11/11

I managed to pinpoint the problem.

IE has a problem with this line of JS code:

try { __flash__toXML(createResourceContainer("workspacehr","Resource_B048A5A0-2157-D64F-1E49-74F49BD4CAE0","http://myserver:8080/workspace-server/documents/247043599265782593-60/C:\LCGDS\docm1294225602154\uj7g56xyyow23629a1t8rdy03000tnjo","application/pdf")) ; } catch (e) { "<undefined/>"; }

This line of JS code contains following string:

"http://myserver:8080/workspace-server/documents/247043599265782593-60/C:\LCGDS\docm1294225602154\uj7g56xyyow23629a1t8rdy03000tnjo"

and problem lies on last part of string:

\uj7g56xyyow23629a1t8rdy03000tnjo

uj7g56xyyow23629a1t8rdy03000tnjo is an actual file name of a LC temporary file containing PDF form to be displayed for the task.

Problem arises on occasions when this file name (obviously random generated) starts with the letter 'u' as in example above.

Together with preceding backslash they form '\u' which is a signal for IE that what's following next is a unicode character. Most of the time it isn't and IE stops with 'Expected hexadecimal digit' JS error. Form is not loaded, task cannot be opened.

Now, I have looked at Workspace source and I wasn't able to find any reference to line of code mentioned above (nor to just __flash__toXML part) and I suspect that this javascript line of code is returned by the LC server which lieves me without options:

- i cannot change generation of random file names

- i cannot interfere with JS code that generates the error in IE

- i cannot force our clients to change the browser (Chrome is OK with this, Firefox generally don't agree with workspace app at all)

What can I do next?

Report · 1/11/11

This is a bug (the full disk path should not be in the url) and it was fixed in a Process Management patch for 8.2.1.3.

The situation is rare that a disk path with backslashes would be used but it (obviously) can occur.

Contact support and either get this patch if you are using SP3 or log the incident to have it ported to whatever version you have.

Also note that for all new Process Management patches, including this one already done on 8.2.1.3, there is a required Core/Foundation patch (don't recall the number) so ensure your support person provides this as well.

Jon

Zvranic · 1/11/11

We are running LC ES2 so, according to About page in admin console we have

ADOBE® LIVECYCLE® Process Management ES2

9.0.0.0

SP2

Does this patch for 8.2.1.3 still apllies?

Is there a patch for ES2? It's obviously not fixed...

Anyway, I resolved my immediate problem by changing workspace source.

After some javascript debugging i was very suprised to find out that
my string url parameter from call:
__flash__toXML(createResourceContainer("workspacehr","Resource_B048A5A0-2157-D64F-1E49-74F49BD4CAE0","http://myserver:8080/workspace-server/
documents/247043599265782593-60/C:\LCGDS\docm1294225602154\uj7g56xyyow23629a1t8rdy03000tnjo","application/pdf"));

inside actual js function createResourceContainer becomes:

http://myserver:8080/workspace-server/documents/247043599265782593-70/C:LCGDSdocm1294225602154uj7g56...

Backslashes were simply removed!!

After I figured out that

__flash__toXML(createResourceContainer(...

is actualy generated by:

ExternalInterface.call("createResourceContainer",

I just changed Workspace source file: ResourceContainer.as and in function createResourceContainer instead of:

ExternalInterface.call("createResourceContainer", Application(Application.application).parameters.swfId, containerId, url, contentType);

i wrote:

ExternalInterface.call("createResourceContainer", Application(Application.application).parameters.swfId, containerId, url.replace(/\\/g, ""), contentType);

effectively removing backslashes before they could reach javascript and cause problems with IE.

It still baffles me:
- how were these backslashes removed during js function call? when? why?
- how come that LC manages to sort out paths like: C:LCGDSdocm1294225602154uj7g56xyyow23629a1t8rdy03000tnjo
- why in the world LC server has to send itself its local temp file path via client in the first place

Report · 1/11/11

Didn't think it would be on ES2 but it is so it's a bug you need to contact support to get a patch for it.

The url should end with the filename part of the path (e.g normally something like /expenses.pdf) and not included any preceding drive:/path/path info). The bug is that when the full path filename contains backslashes, the parsing didn't work.

The filename is pulled from the fileName attribute of the Document provided to the render service. This case could only happen if you are using a document variable in your process. As a workaround, you could temporarily change the process to clear the fileName attribute of doc variable containing the form before it is used in a user step. (use setvalue with Document function setDocAttribute(docvarname, "fileName", "" - note that this returns the updated document so easy to use in a setvalue).

I would not recommend trying to modify workspace to fix this.

Zvranic · 1/12/11

Thanks a lot Jon!

I know workspace shouldn't be modifyed like this but I thought it was the only option and it was critical to resolve the problem at client installation ASAP.

Your suggestion to clear fileName att from document variable worked and that is very good, nonintrusive solution which we will use instead of modified workspace.

Anyway, after this fix url is now just:

http://myserver:8080/workspace-server/documents/247043599265782593-95/

No file name at the end. But it works.. :-)