Possible bug with DFFS_Loader.html 21st January 2018 release

[AdamP]

Hi Alexander

After updating DFFS we’re encountering an issue with previously known good vLookups failing to load.
I’ve pinpointed this to the change made to DFFS_Loader.html on 21st January 2018 – it looks like you made a change which included the src-min-noconflict for the ACE editor, although I don’t know why that would kill the vLookup for us. We’re running on-prem SP2010.
I can replace the DFFS_Loader.html from the December 2017 release into any of the more recent released and the vlookups load correctly again.
Screenshots of the before/after attached. There don’t appear to be any errors in the console. Interestingly, the same vLookups are fine when using vlookup list view, it’s purely in the forms where there is a problem.

Thanks

Adam

Attachments:

1. 

   vLookupIssueDecember2017.png
   

2. 

   vLookupIssueJanuary2018.png
   

[Alexander Bautz]

I know there is issues with the ACE editor when editing a DFFS config in IE when because SP 2010 forces it to IE 8 mode, but I haven’t had any reports about this issue.

Are you able to check to see if it is the same behavior in other browsers (like Google Chrome)?

Also, did you update all the files in the new DFFS package so the path where the loader looks for the new ACE files exists?

Alexander

[AdamP]

Yes – the whole package was updated – SPJS/DFFS folder replaced with entire package from the download. When we noticed the problem I started experimenting with the custom versions to track down the issue.

I can force it to fail by switching from DFFSv2017-12-20 to DFFSv2018-01-21. Then replacing DFFS_loader.html from 2017-12-20 into the 2018-01-21 version appears to restore the vlookup functionality, although ace.js doesn’t actually exist on the path specified in the older loader…

Firefox behaves exactly the same as IE11 (in IE8 mode), changing the document mode in IE has no effect.

Attachments:

1. 

   ACEsrc-min-noconflict.png
   

2. 

   ACEDecember2017.png
   

3. 

   DFFSVersions.png
   

[Alexander Bautz]

This was strange. I haven’t had any other reports on this issue – are there anyone else experiencing the same issue?

I have checked the current version of the loader with the one from December 20, 2017 and it’s basically only the path to the ACE files that has changed, and I cannot see why the changed ACE folder could cause this issue because it isn’t actually loaded when not in the Backend – it is wrapped like this in the code:

// ACE Code editor - must use the appendChild method to ensure it loads dependencies
if(dffs_loadBackend){
    s = document.createElement('script');
    s.src = spjs_path+"/ace/src-min-noconflict/ace.js?v="+dffs_scriptVersion;
    document.getElementsByTagName('head')[0].appendChild(s);
}

The dffs_loadBackend variable would be false in Frontend mode.

Alexander

• This reply was modified 6 years, 4 months ago by Alexander Bautz. Reason: Posted the ACE path from the December 20, 2017 version and not the current one

[AdamP]

It seems I created a red herring in my initial assessment of this issue, I think there were some browser cache settings interfering.
The issue for us actually seems to lie in SPJS-vLookup_frontend.js.

I can install the very latest package of DFFS in it’s entirety and vlookup fails as per the original screenshot. If I then replace /SPJS/DFFS/plugins/SPJS-vLookup_frontend.js with the version from the 2017-12-20 package, vlookup fields immediately start to work correctly again.

Running firefox developer tools > network tab on an identical form, I get the following results consistently;
2017-12-20 vLookup_frontend: 73 requests, 4,045.71kB, 8.01s
2018-01-21 vLookup_frontend: 67 requests, 4,029.43kB, 7.52s

The 6 requests difference are the ones shown in the screenshot attached (using vlookup_frontend 2017-12-20), but with the later vlookup_frontend, they just don’t appear to fire at all.
Clicking the vLookup refresh button using vLookup_frontend 2017-12-20 returns the last 4 rows from the screenshot.

Is anyone else successfully running SharePoint 2010 and a vlookup version after 20th December 2017?

Thanks

Adam

Attachments:

1. 

   vLookupFrontend20171220.png
   

[Alexander Bautz]

Hi,
Could you try hitting F12 to bring up the developer tools – select “Console” and type in this:

spjs.vLookup.version;

It should write out the vLookup version.

If the above returns a version number and not “undefined” you can try writing this and hitting return:

spjs.vLookup.init();

Alexander

[AdamP]

Latest Package (non-working);

spjs.vLookup.version;
“2.2.123”
spjs.vLookup.init();
undefined

Latest package modified with December 2017 SPJS-vLookup_frontend.js (working);

spjs.vLookup.version;
“2.2.108”
spjs.vLookup.init();
undefined

In both cases nothing seems to change after the init. The Latest version continues to show the /_layouts/images/gears_anv4.gif spinner and “Loading…” text.

[Alexander Bautz]

I’m not sure exactly what could cause it, but I have made some changes to this plugin that could be relevant for this issue. Unfortunately I don’t have access to a SP 2010 site now to test it so I was wondering if is is any chance I could log into your site and look at it there?

If so, please email me the details.

PS: If your vLookups work when you load the December 2017 version of the plugin you can just continue using it with the latest DFFS version.

Alexander

[Author]

Posts