Lookup value (rendered as picklist) changing on jqueryprint's .print()

We’re running jqueryprint (along with @media print CSS) to print elements of our pages. It’s working great, except that in this case that value for a lookup field (rendered as a picklist) is changing with .print().

Here’s what it looks like on screen:

Here’s what the print preview looks like:

Any thoughts on what might be going wrong here? Where would you start troubleshooting?

Interestingly, if I print the whole browser screen, the value for the picklist stays intact.
It’s not a CSS @media issue, because the console’s CSS @media print emulation looks fine.


Assuming that jQuery.print.js prints the “selected” option, it appears that no option is selected?

What do you see when to inspect the DOM element?

Here’s a screenshot of the DOM element that we’re asking jquery to print…

The data is in the skuid model. It’s a reference field… I’m not sure how that affects anything?

Which option is decorated with the ‘selected’ attribute?

None are. The next line after what you see in the screenshot is .

I suspect that is the problem.

This is easily reproducible outside of Skuid e.g. JSFiddle.  It would be interesting to get Rob’s take on this.

Skuid? Is this a bug?

Do I have to manually attach the ‘selected’ attribute to the DOM element that is selected? How does Skuid know which value is selected in a picklist, or communicate that to the DOM?

The selected attribute is set by the browser whenever you select an item from a picklist.  Like I said, I can recreate this scenario outside of Skuid e.g. inside of JSFiddle.  I would definitively ask one of the Skuid folks to spend 5 minutes investigating; I think you’ve earned the right to ask.

Thanks for the vote of confidence, Irvin.

Skuid-- anyone want to give this a go?



Update: Looks like this is also and issue with text boxes.

Displayed on screen:

Print preview:

From a quick scan of the github project, it looks like jQuery print is actually copying the HTML elements into a hidden iframe element and then printing that. If that’s the case, then user-updated form elements will not have their value (or selected value) copied to the iframe as that information is contained within the browser’s memory, not in the HTML.

It looks like they have a property to overcome this limitation (though it may be “expensive” to use and I’ve not tested it with Skuid for compatibility):



Thanks for taking a look. manuallyCopyFormValues is true by default. Even when I set it explicitly, it’s still not copying the user input. I’ll try the popup option instead of the hidden iframe in the next day or so and let you all know if that works.