I am using YUI treeview to show some hierarchical structure.The problem is that even when I delete some nodes from back end and then refresh the whole tree it does not reflect the changes done on back end.(i.e If I remove a certain node from database and then refresh the page containing the tree view it still shows the deleted node in tree.)
Ironically this issue is just specific to IE 8 and 9.I dont face this issue in chrome and firefox.
is there a way to solve this problem?
The problem might not be TreeView but too aggressive caching by the browser. IE is known to do that. With the debugger, look at what information was actually transferred from the server. In the refresh, the browser might be actually reading the data from its own cache. If so, the problem is not YUI's. After all, it works in other browsers.
Related
I feel like this should be really easy to find if it exists, but I've been googling for 10 minutes. I don't see it mentioned in the official documentation.
I'm trying to troubleshoot a solution to a problem. The solution requires rearranging the order the head child elements.
It's trivial to make that change with Firefox devtools, but I don't know how to view the page with those changes; if I reload (ctrl+r), the HTML goes back to the server version. Does this feature exist?
FWIW, I can find ways of doing this for CSS and JS changes.
There is currently (as of Firefox 92) no such feature of re-applying HTML changes.
What I found is a feature request in Mozilla's bug tracker.
At the moment, the only workaround for this is to directly transfer the changes on the server side script creating the HTML output once you've done them in the Inspector.
Note: It requires some heuristics to re-apply changes to HTML in the browser because the resources served over the network could change in the meantime.
For CSS, the simple DevTools solution is to replace a file entirely by the saved one. For JavaScript, they have some heuristics to recognize where a line moved when code has changed between two reloads. Though those solutions cannot be transferred to HTML easily, as it is generated dynamically most of the time.
Ok; I'm stumped on this one. This regards the built-in draggable sort functionality you use for basic blocks or organizing books. I'm using the latest Firefox on Fedora 20. I also use profiles, meaning different instances of Firefox with separate caches and add-ons. However, in both profiles, I am logging into my Drupal site with the same credentials.
The Problem: For the last few days my primary browser has suddenly stopped showing the draggable handles in any primary Firefox profile. Inspection of the code shows that they are receiving a "display: none" element style in every case. However, this is happening only in one of my Firefox profiles. If I could even duplicate the problem in my other profile I'd have some clues, but I can't get them to disappear there any more than I can get them to come back in my primary. Remember, I'm logged into my Drupal site as the same user in either case, so it shouldn't be a permissions thing.
Things I've tried so far:
disabling all add-ons
Clearing all memory and caches. Again, and again, in conjunction with everything else I've tried
Clearing all Drupal caches
Force-refreshing the pages (shift+r)
You can see the problem here; it's not even a stylesheet thing, but something effecting generation of the drag-handle elements to apply a "display:none" to them.
See my firebug comparison screens attached.
EDIT I "cloned" my profile by creating a new Firefox profile and syncing everything (addons, history, etc); the new profile does NOT have the problem.
After clearing my cookies (a separate operation from all the cache clearing), it was fixed. I am still perplexed by why there should be a cookie with the power to toggle draggable blocks, but there we have it.
Solution: Clear Cookies
My app for the iPad shows PDF-files by using a UIWebView. But sometimes when I click on several pdfs in a row, the first page of a pdf is blank suddenly. When I reopen the same pdf a second time, the first page is normal again. This happens from time to time and is not just linked to a specific pdf file.
Any ideas or did you had similar issues? Solutions? :/
Thanks in advance!!
Without seeing neither code, nor the PDFS, I would bet for a memory related issue, since you say this happens when showing several PDFs in a row. Indeed, UIWebView is highly optimized as to memory usage and keeps in memory only relevant parts of the page, so it could be that somehow your first page is unloaded.
You can check if this is the case by adding some NSLog traces to didReceiveMemoryWarning in your app delegate. If you see the trace logged just before the blank page issue appears, then this would be a hint that it might be a memory problem.
If my hypothesis is right, then a fix would be forcing the web page to refresh its content. Or you might try a workaround just to make this particular use case (quickly moving through multiple PDFs documents in a row) work. In both cases, I would need more detail to suggest any possible implementation.
This is driving me crazy. This website and its pages work perfectly in IE, and Chrome but in Firefox 5.0 it frequently won't load the belts and bags page and the only way to get it to load is clear my cache/history.
http://www.urlgone.com/0ad9a6/
If you click around four times on the Bags link, then the belts link, then the Bags, then the accessories link it usually won't load. Another testing process is when you click Belts or Bags twice each then hit refresh it gets stuck and never loads or eventually after a long wait does. It seems to do this on either Belts or Bags but its
not always the same page that has problems.
Can anyone give me a clue what the problem is?
I figured the problem out. Its more specific to my individual situation i guess. I thought maybe my problem was the word press include header file but I was wrong. It appears to be permalinks. I changed my perma links to default and it worked. Next I did a restart with Firefox in Safe Mode using pretty permalinks (not default) and it worked fine. So ultimately the problem in Firefox is an add-ons in combination with the permalink somehow. I found the culprit add-on is HTML Validator 0.9.0.6. I'm not sure why this is the problem but appears it is.
I'm developing a web application where, due to slow database access, not all content in a page is loaded immediately but rather dynamically when the user clicks a button after optionally making a selection.
This works fine. However, after dynamically loading content, if I navigate to a different web page, then navigate back, in Internet Explorer the loaded content will have disappeared, i.e. the page will have reverted to the originally retrieved page. In Firefox (and Opera as well), however, the loaded content will still be there, i.e. the page will look like it did before I navigated away from it.
The Firefox behaviour is the desired behaviour in my case, as the user would routinely navigate to subpages and go back to the main page. My question is therefore, is there any way I can force Internet Explorer to exhibit this behaviour, or are there any possible workarounds to get the desired result?
Here is my workaround solution for IE. It utilizes the fact that, even if the DOM is reset when navigating away and back to a page, input field values are still remembered.
For every dynamically loaded element, I also have a hidden input field where I "cache" the loaded value. I then have a function transferFromCache() which copies the values from each hidden input field to the corresponding element. This function is run at page init - which, in IE's case, is at page load AND every time one navigates back to the page.
This technique could probably be used to store the values of javascript variables as well.
I don't think there's a method to get IE to emulate FF in this manner. The reason is to do with fairly fundamental aspects of the browsers. FF uses a mechanism for it's page history called 'Fast DOM caching' which (from my limited understanding) basically means that when it puts a page into the browser history then it will store the current DOM (so the current page state) in a serialised format, which means that when the page is reloaded from history the state is preserved and FF can do this much quicker as a lot of work is already done (parsing the HTML into a DOM, etc). In comparison, IE will simply store the HTML received initially as it's history file and will reload it when navigating history.
Here is an article about saving state in session variables, which may help