Global Search reverts back to Classic Search

Brian_Winter

When a user goes to a New Page with widgets (HTML, OData, what have you), the old Work Item Search appears MOST of the time (not 100%). A <ctrl>F5 will return the Global Search. All OotB pages work fine. Navigate away and back (or to another widget page) and Classic Search returns.

1) has anyone else seen this?

2) how can we stop this from happening? (something in our js?)

TIA

Brian_Winter

Hi @Simon_Zeinhofer ,

Sorry to have taken so long to get back to you on this problem. We did, in fact, solve this problem by making sure there is no caching in IIS. While there was some talk about a performance hit, we didn't notice anything significant. So, in IIS, go to your site, then open the HTTP Response Headers. We have these 5 entries:

Cache-Control no-cache, no-store, must-revalidate

Expires 0

Pragma no-cache

X-UA-Compatible IE=edge

X-XSS-Protection 1;mode=block

Brian_Winter

Found out that this error is popping up on any "Page" url. Looking at with Dev Tools, I see the error:

Uncaught Error: The onElementResize binding is not supported by the div element
 at init.applyBinding (kendo.all.min.js:30:5079)
  at init.bind (kendo.all.min.js:30:4605)
  at a (kendo.all.min.js:29:17188)
  at Object.s [as bind] (kendo.all.min.js:29:17507)
  at 374b746c-eee6-4e1e-9309-35d6714f004c:1455:15
  at Object.success (app.js?v=1170:1292:26)
  at c (jquery.min.js?v=1170:2:28294)
  at Object.fireWith [as resolveWith] (jquery.min.js?v=1170:2:29039)
  at l (jquery.min.js?v=1170:2:79800)
  at XMLHttpRequest.<anonymous> (jquery.min.js?v=1170:2:82254)

Ironically I have to open Dev Tools after the problem raises it's ugly head. If I have Dev Tools open, then the problem doesn't happen! Go figure 🤷‍♂️

Simon_Zeinhofer

@Brian_Winter As we rebuilt most of our Views to dashboard queries, I came across the same problem (but here it also happens when I have dev tools already open :D )

My custom scripts inside the custom.js are not working either, when this error occurs.

When you press f5 it is sometimes working again, sometimes not.

Simon_Zeinhofer

@Brian_Winter What I experienced so far:

For me this happens nearly everytime when I am at the home office, but very rarely when I am at the office (internal network)

So when the site seems to load a bit longer (what is the case in home office) the error occurs.

Simon_Zeinhofer

@Brian_Winter have you been able to get further into this?

Since today, it does not happen when we are connected via VPN anymore. As we have not changed anything, I am pretty sure it was something getting blocked by our VPN system.

I will ask our infrastrucrture team about it and will keep you updated - maybe this will help you as well :)

Brian_Winter

Hi @Simon_Zeinhofer ,

Sorry to have taken so long to get back to you on this problem. We did, in fact, solve this problem by making sure there is no caching in IIS. While there was some talk about a performance hit, we didn't notice anything significant. So, in IIS, go to your site, then open the HTTP Response Headers. We have these 5 entries:

Cache-Control no-cache, no-store, must-revalidate

Expires 0

Pragma no-cache

X-UA-Compatible IE=edge

X-XSS-Protection 1;mode=block

Simon_Zeinhofer

@Brian_Winter did you have the problem everytime, means also in the office, or just under certain circumstances?

In our scenario it only happened when we were connected via VPN. Now our infrastructure team told us they didn't change anything - So, I really don't know why it is working now :D

Brian_Winter

@Simon_Zeinhofer, we found it was happening on a person's first visit to any url with "Page" in it, such as custom pages. A second visit and Search was the way it was supposed to be. It didn't seem like it mattered whether we were at the site or remote.

Thanks to @Brad_Zima for helping uncover the caching issue!

Simon_Zeinhofer

@Brian_Winter Ok so I guess for us it was a different issue, because it didn't matter how often we visited the same page, 90 % of the time, the error occured.

Is this something you have to reapply after every update, or are the settings reapplied automatically?

Brian_Winter

@Simon_Zeinhofer This was a one-and-done. Once we entered those values and restarted the site, we haven't seen the problem since.

Simon_Zeinhofer

@Brian_Winter sry my question was misunderstanding, I meant when you update your portal version, is this setting sustained or do you have to recreate it after every udpate?

Brian_Winter

@Simon_Zeinhofer I understood. It is persistent from upgrade to upgrade. In addition, version 11.6 onward, ALL IIS settings are persistent.

Simon_Zeinhofer

@Brian_Winter ok, was just asking because our url rewrite rule (so everytime a user wants to navigate to out portal via http, it will be rewritten to https) has to be added after every update as the web config file gets replaced.