Fix for SharePoint 2010 scrolling problems for Chrome, iOS4 & Android

The other day a public facing website that had been built upon the SharePoint 2010 platform was experiencing some scrolling issues. After a date with Google and a few furrowed brows, I crafted a hybrid solution of my own that worked best for my particular scenario.

The Problem

Scrolling did not work when visiting the site using:

  • Google Chrome
  • An iPad or iPhone that was running iOS4
  • Google Android phones

The Solution

I was able to identify that the source of these scrolling issues was due to the manner in which the static placement of the SharePoint 2010 “Ribbon” was implemented. Essentially the default browser scrolling behaviour has been overridden and replaced with a JavaScript solution that has a few problems. While I appreciate the improved authoring experience that the static ribbon provides for content authors, it serves no purpose for anonymous visitors to the site.

Below is what I did to hide the ribbon control, and override the JavaScript scroll bar if you are an anonymous visitor.

Let’s just jump right in, shall we?

Psst…If you don’t care about the “why?” and just want the final solution go ahead and download my updated v4.master.

Step 1: Right above the closing head tag you want to place the following LoginView snippet.

Why? Because we want to override the body.v4master { overflow: hidden; } default SharePoint declaration but only for anonymous users.

     <asp:LoginView id="LoginView" runat="server">
               <style type="text/css">
                    body.v4master { overflow:auto; }

Step 2: Remove that pesky scroll=”no” on the body tag.

Why? Because if we don’t then we will not be able to scroll on IE7.

Look for this:

<body scroll="no" onload="if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();" class="v4master">

And replace with this:

<body onload="if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();" class="v4master">

Step 3: Hide the Ribbon Control so it only appear when the user has the ability to add or remove personal Web Parts on a Web Part Page.

Why? I do not want the ribbon control to load unless the user is logged in. I tried using the AnonymousTemplate logic above but it created some other issues which will be a follow up post.

Security Trimmed Control, Permissions … What? Yeah I thought the same thing the first time I discovered this control. You can read more about the different built-in permissions available in SharePoint Foundation over here: SPBasePermissions Enumeration. It’s worth your time to take a look.

Look for the id=”s4-ribbonrow” and include the SharePoint:SPSecurityTrimmedControl above it:

<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="AddDelPrivateWebParts">
     <div id="s4-ribbonrow" class="s4-pr s4-ribbonrowhidetitle">
          <div id="s4-ribboncont">

Now to close the tag look for the closing #s4-ribbonrow div tag, and add the closing SharePoint:SPSecurityTrimmedControl tag.

                         <asp:PostBackTrigger ControlID="WebPartAdder" />

Step 4: Only display the the #s4-workspace div if the user is logged in.

Why? Because through JavaScript SharePoint adds an inline height and width to this div that is then referenced in their scrollbar JavaScript code. In my solution I did not need, or want it, for Anonymous visitors.

NOTE: The opening and close #s4-workspace divs will now appear yellow because the MasterPage will not be able to see that they are in fact matching tags. Do not worry though because once the page renders for the visitor, everything will work just fine.

Search for div that has id=”s4-workspace” and replace it with the code below.

<asp:LoginView runat="server">
          <div id="s4-workspace">

Search for the closing #s4-workspace div and replace it with the code below.

<asp:LoginView runat="server">

Step 5: Download my updated v4.master with all the changes described above.


While this solution worked for my scenario, I obviously can not promise it will work for you. I did notice one issue of a double scroll bar if a content author accessed the the site using IE7. This particular authoring scenario was not a requirement and the client agreed it was an acceptable trade off.

I also wanted to thank the people that took the time to create their own tutorials that helped me with my own solution.



2 Comments  |  Make a comment

Leave a Reply

Required fields are marked *. Your email will not be published or shared.