Seems like something has gone wonky with the javascript for the page.

I had a similar issue here: https://community.skuid.com/t/cannot-read-property-length-of-null-in-community
are you on version 6.6?

Thanks Moshe,  Actually, I am on 6.7 but the problem still exists

We are seeing “blank pages” intermittently as well (not community pages).  A simple refresh of the page (Ctrl-F5) solves the problem but it shouldn’t be loading blank to start with.  We have seen this in Chrome and IE so doesn’t appear to be browser specific.

Don’t have any details yet but will post further info as soon as I have it.  We have experienced this as recently as 6.7 and we seeing it with 6.6 and I believe 6.5.  Don’t recall if we saw it prior to 6.5 though.

Thanks for sending this along. If any of you can provide more specific repro steps - please send.  We will continue to look into these issues and try to figure out what is happening.

Hey Rob -

From what we’ve seen, there really aren’t “repro” steps per se on this one.  It seems to happen the first time a page is hit after opening a new browser (page doesn’t seem to matter). Refreshing the page makes it load properly and it doesn’t seem to occur again until a new browser is opened and first page hit.  It’s intermittent and doesn’t happen every time on first page load.  

I have a few users armed with “F12 Developer Tools” instructions and my cell # so been working on nailing down more information.  As soon as I have it, you guys will be the first to know :) 

Thanks!

We have had similar issues but only when the user navigates away from the open tab while the page is loading. If the user were to keep the loading page as the current tab it does not happen. All 3 browsers have the same issue.

I had a user encounter this today and fortunately the developer tools was open so I was able to get a “live” look at what is going on.

What appears to be happening is that several javascript files are not getting loaded in to the page, for example, skuid__jQuery. The first “exception” hit is inside of jquery-ui.min.js. The exception is triggered because jQuery is not defined - which makes sense since the jQuery file wasn’t retrieved. What doesn’t make sense is why it wasn’t retrieved. There were no console warnings indicating 404 or anything of that sort.

Here were the steps that the user took:

1. Open new browser (in this case IE11 running on Windows 8.1)


2. Navigate to https://test.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

Actual Result

Exception in jquery-ui.min.js with error jQuery is undefined and a blank page results

Expected Result

Skuid page loads normally

Notes:

1. The VF page is 3 lines and just contains a skuid:page element


2. The Skuid page is rather straightforward and contains some panels, a custom component and a custom renderer. I don’t believe that the contents of the page has anything to do with the issue based on what I saw but it’s possible.


3. A Ctrl-F5 and the page loads normally


4. Closing all browsers and repeating the exact same steps and everything worked as expected


5. This occurred on Skuid 6.8 (most recent release)


6. The HTML on the blank page does contain a script reference to skuid__jQuery but for some reason it was never loaded. One thing I noticed is that the HTML that is rendered does contain and
   elements inside of a element which is invalid HTML markup. That said, this shouldn’t cause the issue encountered (although likely should be adjusted) but is something to be aware of.
   
   
   

I have granted login access. I also have several screen shots and some additional diagnostic information that I will zip up and send to support via email along with the Org ID.

The problem itself is very intermittent and not reliably reproducible unfortunately. I’ll continue to gather additional information as we encounter the issue moving forward.

Assistance, as always, is greatly appreciated.

Thank you!

Thanks for all the details.  We will dig into this… 

Thanks Rob.  One thing I forgot to mention is that this particular user has their IE browsing setting configured to check for newer versions “Every time I visit the webpage.”  I have this same configuration on my IE and similar on Chrome (I’m typically using Chrome) and have also seen the issue but very rarely and unfortunately, not recently.

I had a user (same one as last time) encounter this issue again today and the good news is that I think we might be getting some signs of a pattern.

The user had shutdown their machine last night and started it up this morning.  They encountered the issue on the first attempt to access the Skuid page backed by the VF tab.  They indicated that when it happened the other day, it was also the first time they accessed the site after a reboot.  I then had them reboot again and the problem occurred another time.  During this 3rd occurence, I was able to capture additional diagnostic information including a network trace.

What appears to be happening is a number of HTTP 302’s that result in an HTTP 404 for Skuid’s JQuery and SkuidJS files.

Here’s the high-level overview:

1) myorg--c.cs16.visualforce.com/.../skuid__skuidJS requested but gets 302 to myorg--skuid.cs16.visual.force.com/.../skuid__SkuidJS
2) myorg–skuid.cs16.visual.force.com/…/skuid__SkuidJS requested but gets 302 to myorg.cs16.my.salesforce.com/visualforce/session?url=....skuid__SkuidJS
3) myorg.cs16.my.salesforce.com/visualforce/session?url=…skuid__SkuidJS requested but gets 302 to myorg--skuid.cs16.visual.force.com/visualforce/recsession=sid=...skuid__SkuidJS
4) myorg–skuid.cs16.visual.force.com/visualforce/recsession=sid=…skuid__SkuidJS requested but gets 302 to myorg--skuid.cs16.visualforce.com/resource/####/SkuidJS
5) myorg–skuid.cs16.visualforce.com/resource/####/SkuidJS requested but gets 404

