Tag Archives: Javascript

Sharepoint 2013 – some thoughts about sticky footer the sharepoint resize event and DOM breakpoints

Lately on a SP 2013 project where we had a sticky footer, we were facing a problem lots of people currently face: SharePoint calculates the height (and width by the way) of the s4-workspace div based on the window object size.

It means that the workspace does not consider the footer, and when the content needs a scroll, the scroll is hidden behind the footer.. not cool :|

After spending some time and hitting the wall, I got a solution that’s not too ugly..

1st try
Add an event listener to the window resize event and subtract from the s4-workspace height the height of the footer.  And it worked…. for a second only.. then the SP event that recalculates the size would override it again. It was a dead end.

2nd try
It become obvious that I needed to understand what method was being called by SharePoint to calculate the sizes. But I didn’t find a way to see all the event listeners attached to the window element.

Then I looked at the problem from another angle. What do I know?

I know SharePoint is changing the size of the s4-workplace div. How can I find where and how does he do that? The answer is the DOM breakpoints.

Using Chrome developer tools, I selected the s4-workspace div and the selected “Break On…”, “Attributes modifications”:

dom breakpoints

Then I resized the browser window and the code stopped on the exact spot where a modification for the workspace div attributes was operated. The function happened to be on the global scope, and the only function on the call stack:


So now that I know that the name of the function that SharePoint uses to calculate the size of the workspace div, I can remove the height of the ribbon. I did it by saving the original function to a variable, and replacing the function with a new one that calls the original one and right after removes the footer height from the workspace div:

var originalResizeFunction = FixRibbonAndWorkspaceDimensions;
FixRibbonAndWorkspaceDimensions = function()
    //let sharepoint do its thing

    //adapt to the footer size (assuming  #footer is the footer element)
    $("#s4-workspace").height($("#s4-workspace").height() - $("#footer").height()

Remember to call this script after the init.js of SharePoint is loaded. Do it either at the end of the DOM or use the ExecuteOrDelayUntillScriptLoaded method.

Now the workspace adapts perfectly to the footer and the scrollable content does not hide behind it.


[Javascript] – Parsing integers with trailing “0” with parseInt

We are always learning, sometimes not the best way :)

As most of the times, when I develop in JavaScript, I end up using the chrome debugger as it’s lighter than its IE counterpart.

On a project, I had to retrieve some dates from DOM elements and process them, place the elements in the proper position.

The dates were on the following format: “MM:YY”. It means that February is “02” and September is “09”.

While on chrome the parsing of those texts were ok:
parseInt(“02″) -> 2
parseIng(“09″) -> 9
on IE9 and IE11 they were inconsistent:
parseInt(“02″) -> 2
parseInt(“09″) -> 0

Apparently parseInt works in OCTAL mode by default when the string starts with a “0”. Since in octal mode 8 and 9 don’t exist, it returns 0, for IE 8 Document mode.

Like it or not, it is designed like that, when you use IE 8 Document Mode (which you necessarily use for sharepoint 2010).

JsBin (set your browser to IE 8 Document Mode and ignore the JSBIN javascript errors caused it causes):

So, it’s necessary to force the decimal mode:
parseInt(“09″,10) -> 9

So from now on, I’ll always specify the decimal mode, just in case.

[Windows 8] [Workaround] – Javascript runtime Error: Object doesn’t support property or method ‘itemFromDescription’

Lately I’ve been playing with the Windows 8 developer tools, being focused on the HTML5 + Javascript version.

Although the paradigm changes a bit (being a pure OOP developer) I must say I’m well impressed with it.

The labs are a great place to start, and will provide a general knowledge of the main features of the windows store apps.

One of these features is the semantic zoom. While I was trying to use it on a experience project of my own, I got the nice exception “Javascript runtime Error: Object doesn’t support property or method ‘itemFromDescription'” when zooming out.

When zooming out, the position of each item will be retrieved. The action happens on the ui.js file:

                if (typeof key === "string" && this._dataSource.itemFromKey) {
                    itemPromise = this._dataSource.itemFromKey(key, (this._isZoomedOut ? {
                        groupMemberKey: item.key,
                        groupMemberIndex: item.index
                    } : null));
                } else {
                    var description = (this._isZoomedOut ? item.groupDescription : item.firstItemDescription);

                    if (WinJS.validation) {
                        if (description === undefined) {
                            throw new WinJS.ErrorFromName("WinJS.UI.ListView.InvalidItem", strings.listViewInvalidItem);

                    itemPromise = this._dataSource.itemFromDescription(description);

If you look closely, you’ll see that if the type of the key used for the group is not a string, the fallback will be the “item.groupDescription” (zoomed out) which obviously can be undefined (depending on the group object structure).

The workaround is to convert the group key to string:

var groupedItems = list.createGrouped(
    function groupKeySelector(item) {
         return item.departmentId.toString();

And that’s it. It doesn’t solve the problem, but it goes around it.