Glenn, just to clarify, you mean Spring 15, right?

Hi Ben -

We were just upgraded to Spring '15 this morning.  Prior to Spring '15 upgrade, I was able to repro the problem consistantly using Incognito mode.  I’ve run about 5 test passes against Spring '15 and have been unable to reproduce thus far - page loads the first time each time.  Network trace looks like I would expect it to.  Can’t say we’re out of the woods yet but it looks very promising.

Will keep you posted as I do some more testing and have other users do the same.

Do you have a link to the issue that SFDC resolved as part of Spring '15?

Thanks!

[Removes palm from forehead] Yes, I meant Spring 15.

Update - Had a couple of other users test and we have not seen the problem as of Spring '15.  

Hi Barry, I never saw an official issue, but I did notice that how Salesforce authenticated static resources changed between the two versions of Salesforce.

The error was being cause when Skuid requested a certain static resource say skuid__SkuidJS. If there was not a certain session cookie set, Salesforce would serve up a HTTP 302 to /visualforce/session instead of serving up the requested content with a HTTP 200 like you’d expect.  The HTTP 302 would take your poor browser on a wild HTTP 302 goose chase that passed through /visualforce/session and /visualforce/recsession and back to /visualforce/session and finally to back to your intended destination with your session cookie included.

The problem however was that if your original request included a managed package namespace, somewhere along the chain, it was removed, and ended with a bad, although authenticated request.

However, by examining network traffic in Spring 15, it looks like Salesforce is doing a much better job authenticating resources.  I’m still not 100 percent sure how all this works, or what exactly salesforce is doing with these 302s, but from what I’ve seen, this issue is gone in Spring 15 and you should actually see less latency because a lot of these 302s have been eliminated.

Hi Ben -

Appreciate the details, thank you.  Consistent with what you describe, I noticed far fewer HTTP requests on page load and the 302 wild goose chase is gone.

Thanks again!

Same here. Better page load performance and no recurrence of the major failure since Spring 15. Tickety-boo.

We’ve been seeing what looks like a recurrence of this bug in recent weeks, perhaps since the rollout of Salesforce Summer 15.

I can recreate it consistently as we did before:

1. Open new Chrome incognito window


2. Navigate to https://login.salesforce.com
   


3. Input credentials


4. From SFDC home page, click a tab link that is backed by a VisualForce Tab page that contains a skuid page

Screenshot of the failed page with console:

As before, a simple page refresh fixes it every time.

This is a production org running Skuid 6.8.19.

Is anyone seeing the same?

Hey Glen - Just tried with 6.8.20 in a couple of sandboxes and am unable to reproduce.  Are you seeing this in just Prod or also in sandboxes?  Possibly 6.8.20 will solve your issue?

I just upgraded the prod org to 6.8.20 and am still getting the failure. Every time it fails to load resources:

https://skuid.ap1.visual.force.com/resource/1433565733000/JQuery 
https://skuid.ap1.visual.force.com/resource/1436413923000/SkuidJS 

I haven’t tried a sandbox.

Outside of SB vs prod, one other difference between your situation and mine is that I believe you are in a managed package, correct?

Yep, that’s right. And Ben’s previous posts suggested it was namespace related.

Can I give this a bump please? Can others reproduce this in a managed package environment? We’re getting it repeatedly.

Are you getting any JS errors?  Can you post those - or send via email? 

Can you reliably reproduce the issue?  If so could you grant us login rights and send us an Org ID and the repro steps via email?

We’ll try to get to the bottom of this.  

Ok, Glenn.

I was able to recreate the issue in our Demo org. At first I couldn’t because of two issues. I only get this problem when the “Serve Static Resources from the Visualforce Domain” critical update is enabled. Also, when I had a Skuid page load as a Home Page component I couldn’t replicate the issue either.

A quick (hacky) workaround would be to have your home pages load in something that used Skuid.

Another workaround for now would be to disable that critical update. (It shows I still have 51 days before it will be automatically applied.)

We’ll keep looking at this issue and possibly raise a case with Salesforce.

Good spot, mate. That makes sense re the critical update. In our production org, the critical update is activated and I consistently get the failure. In our demo org it’s deactivated and I don’t get the failure. I then went to the production org, deactivated the critical update, retested and I don’t get the failure anymore. So that gives us a 50 day window.

As for your workaround, PractiFI loads a Visualforce page with a Skuid page by default, bypassing the Salesforce home page, so that probably won’t work for us.

Thanks for your help Ben & Rob. Keen to hear how you get on with it from here. 

Thanks Glenn. 

Quick Update on this…

I found this “known issue” that looks to be quite related to what we’re seeing here. Feel free to  click “This issue affects me”.

https://success.salesforce.com/issues_view?id=a1p300000008XWkAAM

Another quick update on this issue. I’ve been working with Salesforce support on this and we finally have a “known issue” that relates to this issue. Another update is that the enforcement of this critical update has been delayed until the Spring 16 release.

Here’s the link to the known issue.
https://success.salesforce.com/issues_view?id=a1p300000001ACTAA2

Feel free to click the “This issue affects me” button in the issue.

Any update on this? We’ve experienced it from time to time and its particularly frustrating when the first thing a new trial user sees after logging in is a blank screen. I understand it’s a SF issue, but any advancements? 

Is there a way to display a message “behind” the Skuid page if it doesn’t load? That way we could say “Please refresh your browser”. I’m thinking similarly to how some ads show text behind the ad if you’re running adblocker.

For now the resolution is to not have the “Serve Static Resources from Visualforce Domain” Critical update applied. They’ve extended forcing that critical update until the Spring 16 release. Word is they’ll have it fixed by then.

When you first log into the app, the first screen is blank and requires a refresh. The update is deactivated. 

Interesting, I’ve never seen this issue before with the update deactivated. Are you getting any javascript error in the console that first time? If so, can you post a screenshot?

Disregard above. Apparently I somehow enabled this update in my TSO but not my development orgs. The update WAS enabled in this org. I have disabled it from my TSO so hopefully future trial templates will not have the same issue.