Pages no longer loading after upgrade to 9.3.3

I experienced a similar problem and when I changed my theme from a custom one to one of the standard ones my pages showed up - not sure if this is the same problem you are having but worth a try.

Thanks Susan. I’ll give that a try

Actually…I am already using a standard theme: Clean Green

Hi Conlan and Susan. Once you attempt to load these pages, are you able to look at the console in your browser’s dev tools for any error messages? If so, please share them here. Also, is it an issue that is consistently happening on certain pages? Have you found anything that the affected pages have in common? 

Mark: see error messages in screenshot above.

No, it seems pretty hit or miss whether the pages load or not

Mark - I haven’t experienced this problem since switching my theme to a default one.
Thanks,
Susan

Susan, I’m glad to hear that took care of this issue for you.

Conlan, does the page in question have any models that reference the User object? 

Mark, upon looking more closely at the error messages, it looked like an issue with the JS resources embedded in the page. When I removed them, the page loaded correctly.

Unfortunately, that means I can’t use those JS resources unless I resolve why 9.3.3 is no longer playing nice with them.

Would you be willing to take a look at the In-Line Component JS below to see why the issue is now ocurring:

// JSignature <a href="https://github.com/willowsystems/jSignature" style="font-family: &quot;Source Sans Pro&quot;, Helvetica, Arial, sans-serif;">https://github.com/willowsystems/jSignature</a> and&nbsp;<br>

// SKUID http://www.skuidify.com/home 

// demo for saving drawing of signature in Salesforce

// Peter Baeza - 2014-04-22

var element = arguments[0],

   $ = skuid.$;

$(document).ready(function() {

    // init signature canvas

    element.jSignature();

    element.jSignature("reset");

    // Create new signature in text field

    var model = skuid.model.getModel('SemiAnnual'),

        row = model.getFirstRow(),

        sigField = 'Semi_Annual_Signature__c', 

        sigData = model.getFieldValue(row,sigField);

    if(sigData !== null ) {     // read back Signature data

        element.jSignature("setData", "data:" + sigData);

    }

})

The jSignature element is stored within a static resource (referenced by another JS resource within the page).

Any ideas/help would be greatly appreciated

Thank you for following up with this new information. Looking at your screenshot, it appears that the jSignature.min.noconflict.js is throwing errors, rather than an inline snippet. There is also the error above that, regarding the user-agent, and I’m not sure whether that error could be related to the jSignature errors. Since you have the jSignature resource in your org, do you have a way of setting up a simple test page to see if that javascript throws an error in a more stripped-down environment?

Hi Mark, yes I just set up a test page with the same JS Resources, and the error continues to throw

Could you describe the resources you’ve got on that page? And is the page throwing the errors intermittently, or every time you load it? Are the errors the same?

It’s just the In-Line Component JS listed above, and the static resource. The static resource file is a signature capture canvas

File here: https://drive.google.com/file/d/0B1PKG9_1V4XTeE1jdi1hdTdmSVE/view?usp=sharing

Originally downloaded from GitHub here: https://github.com/willowsystems/jSignature

And yes, the same error is thrown consistently every time I load the page

Related: We are having the same problems and we would like to roll-back one of our sandboxes to pre-brooklyn.  Has anyone tried this?  Is it possible?

Hi Peter - 
Here is some helpful insight (paraphrased) I received yesterday from Karen @skuid:

Regarding rollback: 

The issue with Salesforce’s Spring '17 release created problems in installing any version of Skuid. They provided a workaround which has been implemented in Brooklyn Iteration 3 (9.3.3) so currently, customers are only able to install 9.3.3. Even if we could help them uninstall and reinstall (not recommended), we wouldn’t be able to get them back on 8.15.8. (from a package install)

Options:

1. They can create a new sandbox off their production org and it should automatically bring the production version of Skuid (Rockaway 10) down with it.  They would be able to package up their Skuid pages in the sandbox they’ve been working in so they don’t lose their development there. They’d be able to unpack those pages in the desired sandbox. Here is a tutorial on how that can be done.

*note: If you have not yet installed skuid on production, you can still do so as long as your production instance is still on Winter '17 and has not been updated to Spring '17

2. A number of bugs from 9.3 have been resolved in 9.3.3 and more will be addressed in Iteration 4 (released 1/26/17, currently available on skuid.com/release website). (you may need to install 9.3.3 into an org before updating to 9.3.4 because of the Spring 17 issue, not positive on this one)

Also, Skuid has an auto-update opt-out list that you may want to put yourself on.  Just send the request to their support email and provide the org ids for the environments you don’t want to auto-update.

Hope this helps!

Hi Conlan,

First we have to find out, on which jSignature call, you get the error. I assume it’s on the second or the third one. Comment out one at a time, until your error doesn’t show up again.

If it’s the second one, try to use

element.jSignature("clear");

instead of

element.jSignature("reset");

If it’s the third one, try to pass some hardcoded data (see below) and let me know if it works, so I can help you further investigating this issue.

element.jSignature("setData", "data:" + "image/jsignature;base30,cVZ1000Y59ce1Gomn1Sla4331222_2Q9aad331000000062344544");

Hi Jannik,

Great, thanks. It looks like its the second call that throwing the error…once I commented that second jSignature call, the page loaded fine…although the Sign component didn’t load (but I think that’s to be expected).

Please advise.

Thanks,

Conlan

This may help resolve the error. Anywhere that the following code is used:

$(document).ready(function() {

Replace it with:

$(“.nx-page”).one(“pageload”, function() {

Excellent, that took care of the issue. Thanks Zach!

Great to hear! Just want to make a note that this is not a change introduced by the Brooklyn / 9.x.x release,  $(document).ready(function(){ … }) and $(function(){ … }) have not worked in Page Includes for years now at this point, the only way to reliably have Javascript code run from a Page Include only after Skuid Model initialization is complete is to use the .one(“pageload”) approach.