I have a page that has a RadMenu and a RadGrid used together. The RadGrid is used in client-side mode. This means that the loading, saving, editing and creation of new records is done via ajax. The grid seems to work fine but after sometime it appears that The menu dropdowns tend to be slower and after more use the entire page freezes. I am not sure whether it is this combo that causes this effect or either of the controls since a lot of js is being used to automate the menu dropdown and the ajax calls to the. This is the order in which the error is reproduced.
The menu control is located up above in a separate iframe and the grid is below in a separate iframe. This makes the scenario more peculiar since different js files are loaded in two iframes and there is no interaction between the two.
What could be the cause of the sudden freezing, a memory leak perhaps? Better still could it be a general problem when a lot of ajax interactions occur and other events are fired before the callbacks return?
On the video once can see that when the grid page loads everything seems fine, but after firing some events and performing some actions, the menu starts taking a lot of time to load. It reaches a point that it takes such a long time for the drop downs to display and eventually the entire browser tab freezes.
I have uploaded a video of the effects and here is the link:
http://megaswf.com/simple_serve/87153/
"Better still could it be a general problem when a lot of ajax interactions occur and other events are fired before the callbacks return?"
- that's most of your problem. Telerik's JavaScript is thrown together, just view source and check out how many scripts are on the page, as well as the inlineJS. Contacting Telerik couldn't hurt, but I doubt it'll help. If you have a float based layout, when you go into edit Telerik, the tools don't work because they're relying on absolute positioning. I had to find my own solution. Good luck.
Related
Now this has come up a fair bit on here so I guess I'm looking for an explanation rather than a fix (though that would be ace), but Safari's back / forwards cache is horrifically greedy.
I've got an issue where a form submits, but loads an interstitial modal window before moving on to the form action page. On Safari the cache is so strong that the back button has the modal open still which is making my soul very sad.
I'm hacking around it by dismissing the modal and then submitting the form. On back the browser has a half closed modal (it's Bootstrap so it fades) which then just carries on dismissing.
Now I know about onunload="" but refreshing the page just seems crazy. The cache is a good thing and something you want, specially on mobiles.
I guess my question is:
Why is it so much more intense than say Chrome and is there anyway of forcing the browser to cache a state instead of just the last state?
Thanks
Hah, greedy is an understatement! Honestly though, 99% of the time, the caching design behind Safari is the ideal way to handle page transitions on a mobile device.
When you go from Page A to Page B, and then back to Page A, you don't want to burden the device (bandwidth, battery life) with fetching resources and assets, when you could just "paused" the state between interactions, and then "continue" it when you navigate back.
That's effectively what Safari Mobile does. They use a concept of Page Cache, which keeps the entire page live in memory, when you navigate from one to another. This reduces the need to fetch those resources, and allows for a snappy interaction when clicking back.
That's great and all...but it does lead to problems (such as the one you brought up) - Specifically, how do you distinguish between a page that was suspended and one that should have been destroyed?
Thankfully, WebKit provides a pageshow and pagehide event that tap into Page Cache. In addition to firing when the page shows or hides (similar to onunload), it has the nifty ability to indicate whether a page was persisted - or placed into the Page Cache.
While it's not a perfect solution, you could check the pageshow event for persistence, and then handle the modal more directly (since you know it was cached) like immediately hiding it.
If you haven't already, take a look at these two links here:
https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/
https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/
They do a great job explaining the Page Cache and include code samples of the pageshow and pagehide event I referenced earlier.
Hope this helps!
More specifically, when developing websites/web applications, do you cater for users double clicking on elements that aren't originally designed to be double clicked?
I know this sounds like a slightly off-topic question but it's something I've only considered recently and something I'm genuinely curious about. There are certain users that we all know that will double click on elements in the browser, in fact they pretty much double click anything on the computer to action something. Granted, these people are usually the less experienced - but they are users nonetheless.
I had an issue a couple of weeks ago whereby I was making an ajax request onclientclick of a button. Double clicking the button caused unwanted behaviour, so I've put the necessary checks in place. Which led me to thinking that maybe I should be considering this for all elements on a web page.
Is this something you currently code around?
We have a simple web form for making purchases, it just used ordinary form submission, no AJAX. And we found that some customers were accidentally purchasing twice, because they doubleclicked, or maybe the server was slow and they clicked a second time while waiting. So I put in some simple Javascript to disable the submit button after the click.
I have an C# .Net MVC3 web app. We are utilizing the CkEditor control. We love the control, however we are having a performance issue with it. One of our pages displays a dynamic list of objects. For each row in the list we have two CkEditor text areas. The larger the list the slower our app is. A list of 72 rows takes over a minute and a half to lead. The rendered page has time tags at the beginning and end of the page. The time tags show the page takes 2 seconds to create. The rest of the time is spent on the client rendering the page. The performance degradation is directly proportional to the number of CkEditor controls on a page.
Any ideas? Are we, in our code, loading a framework more than we need to, going out to the web for properties of each control?
The original developer is no longer and I am a novice with CkEditor.
I found an answer. It's not great news, but it's an answer. IE is the culprit. Firefox loads the identical URL's 6 to 7 times faster. The attached article from CkEditor support is what clued me in
CkEditor Support on Performance Degradation
You know how sometimes you are on a good site and you click a button (like to submit a form) and the form doesn't go away, instead, the foreground becomes transparent and it contains a message of some kind, or another page. The message is at the forefront but the previous page is still mostly visible behind it - how do they do that? I'm assuming it's an Ajax-esque trick.
This is called a light box modal. There are quite a few JS plugins that can do this including Lightbox and the JQuery UI Dialog to name a couple. I just recently started using Fancybox and have been very impressed with its speed and configurability.
Here is a pretty good (not all inclusive) list of them:
http://spoonfedproject.com/jquery/extensive-list-of-jquery-lightbox-modal-plugins/
One way is to use GreyBox. I think this similar to the effect that you're talking about.
I have a simple aspx page with some search options which queries an SQLEXpress database, and it is displayed in a gridview.
For some reason, it runs lightning fast in IE but very slow in Firefox.
It has very little code, a gridview a couple of images and a couple of textboxes and a search button. It was done with Expression Web so no additional code added.
In production (not local) the speed is very noticiable when doing a search...
IE displays the results almost instantly...Firefox might take 3-5 seconds.
And everything else runs super fast as well in IE (update, delete etc).
Is there a reason for this ? Thanks
what kind of extensions do you have in firefox? something like fasterfox may be sending multiple page requests
Maybe the problem is with your Firefox Instance, maybe some creepy Add-Ons you installed or maybe you should disable Firebug which causes problems like this.