In Firefox if the window.location of an iframe is changed, this gets populated to the history of the top level window.
If the user now clicks the browser back button, the contents of the iframe will change rather than the browser going back to the previous HTML page.
This is totally wrong for some architectures.
Is there any way with JavaScript to prevent Firefox (3.x) from doing this?
(Please stick to just this question, not why/when/how iframes versus other techniques should be used.)
Use .location.replace
I have the same issue and was researching possible ways around it when I read this. I don't know if you solved the problem, but I think I'm going to use the unload event in the IFrame'd window to notify the parent window when it's unloaded.
If the iframe is closed by a 'valid' method, a variable is set at the parent to say the iframe is expected to unload
If the parent reloads / changes the src of the iframe a variable is set to say the unload is expected
If an unexpected unload happens in the iframe I assume it was the back button and update the parent page accordingly (e.g. jump another step back in the parent's history, or do something else).
The only ugly case here is if the parent page is unloaded and the iframe also throws unload - depending on how quickly the parent page changes you might get a race condition where the parent's iframe unload handler is or isn't fired.
Related
I'm trying to integrate CKEditor in a page of a SPA (Single Page Application).
CKEditor behaves correctly within the SPA page on the first visit, but not on next visits. For example, when pressing the backward browser arrow (to display the previous SPA page) and then the forward arrow (to display again the SPA page with CKEditor), CKEditor appears but the content has been erased and it's not reacting anymore. There is no carret when cliking on the text area. Also all API calls (such as setData() or resize()) have no effect anymore (whereas they were working on fist visit).
I presume CKEditor doesn't like its element to be removed from the DOM (that's what happens when switching to another page) and then be re-added to the DOM (that's what happens when visiting the page again).
EDIT ON July 5 2017
Thanks for your proposition to destroy CKEditor when leaving the page and to recreate it when navigating back, but this causes the lost of the editor state such as the the scrollbar position, the caret position, text selection, etc...
Ideally I would like to make it possible for a user to visit another page while he is in the middle of writing something in the editor (for example to check an information or copy a content from another page) and then to continue exactly where he was (no change on scrollbar, caret, selection,...) when he navigates back to the editor.
Is is possible?
Removing CKEditor just by removing its parent container like in your fiddle is not a good solution as CKEditor attaches some listeners to the DOM and by removing the container you are detaching those listeners which are not reattached then.
You should destroy the editor before removing from DOM and then recreate it. Remember that destroying happens in an async manner so to know when it is finished you may listen to destroy event.
Here is modified fiddle using destroy method (without handling destroy event which should be added).
EDIT ON July 10 2017
To preserve the state of the editor (scrollbar position, text selection, etc) between destroy - recreate, state of all this elements should be retained before destroying editor and then set after recreating it. It is doable, but requires some work and quite a lot of custom code.
Ideally I would like to make it possible for a user to visit another page while he is in the middle of writing something in the editor
Since you are creating a SPA application, for the above the better solution will be to use some floating/fixed container in which CKEditor is placed and which does not reload with rest of the page upon navigation (e.g. the same as Facebook chat works).
Also remember that recreating CKEditor takes some time (very short, but it may be still visible) so on every page navigation it will be visible for the user that something is happening with the editor even though its state does not changed.
I have a problem with a component that loads in to a modal window. I am using the Alpha User Points system and it has a component that gives you a full list of yous site's users. It also gives you the ability to order by username, by points etc. If I use it outside of modal window it works fine. If I use it in to modal window, ordering don't work!!! When I put my mouse over table's headers, outside of modal window gives this...javascript:tableOrdering('aup.referreid','asc','');In to modal window I see this...javascript:tableOrdering('aup.referreid','asc','');?ml=1 Using Firebug, I remove this ?ml=1 and it works into modal also!!! So the question is, why in to modal window gives this ?ml=1, what is this? And how will I remove it?
Well here is the answer... I use the Modalizer extension of nonumber.nl. I was loading my component through modalizer's modal box, this is why I had this issue. So, if anyone use Modalizer to popup components and have the same problem with me, just go to modalizer's Plugin Manager, find the option Convert Links inside Window and disable it!!! But, after this, if you want to add link in to modal window and you don't want to show-up the whole front page but only the component or what ever this is, you have to add at the end of the link this &ml=1.
First of all, I had all my buttons which opened the Colorbox using the "ajax" class. That class however caused me many problems:
1-When I open one window, it will appear, when I close it and re-click the same button, it will be loaded twice (so I need to click twice to close)
Is there a fix for this?
What I have done for the moment:
Use iframes; my only problem now is I cant load the other colorboxes that are linked in that iframe. I am using the inline class.
Let me re-phrase that: I click on button "generate" it opens first colorbox with the iframe class. Inside that iframe I have a "generate_2" button which has inline content. Once I click that second button nothing happens. This used to work when I had the first button set to ajax.
What can I do?
thanks!
I had the same problem before. Since JavaScript cannot affect iframes, you must add the JavaScript code inside a script tag in the iframe page itself.
when I close it and re-click the same button, it will be loaded twice (so I need to click twice to close) Is there a fix for this?
I'd wager you are using ajax to open a complete HTML document, aren't you? You shouldn't be doing that. It's not valid HTML to nest one HTML document inside another, and you are causing the scripts from both to be applied to the original document. Each time you load that content, those scripts are being loaded and executed all over again.
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
Aims
I'm trying to let users download a file (myfile.zip in this case) by clicking a button on the page, without them leaving the page - ie the browser must stay on the current page, and leave them in a position where they can continue to use the page, including clicking the button again (should they wish to get a new copy of the file).
I need this to work across all browsers (IE6-8, Firefox, Chrome, Opera, Safari).
Background
Packaged inside the zip is a selection of stuff based on their other interactions (some of which may be partially complete) from the same page (this is all done via ajax) and I don't want them to leave the page as they would lose any unsaved changes.
Add the following header when the download file is served:
Content-disposition: attachment; filename=filename.zip
Most browsers will wait to see what type of thing they are loading before they clear the current page, and if it something that should be downloaded as a file they won't navigate away from the current page (they'll show a Save As dialog in front of the page, which can be dismissed to return to the page).
If however you find that a certain browser does navigate away from the current page, you may try having the link to the download contained in a small iframe, so only that frame changes.
I think it's a better solution to opening the link in a new window, because some browsers will leave the new window up even once it's determined that it is a file that should be downloaded, so you end up with a blank window.
If you make the link open in a new window/tab (e.g. via the <a> tag's target="_blank" attribute), it won't disturb the contents of the current window.
The target attribute is deprecated, but widely supported. Depending on the browser, you may also be able to use the CSS3 target-name property.
If your goal is to absolutely guarantee that the main window is undisturbed, this is likely the safest method, as it's resilient against download errors.
To avoid leaving the page (if you do this the page tries to close itself first, so that it's sure that you've saved everything, and you get warning messages if you haven't) or leaving blank tabs (which I don't like, nor the use of the depreciated target attribute) I've used an iframe, whose src attribute is changed in javascript.
This works everywhere except some versions of Opera, which I have considered an acceptable loss (I might fix that via the use of one of the other solutions plus browser detection later).
I believe if you direct the user to a file and the MIME type is something the browser knows it must download vs render, the browser will not leave the page. For instance if you were serving a zip file the browser would know it was a zip file and prompt for download. But if you were going to serve a zip file from a page request (i.e. /file.aspx?file=myinfo.zip) then file.aspx would need to change the MIME type to be "application/zip" before send back the response in order to prompt the user for the download.
One major caveat here is if the file didn't exist for some reason the user would get a 404 and be directed to the error page.
As a sure-fire way of not redirecting the user you could open a pop-up for downloading.
We do this on postback on an aspx page by setting ContentType to "application/octet-stream", then streaming the zipfile with Response.BinaryWrite(..) and Response.Flush().
Gives the user a popup "do you want to open or save" the file.
Page is still available.
By the way, specifying the appropriate content disposition header alone might not work in all browsers. Specifically, I've seen it not work in Opera, and IE7 displays the yellow security warning bar.
In addition to the appropriate header, as described by thomasrutter, The way I've done this is by using a hidden form:
<form id="download_form" method="get" action=""></form>
When the user clicks a button, you can manipulate the "action" attribute of the form with the URL of the file.
This seems to work in all browsers, even IE7!