I have an HTML form that contains regular inputs as well as a file input. When a user selects one or more files to upload, I instantly change the target attribute of the form to the name attribute of a hidden iframe on the page as well as change the action attribute of the form to the script that I want to send the file-upload request to.
From the requested script, I then upload the files to the server, and once the script ends, the onload event for the iframe fires, after which I make various interface changes.
Everything uploads correctly, but the problem is that the iframe request seems to cause a page request to be added to the browser history, which creates unintended consequences. I have currently found the following two issues:
If I upload one file and then right after that another file, and then
hit the Back button, the browser stays on the form instead of going
back to the page displayed before the form.
If I upload one file and then hit the
Back button, the browser corrects goes back to the previous page,
but if I then hit the Forward button to go back to the form, for
whatever reason, the script that is executed in the iframe to upload the files is immediately called upon the form loading, which causes other unintended side effects.
Point being, it seems like the iframe request being added to the browser history is causing all sorts of problems, and I'd like to avoid this if possible. Is there any way to stop this all from happening?
I should also note that I'm currently only developing in the most recent version of Chrome, but whatever solution I use must work back to IE8.
Below are some explaining refer to your bug
Rerendering components with iframe leads to browser history duplicates
The navigation events of the iframe (change its src attribute in this case) are propagated up to the parent window as well.
Here is a full demo and explaining of this weird bug. Back Button Behavior on a Page With an iframe
3-reasons-why-you-should-not-use-iframes
Reason #2: iFrames cause usability issues
The iFrame tag is notorious for creating usability annoyances. Among most common of them are:
* it tends to break the "Back" button in the browser being used;
* it confuses visually impaired visitors, using screen readers;
* it confuses users, suddenly opening the iframe content in a new browser window;
* content within the iframe doesn't fit in and looks odd because it can ignore the styles sheets from within the main website;
* content within the iframe is missing since the source URL changed; and,
* navigation of the site in the iframe stops working.
I figured out the problem and a solution. The problem was that I had an iframe on the form page when the form was first loaded and somehow (I don't know why) that was causing the problem described above.
However, I decided to remove the iframe from page-load, and instead dynamically create an iframe via JS when it was time to upload files. Once the files were uploaded and the iframe onload event fired, I then removed the iframe from the DOM via JS and it no longer caused the problem occurring above.
I'm honestly not too sure why that fixed the problem or if it's just a potential issue with browsers, but all the same, for anyone that wants to use an iframe to upload files on a form without reloading the page, be sure to not have the iframe on the page when it first loads, and instead dynamically add the iframe only when you need it and remove it when you're done.
Related
Doing some Intranet development. The design approach uses a basic HTML framework populated with an ajax call (via jQuery) to populate the page. We've standardized on Chrome for Intranet access. The intranet allows the user to open PDF documents linked from the page in the same window, and then use the back button to return. Our old "static" page approach retained the prior page contents - the new dynamic approach reloads the page. How can we retain prior page content?
Research has found similar problems, but not a clear answer. We've tried checking for an existing element in the onload() event; doesn't work because the page load is already triggered before that code gets evaluated.
The code is working correctly - our desire is to return to the already rendered page.
No errors. Getting page reload with the back button when we want to return to the already rendered prior page.
You could modify the url via the history api when you are changing the page content. This should be enough as history gets modified so the back function would work properly. However if this doesn't work you can use the url to determine what to show up on the page.
Here's an example: https://css-tricks.com/using-the-html5-history-api/#pushState-example
Good day,
I have taken over a Drupal site that uses iframes for the main content area. I have a minor issue that I'd like to correct.
When a user clicks a link to a page that has a lot of content, then uses the browser's back button to navigate to the previous page, the old content appears, but the iframe's src does not change. I'm using some javascript to set the height of the page dynamically, so when the previous page has less content, there's a huge amount of empty space between the content and the footer.
Here's a diagram that hopefully illustrates what I'm working with:
So upon returning to the previous page, via the browser back button, the footer is pushed way down below because the source has not changed, and therefore the page isn't rendered again.
I've not really used iframes because they aren't great to work with. I'm wondering, is there a way to force the source of the iframe to change when using the browser back button?
Part of my extension involves accessing a webpage and then programatically performing certain functions for the user. The app would obviously be much cleaner if the user did not have to see all this happening in a browser window.
In some situations this could be achieved by, displaying other content (useful to the user) in a browser window, loading the screen with the programmatic elements in an iframe and manipulating them through an action script that triggers on the page load of the page loaded in the iframe.
However, for my purposes this is obstructed partially by the cross-domain limitations and totally by the fact that site in question does not allow iframes.
(One solution was to reverse this process--i.e. direct the browser to the correct page and throw up the useful content in front of it, thereby hiding the noise while loading the page in the browser. This works but it is horrible for obvious reasons)
Is there any clean way to either:
Open a chrome window but keep it hidden?
or
Load a page (i.e. have a DOM built etc) without doing so in a window/tab?
Have you tried using
chrome.windows.create({url:yourUrl, focused:false, state:"minimized"}, function(hiddenWindow){
//do whatever with hidden window
});
or having an <iframe> in the background.html of your extension?
I'm using a form handling service which after hitting submit links to an intermediate page before using setTimeout() to link back to my original page. I would like to cover the ugly intermediate page with something nicer. So far I've tried having the submit button load a new window onClick, where the new window uses parent.write to open a div that would cover the entire page and allow me to write my own html. The problem with that is that it prevents the intermediate page from loading at all, and thus prevents my forms from being processed.
My current workaround involves using setTimeout() in the child window to load my own page immediately after the intermediate page is loaded. It works, but I still see the intermediate page first.
Please help me!
switched to 000webhost and wrote my own formhandler
This is a very urgent problem and I'd be forever indebted to anyone who can lend some insight.
I'm going to be deploying a widget (called the "ISM") to a third-party site. That site uses the document.domain JavaScript property to relax cross-domain restrictions (e.g., setting document.domain in "a.example.com" and "b.example.com" to both "example.com" so they can access each other's DOMs).
This causes problems with my script in Internet Explorer due to the way that I construct an <iframe> that is used to display my widget's HTML content. In Internet Explorer, using document.domain on a page, and then creating an <iframe> with JavaScript, will cause you to be immediately "locked out" of the <iframe> - i.e., you can create it, but it's not created in the correct document.domain, so you're not able to access its DOM due to security restrictions. This isn't a problem in any other browser.
To see what I'm talking about, load this page in IE:
http://troy.onespot.com/static/3263/stage1.html
You should see a JavaScript error: "Access is denied."
To get around this, I'm setting the dynamically created <iframe>'s "src" attribute to load a static HTML file that's hosted in the same domain (different subdomain), and setting its document.domain property to the appropriate value:
http://troy.onespot.com/static/3263/stage2.html
That gets around the security issue, and lets me write the document I originally wanted to write to the <iframe>:
http://troy.onespot.com/static/3263/stage3.html
With that document in place, my widget does some polling to our server to get some HTML content that I want to insert into another <iframe>, which will be visible to visitors of the parent page. I've roughly simulated that here (using static content, not actually contacting our server):
http://troy.onespot.com/static/3263/stage4.html
Here comes the problem. When I get that HTML content and insert it into the second <iframe>, I now face an unusual issue with a broken "Back" button. This happens in Firefox 3.0 and all version of IE (possibly other browsers), though it does not happen in some browsers I've tested (Firefox 3.5, Safari, Chrome). See this page:
http://troy.onespot.com/static/3263/stage5.html
If you click the "Google" link, all seems fine. But, when navigating back to the previous page (that has the latter test script), another JavaScript error is introduced: "Permission denied." This does not terminate the script, and does not appear to have any ill effects, other than the fact that I assume it's connected to the broken "Back" button functionality, which is a very big problem - the one I'm desperately trying to solve. I'm at a loss to debug this error since its call stack starts and stops in the jQuery script.
You can also encounter this error - with more serious symptoms - by going to the last link above (stage5.html - clear your browser cache first). Click the "Stage 5 (Again)" link, then, after that page has loaded, click the "Back" button.
The "Back" button is completely broken! You can't go anywhere except to another URL.
This is the problem that I need to solve as soon as possible. Any insights or help would be extremely appreciated!
I can't deviate from this method too much, so outside-the-box suggestions are definitely welcome, but I may not be able to use them due to the constraints of the widget's specifications. I would prefer to understand why the "Back" button is breaking and how to fix it, along with the "Permission denied" error related to jQuery.
It's really hard to try out fixes for this because of the multiple domains. One thing I've heard is that IE treats a blank src or "about:blank" as a different domain, but it treats 'javascript:""' as the same domain. Have you experimented with changing stage one to set the iframe src to things like:
iframe.src = 'javascript:""'
Or:
iframe.src = 'javascript:parent.getFrameHTML()'
Part of the problem seems to be that IE (at least IE 7) adds two entries to the history named "Domain" when I click on the "Stage 5 Again" link. When you use the little drop-down arrow next to the Back button you'll see the history of pages allowing you to step back more than one step. I see the previous two entries are listed as "Domain" and clicking either of those brings me to the same page. The fourth spot (after Current Page, Domain, Domain) is the correct "ISM Back Button" link to the original stage5.html page.
So the problem isn't exactly that the back button doesn't work, but just that the entries in the history are added and so the back button takes you to the wrong place. I don't have an answer as to why those "Domain" entries are being added to the history, but hopefully this helps point you in a useful direction.
Good luck!