My book says that the below code will show a message box when I close the browser, navigate to a different page or refresh the page. It does not happen ! Why?
<!DOCTYPE HTML PUBLIC="-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<title>Body attributes</title>
<meta http-equiv="Content-type" content="text/html; charset=ISO-8859-1">
<head>
</head>
<body onload="window.alert('Greetings!')"
onunload="window.alert('...Goodbye')">
<h1>Loaded</h1>
Go to google!
</body>
</html>
If you could run arbitrary code for an arbitrarily long amount of time when closing the page, that could be an opportunity for abuse. I wouldn’t be surprised if older browsers supported it, but new browsers stopped supporting it for security reasons.
If you want to prompt someone whether they really want to exit the web page, you can use onbeforeunload, returning a prompt message:
<body onbeforeunload="return 'I\'ll miss you!';">
Browsers have imposed limitations on what may be executed in an unload event handler. IE 11 still lets you open a new window there, but Chrome and Firefox don’t; they ignore your call to window.alert there. Chrome describes this in the console log: “Blocked alert('...Goodbye') during unload.” This means that there is not much you can do in an unload event handler, even though the event is still created and can be handled.
Instead, you can handle the unbeforeunload event, which is created before the actual unload starts. This event, implemented first in IE 4 and then copied by other browser vendors, has now been defined in the HTML5 spec, clause 5.6.11 Unloading documents. Using it, you still cannot create windows as you like, but browsers show a dialog to the user. The dialog is created by the browser, in a browser-specific manner. You can try to inject your own message into it by making your event handler return it as value, but Firefox intentionally ignores such requests.
<body onload="window.alert('Greetings!')"
onbeforeunload="return '...Goodbye'">
<h1>Loaded</h1>
Go to google!
Related
I'm not really familiar with all the meta allowing you to manage the cache client-side so i tried to make a simple example with the HTTP header "expires"
With the following code:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="expires" content="mon, 18 Jul 2016 1:00:00 GMT" />
<title>MY TITLE</title>
</head>
<body>
MY BODY
</body>
</html>
When i load the page for the first time (cache cleared before). the page is saved in the cache but when i update my body with "MY BODY2" and reload the page, the page displays "MY BODY 2". The browser was supposed to take the page from cache (with "MY BODY") since the expiration is in july 2016, no ?
Thank you for helping me to put some light on this problem
It depends how you reload the page.
You've basically three options:
Browse to another page and then back. This should use the cache.
Press F5 or reload but. This is an explicit reload so will check with the server if there's a new version - even if it's cached - and download it if there's a newer version.
Force reload (Ctrl+F5 in some browsers). This says ignore the cache and download from scratch (even if the cached version appears to be the same as what server will send you).
I suspect you've done option 2 and didn't realise this would check with the server and assumed it would use the cache if still valid. The reason it actually checks with the server is that a reload is often done when the user suspects the content has changed, or wants to re-download it (e.g. If page didn't render properly).
Also it should be noted that meta headers in HTML are not as good as http response headers set up by the server for various reasons including browser support reasons.
And finally it's worth opening developer tools (F12 in Chrome for example) and checking network tab to see what's going on but in that case make sure you don't have "Disable cache" ticked when it's open (it's ticked by default in Chrome as most developers don't want to use a cache when developing).
I need to render an HTML5 page with jQuery in a CHtmlView in an MFC application.
The page renders rather pathetically, and I get a syntax error when it gets to the jquery script tag.
I've tried the following:
<meta http-equiv="X-UA-Compatible" content="IE=11">
It did nothing. I even upped the MSHTML browser version to 11 in the registry and get the same syntax error. I really do not want to go back to IE6-style javascript. Can someone help me please?
Apparently the meta tag does solve the issue. What I didn't realize was that my html view was running in a frameset, and the directive is ignored in a frame of a frameset. Does anyone here even remember framesets? Anyway, adding this line and removing the frameset was the answer:
<meta http-equiv="X-UA-Compatible" content="IE=11">
If you don't set the correct browser Emulation for your application this will not work.
Please read this MSDN article.
So create an entry for your application in FEATURE_BROWSER_EMULATION and set the Version to 11000!
I have a problem that my webpage does not display as i wish it to do.
When opening the F12 developers tool in IE11 it says "Document mode: 8 (Default)".
If i change it to mode 9 or higher the page displays as i want it to do.
My code is included in the host web page through an Iframe. I do unfortunatly not have access to edit the host code. The host code includes the code:
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
I thought this code would ensure that the code was not shown in document 8? The code is included at the end of the head tag, with 88 lines of code in front of it. Could this be what is causing it to use document mode 8? How can i work around this when i am not able to edit the head code?
Do you know a way to disable any message bar (Google translate, ff help bar question,...) that appears when loading a site page?
I have noticed that for some site Google translate is not pop up, although they don't use code as <meta name="google" value="notranslate">? Is there any trick in html code, or is depends of html definition:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
That affect the browser bar?
Well, if a browser company decide to 'freak-out' or what-ever do something beside showing html content, you can't do anything but try another browser. Like, if googleChrome add publicity to their 'software' .. you'd need to 'hack' the software in order to remove components from it.
Some softwares offer 'web' extensions such has microsoft IE
<meta http-equiv="imagetoolbar" content="no"> etc etc..
Search the web for 'browser specific meta', it might help.
carry on
What you want to do is check that your document is the top-most frame and if not, 'break free' from being displayed in a frame/iframe of another location. Add this code to your documents in the HEAD section:
<script language="JavaScript" type="text/javascript">
<!--
if (top.location != location) {
top.location.href = document.location.href ;
}
-->
</script>
This won't stop Google Translate from displaying translated version of your page, for example, but it will make your document 'break free' out of the frame that Google sets up (with the ability to change a few settings and such). Hope that's what you were looking for. If you have access to your web server configuration, then also check for how to prevent linking in frame and iframe from other domains for your web server. The Apache code for that would be:
#block frame and iframe linking from other domains
Header always append X-Frame-Options SAMEORIGIN
Not sure all browsers respect such headers, though and you might be forced to use mod_rewrite rules to achieve what you're after.
Cheers!
I have a page using something along the lines of
<meta http-equiv="refresh" content="0;url=http://example.com/" />
but for certain users on a certain workstation this doesn't work. The is in IE. Is there something wrong with cookies or a setting somewhere which would cause this to fail? I never heard of such a thing.
The problem is that when IE sees this:
<meta http-equiv="refresh" content="0;http://www.example.com" />
it expects the contents attribute to contain a number. The only time IE will check for a URL is if the content attribute contains "URL=" so the redirect that is most usable in all browsers is this:
<meta http-equiv="refresh" content="0;URL=http://www.example.com" />
The above example would redirect immdetiately but if you changed the 0 for another number it would wait that many seconds. Hope this all makes sense, it should work just fine but I still think my first idea was the better one.
There is a security setting in internet explorer that does not allow meta tag refresh. It is under the Security tab, then choose Custom Level and the Meta Tag Refresh under Miscellaneous. If that is disabled, it would stop the meta refresh from working.
Aside from being able to disable it selectively, it is automatically disabled if you set IE's security level to 'High' [observed in IE9].
is it a really old version of IE? if so, try:
<meta http-equiv="refresh" content="0;url=http://example.com/"> </meta>
It needs a white space. HTML editor will complain, but just ignore it.
Check out this solution. It handles both javascript and meta-refresh at the same time:
Meta-refresh and javascript
The META tag is not an empty tag and does not have a closing tag in HTML, only in XHTML. (If you are really are sending XHTML, it may not work right on older versions of IE anyway, there are only workarounds to send XHTML to older IE versions.)
Try:
<meta http-equiv="refresh" content="0;url=http://example.com/">
W3 Schools META Tag Description
You might also try:
Checking the major and minor versions of IE. You can do this on the help->about menu option.
IE has historically gotten all confused by filenames and MIMEtypes. Make sure that you are sending your HTML as an htm or html extension file, and that those filetypes are set up on your server to send text/html mimetype.
Make sure your server isn't sending a conflicting meta refresh http header.
In case anyone tries to use meta refresh to redirect to new URL in Facebook applications ( either Page Tab app or IFRAME app ), the tag is disabled by Facebook somehow.
Workaround is:
<script>
top.window.location = 'http://example.com';
</script>
Remember to target "top", as Facebook applications are in IFRAME.
Just a wild guess: maybe there are some adblockers installed on those machines where the redirect does not work.
Can't think of any other reason why this common technique works on some machines while it fails on others for you.