Thursday, April 21, 2016

Freeze pane on SharePoint list

In case of a larger SharePoint list, end-users may appreciate that the header row remains in the visible area while they scroll through the list. Out-of-the-box the SharePoint XsltListView webpart does not provide this functionality. However, it is possible to augment the standard behavior by modifying the rendered HTML through javascript. There are multiple examples published, but for some reason these did not immediate work for me. Did get me inspired though, and I coded a jQuery-snippet that when inserted in a page containing a XsltListView webpart delivers the 'freeze pane':
<script src="" type="text/javascript"></script> <script type="text/javascript"> $(document).ready(function () { var $table = $(".ms-listviewtable").first().data("summary", "<listview name>"); // WRAP TABLE IN SCROLL PANE $("#s4-workspace").css( { overflow: 'hidden' } ); $table.wrap("<DIV class='FreezedLV' style='OVERFLOW: auto; HEIGHT: 550px;'></DIV>"); // FROZEN HEADER ROW $(".FreezedLV").wrap("<DIV class='FreezedLVContainer'></DIV>"); $("<table id='FreezedTR' class='ms-listviewtable' cellPadding='1' cellSpacing='0'></table>"). insertBefore(".FreezedLV"); $("#FreezedTR").width($table.width() + "px"); var $origHeader = $("", $table); var $firstRowTable = $("", $table); var $freezeHeader = $origHeader.clone(); // Propagate the computed width of columns of origheader to freezeheader $origHeader.children("th").each(function() { var width = $(this).width(); var ownerIndex = $(this).index(); $($freezeHeader.children("th")[ownerIndex]).width(width + "px"); }); // Propagate the implicit width of row columns as explicit widths in first row to // avoid layout-changes when hiding the original header $firstRowTable.children("td").each(function() { var width = $(this).width(); var ownerIndex = $(this).index(); $($firstRowTable.children("td")[ownerIndex]).width(width + "px"); }); $("#FreezedTR").append($freezeHeader); $origHeader.hide(); }); </script>

Tuesday, April 19, 2016

How-to have IE11 pick up local PAC file

In our company we utilize a cloud-hosted Proxy Automatic Configuration script (PAC file). On occasion it is convenient to switch to a local version, e.g. to investigate or troubleshoot. When we still were at IE9 this was easy, but since we’ve upgraded the company browser to IE11 it becomes more difficult. To promote interoperability across network stacks, Microsoft deprecated the option for a local PAC file. You can still configure it in Internet Settings, but IE 11 will simple ignore a local proxy auto-config file.
However, Microsoft also understands it’s backwards compatible responsibility. And therefore build in support to overrule the deprecation of local PAC file. The approach consists of 2 steps:
  • Step 1: [source: Understanding Web Proxy Configuration] Via registry value 'HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\EnableLegacyAutoProxyFeatures' specify that it is ok to utilize the legacy Internet Settings. Note that in our company the regular users are not enabled to set this, as they are not administrator on their workstation. But the occasional usage of local proxy file is then also not for these regular end-users.
  • Step 2: [source: local proxy which is set in the proxy auto config of IE11 is not processed correctly by IE11] Create the local PAC file as "c:/windows/system32/drivers/etc/proxy", and specify in IE as setting for automatic configuratio script = 'file://c:/windows/system32/drivers/etc/proxy'

Friday, April 1, 2016

Corrupted blobcache hindered responsive rendering

In the branding of our SharePoint 2013 based intranet we utilize Bootstrap for responsive design. However, we noticed that the rendering for mobile user agents was not correct, e.g. the company logo was displayed twice. Remarkable was that in our acceptance environment, it did render correct. On analysis I first discovered that the requests of some resource files (javascript, css) resulted in AccessDenied, but only for mobile UserAgent in the request header:
  • User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) ➜ Downloaded
  • User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) AppleWebKit/600.1.3 (KHTML, like Gecko) Version/8.0 ➜ Not downloaded
Also I noticed that the response for IE as User Agent was successful serviced, but that 'max-age' setting was set to zero in the response (Cache-Control). As on SharePoint webapplication level the Cache-Control header setting is controlled by SharePoint blobcache, this put me in the direction of a blobcache corruptness issue in our production environment. To resolve from the corruptness, our SharePoint operations created a new blobcache for the intranet webapplication. And indeed this resolved both issues: max-age value is set with a positive value (so that lesser times the resource is requested by browser), and also for mobile UserAgents the resource request are now responded with the actual files.