Note that in #5, the request was for “SkuidJS” not “skuid__SkuidJS”.

I have the following captured:

1) Several screen shots of various information (console output, network trace, HTML from DOM, etc.)
2) NetworkData.xml trace file
3) I also closed the browser and repeated the same exact steps and the page displayed successfully.  I have NetworkData.xml and screen shots from the “good” scenario as well to compare.  In the good case, there are no 404’s or references to “SkuidJS” as in #5 above.

I’ll package up the files and send to support.

Another note is that after gathering all the above, I had the user clear cache and try again and the problem occurred again. I had them clear cache again and try again and this time it did not happen.  Then had them reboot and try again and the problem didn’t happen.  Seems to be related to caching in some way but can’t quite nail down consistency yet.

I’ll keep monitoring as you guys dig in to the new info.

Some additional anecdotal information that we’ve observed since yesterday…

We have a 2nd sandbox that doesn’t seem to reproduce the issue despite most everything being the same.  The one key difference between the sandbox that experiences the issue and the sandbox that doesn’t experience the issue is that the one that does uses the “ModuleNameJS” & “ModuleNameCSS” automatic include feature of Skuid where as the sandbox that hasn’t seen the issue explicitly includes all resources on each page.

This is all unscientific testing so just because we haven’t seen the issue in sandbox #2 doesn’t mean it won’t eventually happen.  That said, we’ve done enough testing to at least identify a pattern of difference so wanted to make sure you had the info in case in helps isolate root cause.  Both sandboxes are on 6.8.1.

Thanks!

This just happened to me as well. Made a video. Sorry about the length of the video. Kinda followed my nose based on all that I’ve read about it.

Have all of these instances of this error been on a Custom Visualforce page that uses the skuid:page component?

Here’s mine. Stock Skuid CRM Account tab.

Yeah, from what I can tell so far this is a namespace issue.  A Visualforce page from another namespace needs to specify the Skuid namespace when loading the resource.  What is really weird is the fact that it is intermittent.  I think we can be a bit more specific in our code to make sure that the “skuid__” is always included when trying to retrieve resources.  I’ll keep you guys posted about what I find.

Hey Ben - In our case yes, all of our pages are driven by custom VF page that contains a skuid:page component. I’ve granted login right and sent over the orgid via email to support. Feel free to login and take a look if you’d like.

Hey Ben - We’re able to fairly reliably reproduce the issue now by doing the following:

1) Clear browser cache
2) Reboot
3) Login
4) Click the tab that contains the skuid page

It doesn’t happen 100% of the time but often enough.  As you said, it’s very strange that it’s intermittent.  Given the steps above, I think it would be relatively straightforward to create a small repro in your org so you can debug server side to see what’s going on or your welcome to login to our org and do some testing.

Let me know if there is anything I can do on my end to help.

Hi Barry,

I can get the error to happen in my org every time if I restart Chrome and then use Incognito Mode.  So I think we have what we need.  Still looking into why Visualforce would return a url with a namespace most of the time, but some of the time not do that. I have a few ideas that I can try though.  Unfortunately, this is untestable in our dev org, so we’ll have to release packages and then test them out to see if the behavior changed.

Being able to reproduce this consistently is a step forward.  Thanks for all the help.

Doh!  Incognito mode, of course, makes perfect sense (no cache) - wow, was I buried way to deep in the weeds on isolation.  

Awesome that you can repro consistently.  The behavior is so strange, just doesn’t make any sense.  Based on what you wrote, appears that you guys call in to SFDC to get the url.  Possibly a bug in SFDC - maybe something where there is a reference of a cache’d item or something server side that doesn’t yet exist and the code continues instead of waiting for the cache to populate.  On subsequent attempts, the cache has the value and therefore the url has the correct value.  Just thinking out loud…

Thanks again Ben!

Another thing ,  I recall it started happening after salesforce’s critical updates (about a month ago). And I don’t remember it happeing before that critical updates. If it helps to debug…

Hey Ben … just wondering what your thoughts are on this now. It has a pretty confusing impact for our clients, particularly for new users logging in for the first time wondering where their app is.

Hi Glenn, the plan is to have a fix out for this by the end of this week.

Hi All,

From our investigation it looks like this is a bug on Salesforce’s end. It also looks like this has been fixed in the Salesforce Spring 15 release.  We’ve been unable to get this bug on orgs that are running Salesforce Spring 15.  Can you all with Spring 15 orgs verify this?

I just tried a production org with Salesforce Winter 15, loaded up the PractiFI home page, crossed my fingers and toes … and it worked fine. So based on a sample size of 1, we’re in good shape.