In IE (7 or 8) and HTTPS mode, following RESPONSE is delivered for an AJAX request. My issue is the img was NOT requested at all by IE (figured out using Fiddler), broken img is shown instead. It all works perfectly in HTTP mode in IE and other browsers no problem rendering in both mode (please don't tell me not to use IE). Any thoughts/work-arounds/suggestions? Thanks.
<div>
<h1>Chart Title</h1>
<h2>Chart sub-title</h2>
<img src="https://www.google.com/chart?cht=p3&chd=t:106,169,73,14&chds=0,169&chs=300x150&chtt=Ocean+Area&chdl=Atlantic|Pacific|Indian|Arctic&chma=0,0,0,0|70&chco=3366CC|DC3912|FF9900|109618&chp=4.7">
<p>message comes here</p>
</div>
It might be worth checking that this isn't being caused by a corrupt DOM: try closing the img tag in the AJAX response and see if that helps.
Related
I have a html structure like this
<html>
<body>
<iframe srcdoc="HTMLDOC"></iframe>
<body>
</html>
where HTMLDOC is a HTML doc which has some <img> tags that show images in my server that the user must be authenticated to see.
This works flawlessly on Chrome, but when trying on Firefox the requests made from the browser to fetch these images do not send the user's cookies, and thus the images are not downloaded, (since the server thinks that the user is not authenticated).
If I convert the iframe to a "classic" iframe, like this:
<iframe src="URL INSIDE MY SERVER"></iframe>
where URL INSIDE MY SERVER is an endpoint that serves the same HTMLDOC it works both in Chrome and Firefox, sending the appropriate cookies in the requests to fetch the images.
I've tried as well to add the parameter sandbox="allow-same-origin allow-top-navigation allow-scripts" to the iframe using srcdoc, to no avail.
What's weird is that if this is a same-origin situation I can't think a clearer same-origin that having the page in the HTML itself, so I don't know if I'm missing something.
I'm not sure whether the implement differences between Chrome and Firefox are, but I use some DOM manipulations to bypass this issue:
<html>
<body>
<iframe onload="fillIframe(this);"></iframe>
</body>
</html>
<script type="text/javascript">
function fillIframe(o) {
o.contentWindow.document.body.innerHTML = "HTMLDOC";
}
</script>
I was debugging my web app using DevTools when I noticed that Firefox is requesting url defined in src attribute of an img that is located inside a HTML5 template tag, while Chrome doesn't.
I'm using the last version (50.0).
Is this a bug?
Example below:
<template id="object-img">
<div class='object-container'>
<div>
<img src="cacaca.jpg" class="img-responsive" alt="imagem" />
</div>
</div>
</template>
It's a kind of optimization from Firefox.
The image is requested only the first time if it is not already in the browser's history / cache. Subsequent reload of the page won't trigger the request again.
The problem is that the image inside the <template> is requested before the following but normal images in the rendered DOM, which could be counterproductive in some situations. A solution is to put the <template> after the other images.
Note: the template specifications state that the elements in the template are not rendered, but they are parsed. They say nothing about preloading of referenced resources.
I have a page with a container that gets different content from an ajax request. This content has a form that posts data (and a file) to an iframe that is also in this ajax content container. I can submit the form and it works perfectly in Chrome, but Firefox and IE just sit there like I never clicked the submit button. I have default security settings on each browser, and don't want to change them for this functionality. Can anyone see any bugs in my code or process that would cause this? thanks in advance!
form:
<form action='processUploadFrame.php' method='post' enctype='multipart/form-data' id='myForm' target='iframeUpload'>
<input type='submit' value='Upload' />
iframe:
<iframe name='iframeUpload' frameborder=1 width=750 height=150></iframe>
Solved. My HTML 101 has failed me. Having my submit button in a different table cell than the rest of the form doesn't work in IE and FF, but Chrome is okay with it. Strange. A simple javascript submit link did the trick:
<a href='javascript:document.getElementById(\"myForm\").submit();'>Submit</a>
Here's an article that reminded me about the rules of such: http://www.cs.tut.fi/~jkorpela/forms/tables.html
I am using Knews plugin for subscribing to my website. Everything is working except IE8: in IE 8 error or success message is not showing. I think since this is an AJAXed form I am getting an AJAX response with some unnecessary HTML tags.
Please see the screenshot. I provide this in the backend:
<span class="error_subscription">Please check e-mail Address</span>
But I am getting the response as on the screenshot:
<span class="error_subscription">Please check e-mail Address</span></p></div>
gog.com has a HTTP site (http://www.gog.com/) and a HTTPS site (https://secure.gog.com/).
When I visit the HTTPS site in Firefox, the Login/Sign-up link is visible:
When I visit the HTTP site in Firefox, the link is missing:
But when I visit the HTTP site in Chromium, the link is visible:
So gog.com doesn't seem to hide the login link in general on HTTP. In fact, if I disable the CSS, I can see the login form on the HTTP variant on Firefox, too:
I contacted the gog.com support, but they were not able to reproduce it.
I tested it with three different Firefox installations on different systems, and I never saw the Login/Sign-up via HTTP. Is it only me?!
I checked the source code with Firebug. For HTTP, the relevant part seems to be:
<div class="nav_user">
<div class="nav_empty not_logged"></div>
</div>
For HTTPS, it looks like:
<div class="nav_user">
<div class="nav_link nav_account nav_login" data-hoverclass="hover_acc">
<span class="nav_login_icon"></span>
<span class="nav_text">Login / Sign-up</span>
<div class="nav_hover"></div>
</div>
<div class="nav_cart_h">
<div class="nav_empty"></div>
</div>
</div>
Does someone have an explanation for this? Why does it work in other browsers but not in Firefox?
EDIT: Other things on their HTTP site don't seem to work in Firefox either (but on HTTPS without any problems). For example I can't use the big carousel on the home page: clicking the navigation arrows doesn't do anything, clicking at one game neither.
So all these problems are probably related to JavaScript? Does Firefox have any security features that disallow some functions on HTTPS or something like that?
For whatever reason, gog.com requires local storage for HTTP (but not HTTPS).
So the about:config setting dom.storage.enabled needs to be true.
(Similar problem with JS on anime.stackexchange.com and japanese.stackexchange.com)