This post is over a year old, some of this information may be out of date.
New SharePoint versions can be challenging, especially when it comes to branding your sites. When you are in a migration process like me, you will probably have to re-do the branding to support the new functionalities. Assuming that everything will work like before can be really disappointing. There are a lot of new functionalities, which means that your design will also need to support these functionalities.
One of these new functionalities with which I had trouble branding, were the search hover panels.
When I was testing my design, everything was working fine in Internet Explorer:
But when I opened the site in a non IE browser, the following happened:
Note: these screenshots are just created for proving my point. Of course this was not the design I was working on, but the same thing happened.
As you can see, the hover panel is not where it has to be positioned.
The design was made with a couple of elements that were absolutely positioned. So the first thing I thought about was that it had something to do with that, but it was working fine in IE, so that was the weird thing.
This file can be found in the SharePoint root layouts folder:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS.
The function that is used to show the hover panel is showPopup, and this function invokes the positionPopup function. While debugging the positionPopup function, I saw that I retrieved different values for IE in comparison with firefox. When I dug deeper in the code, I stumbled on something interesting in the getAbsolutePosition function (this function was called from within the positionPopup function).
The getAbsolutePosition function looks like this:
_Note: this function loops over each offset parent element until it finds an absolute positioned parent. If no absolute positioned element is available, it will stop when there is not offset parent anymore. _
The problem I discovered was on line 6. When debugging in firefox, the debugger never entered the “IF” statement, which was not the case for IE.
Taking a closer look at the targetElement object in firefox, it never contained a currentStyle object. A quick search on Google revealed the problem. The currentStyle object is only available for IE and Opera.
The same “IF” statement is also used in the isInAbsoluteContainer function.
The solution is to append the following code to the getAbsolutePosition and isInAbsoluteContainer functions:
The updated code for the getAbsolutePosition looks like this:
The updated code for the isInAbsoluteContainer looks like this:
The best approach is to create a copy of the searchUI.debug.js file and make the changes is the copied file. Upload this file to the master page gallery of the site, and reference the script in the master page like this:
The end result should be the same as in IE.
Note: this is a bug/problem that is present in the RTM version of SharePoint 2013. This could be resolved in the final version, but I don’t know.
Here you can download the new debug and minimal script: