I am writing a web application that will run in kiosk mode on a touch screen. I am currently only targeting it for running on Firefox 3. A few of the use cases I have need to visit external sites. I wish to do so with an embedded browser, which I'm tackling with the help of an <iframe>. I need back/forward buttons for the embedded home page.
I've managed to access the history object of the iframe with
var w = document.getElementById('embeddedBrowser').contentWindow;
w.history.back();
The history of the embedded window is the same as that of the parent window. Therefore for a newly loaded <iframe>, this call will go back to the previous page of the system.
Is there any way to avoid this or a more correct way of solving this?
Because there is only one history object shared within each tab this seems impossible. The proper way around it would be to test window.history.current or window.history.previous before calling back. Unfortunately, window.history.current is privileged and so not available to unsigned pages.
Here's a rough sketch of a messy workaround:
<iframe src="somepage.html" name="myframe"></iframe>
<p>Back</p>
<script type="text/javascript">
document.getElementById('backBtn').onclick = function () {
if (window.frames['myframe'].location.hash !== '#stopper') {
window.history.back();
}
// ... else hide the button?
return false; // pop event bubble
};
window.frames['myframe'].onload = function () {
this.location.hash = 'stopper';
};
</script>
Of course, this is assuming that no (#hash) browsing ever goes on in parent window, and so on, but it seems to work for the problem of limiting back movement.
You might want to take a look at Adobe AIR. It lets you write your application using all the same tools / languages (ajax, html, etc etc), but since it runs as a desktop app and not in a web browser, you have more control over things, such as embedding browser frames and knowing exactly what they are doing, what URL it's going to, controlling it's history, etc. Look here for a few pointers on getting started.
Related
I have a link that opens a new window using window.open. The pop up works fine, however the normal web page stops loading objects (images, scripts, ajax scripts) and sometimes the page doesn't load at all.
Here is my code:
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
Is there anything I am doing wrong?
Thanks,
Peter
First of all, please be more specific: tell us more about your browser and which version, and possible your OS. It could be more related to the browser than to the web content.
Then on to the possible problem; you start with saying "I have a link that ...".
To me that sound like you use <a href="javascript:DoSomething()">. Or perhaps <a href="#" onclick="DoSomething()">.
I tried both in some modern browsers: Chrome v37, IE v11. Both browsers did not produce what you describe:
- Chrome v37 will happily keep on loading, even if I immediately click a "window.open()"-link on top of a (huge) webpage;
- IE v11 will someshow show "false", which is strange, but still not what you got.
In some cases I also got to deal with the popup blocker.
A general tip might be to NOT USE <a href> for things like this. Behaviour seems inconsistent across browsers, also these days there are better alternatives, such as <span onclick="">...</span> and <button onclick="">...<button> or by using JQuery or other frameworks (which I do not know much about).
Although this many not be a conclusive answer, maybe this can help you experiment on your own, and think about possible causes or alternative ways of doing things.
The behaviour you describe should definitely NOT normally happen. This is confirmed by robbmj's JSFiddle, that fails to reproduce the problem. That's evidence that something is going on in the main page that is not plain vanilla page loading, or your "link opening" has something unusual to it. Apart from the syntax error (you use four parameters, not three).
Since you do not supply information on either of these points (how do you load the main page? How do you trigger the popup-opening code?), we do not even know if the problem
might be browser-related; I'd start and try to test things in IE, Chrome and Mozilla to see
whether anything changes; this might provide some useful insights.
One possibility
A very strong possibility is that your inadvertent fourth parameter goes into the window.open() "replace" parameter, which is a boolean, and triggers undefined behaviour or simply an error that stops everything. You should have things somewhat working in IE and not working at all in Firefox.
You should also be able to see whether this is the case by using Firefox and the Firebug extension, or the Web Developer Console in Chrome.
Another possibility
A more esoteric possibility is that the way you define the link might make the browser believe you've actually moved on to another page, so that there's no point in continuing loading the current page. Depending on the browser, this might have to do with how the link is defined and could be remedied by defining it some other way.
For example it could conceivably happen if you had
...
which I suspect is what led user Tomzan to ask, "is the link something like javascript:...?"
So if this is the case, try with this instead (this works for me in IE9/Chrome/FF):
link
function openPopup() {
MyWindow = window.open('player.php', 'Player', 'width=500, height=300');
// Also try the following. You won't probably like the results (it should send the
// popup window behind), but if it works, it proves we're dealing with a browser
// issue there.
// Blur and refocus
// MyWindow.blur();
// window.focus();
// Just focus
// window.focus();
return false;
}
Workaround
A possibly acceptable workaround could be to disable the link altogether (or hide it via CSS), and only reactivate/show it upon main document being ready. This sidesteps the problem, even if user experience could be somewhat worse due to a longer wait.
But if it's so likely that a user clicks on the link before waiting for the whole page to load, I'd also consider not automatically loading the rest of the page at all, and reorganize information to provide a more streamlined navigation. Or maybe distribute it on two sequential pages. Again, unfortunately you did not supply enough information to do more than guess.
As you probably know, JavaScript is single threaded. Every event is queued until there is idle time for it to be executed.
In the case of window.open, both windows must share a single context to keep it thread-safe because the opened window can access to it's parent using window.opener.
I don't know how browsers implements it, but we can guess two possibilities:
Idle time is shared between the two windows. It means if the popup does many blocking statements, it can freeze the main window's events.
Only one of the two windows can be active, which depends on which one has the focus. In that case, all events may be paused in the main window when you're using the popup.
If you want a more precise answer, I need more details about your code.
document.addEventListener("DOMContentLoaded", function () {
//whatever the code
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
}, false);
Try to wrap the code in SetTimeout
setTimeout(function () {
window.open( .. )
}, 0);
Your document should be loaded first, then popup should be open, So write your javascript code in the scope of $(document).ready().
enter code here
$(document).ready(function(){
$("#clickme").click(function(e){
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
});
});
How can I move my popup window back or minimize it? The following code snippet doesn't work:
w = window.open('asdasd');
w.blur();
window.focus();
I need the same effect as in http://www.filesonic.com/file/2959312855/CoreczkaArena.rar, when you Click "SLOW DOWNLOAD" the popup with ad moves back under the main window.
Got You Then - Here The Solution
var newWindow = window.open('Default.aspx');
newWindow .opener.window.focus();
You should not do this.
The reason for that is that your users' experience will suffer and that this type of behaviour is often considered harmful.
If you want to put some content "in the background", just do it within current page by implementing CSS and JavaScript scripts that make site behave as it would contain multiple "layers" or "windows". Try using jQuery UI for example.
If you insist on doing what you asked (creating new window and moving it in the back), someday it will probably stop working and your content will be blocked by popup blockers. But before that happens, you will probably receive negative feedback from the users of your site.
There is not necessarily only bad intentions to want this type of behavior of the browser.
My web application is running on Chrome.
I need to launch http requests to call a web service in localhost for document management from the document server.
And I would like to avoid cluttering the user's desktop with extra windows.
With Window.open you can reduce to the size 100/100 but you can't minimize totally when launching the window.
On the other hand, manually, you can do it afterwards.
I don't see why it can't be done directly when the calling site is in https
Cpf
No, I'm not trying to make an annoying popup. I have a simple webpage that is a web-based control for a SOA tool that will allow our clients mobile access to systems we put in their locations. If the user closes the webpage without using a "Disconnect" button that closes the communication tunnel on the service side before closing the window itself, the system remains active until the service times out. That may not sound terrible, but the same communication tunnel is used by in-house staff in high-priority situations, and if they cannot access it because the customer's web service is tying it up, that is a Very Bad Thing.
So, I want to prevent the user navigating away from the page or closing the tab or browser instance by any other means than clicking "Disconnect". I'm sure it's possible, I just need a nudge in the right direction. The solution must be as browser-agnostic as possible, especially concerning mobile browsers.
You can try using the onbeforeunload handler. but it is not always thrown.
See fiddle using jQuery: http://jsfiddle.net/maniator/qpK7Y/
See fiddle with pure javascript: http://jsfiddle.net/maniator/qpK7Y/10/
You can't stop the using from closing the window via the close button at the top right. You can force a child window to retain focus like this though:
Declare a global variable:
var childWindow;
Assign the variable to a window object
childWindow = window.open("...", "...");
if (childWindow){
childWindow.focus();
}
To force focus on the child window, use the onfocus event on the parent:
focusChildWindow = function(){
if (childWindow != null){
childWindow.focus();
}
}
<body onfocus="focusChildWindow();" ...>
Disclaimer before the uppity types start in: This is not to be deployed "in the wild". This is for local, personal use by a Chrome add-on only. I am not trying trick visitors to my sites or do anything else unsavory. I've seen a bit of chastising of those wanting to hook onbeforeunload.
Some Background
Far and away my biggest gripe with Chrome (at least on Mac OS) is its tab close buttons which, when I have several tabs open (as I usually do), results in my frequently closing tabs unintentionally as the tabs themselves become fairly small and thus the click target area that isn't covered by the tab close button is very small. On certain tabs with news stories, blog posts, documentation, etc. it's annoying but not a huge inconvenience. I just CMD+T to reopen the tab and there's no real harm done. However, certain tabs, in particular Gmail, have definite downsides to being closed. I frequently have one or more chat dialogs with coworkers open and reopening a tab does not restore the chat dialog, and initiating a new chat loses me the current chat history (yes, it's saved, but it's not conveniently accessible by scrolling backwards in context). There are a handful of requests for Google to add the option to simply remove tab close buttons (I prefer to use CMD+W myself), but I'm not holding my breath on that.
A Partial Solution
A while back a friend pointed me towards the dotJS Chrome add-on which allows per-domain custom JavaScript execution, akin to GreaseMonkey, but slightly different. At any rate, it gave me a means to "fix" issues/wants on a number of sites I visit regularly, and I've found it to be very helpful thus far. The other day it occurred to me that I could probably keep my Gmail, et al tab(s) open with a bit of JavaScript. I threw together a small script that based on a regular expression would prompt you before closing a tab. The gist of the code is as follows:
var unloadHandler = function(e) {
if (/(mail.google.com|google.com\/reader|gmail.com)/.test(location)) {
return 'Are you sure you want to close: ' + location.host;
}
};
window.onbeforeunload = unloadHandler;
Lo and behold, this did the trick for most of the sites I tried it on; except one: Gmail. Let me correct that: it worked, insofar as it prompted me to confirm the closing of the Gmail tab, and if I opted to not close it, it would keep the tab open, but before the dialog prompted me, the page had gone completely white. Element inspector shows that the markup is all still there (so far as I can tell), and the styles on the elements shouldn't be hiding things (i.e. display: none; visibility: hidden; etc) and the elements' positioning is still correct (e.g. they're within the viewable area). I went through one-by-one removing elements to see if anything was obscuring the Gmail interface, but was never able to reveal it on screen. I cannot for the life of me figure out what's going on. I'm not sure if Gmail is hooked into some event I'm unaware of (an on*before*beforeunload?), or if Google's browser is doing something special with their Gmail page, or what is causing the strange behavior. Google Reader is unaffected by this oddity (I can prevent close and retain the contents of the page) as are all of the other sites I've tested with.
Does anyone know what might be causing this issue?
For the record, I am running the following: Mac OS X 10.6.5, Google Chrome 10.0.648.205, and dotJS 1.3.
I appreciate any feedback, but I am not looking for solutions that involve: pinning tabs, changing my workflow/usage (e.g. not selecting tabs with the mouse), etc. I really want to figure out what, specifically, Gmail (or perhaps Chrome?) is doing that is sabotaging my efforts here. Thanks in advance.
I think Gmail's own code causes this behavior. I can reproduce your problem (on linux machine) with subscribing for this event from the console with this function
window.onbeforeunload = function(e) {
return "Hey what\'s wrong with you?!";
};
After it I've started the developer tool profiler, the last call after closing the window (and choose the 'stay on this page' answer for the question) is a removeChild function call, which removes some content from the <iframe id="canvas_frame" />. So the content elements are not there anymore.
function Fc(b) {
return b && b.parentNode ? b.parentNode.removeChild(b) : m
}
I've found some 'traces' in the obfuscated code for subscribing for the beforeunload event, but it's hard to be sure :)
function It(b, a) {
this.Qc = jCa++;
this.ea = b;
this.ka = new J(this);
this.Qa = a;
this.Ka = [];
this.Za = !1;
this.ka.ya(this.ea, "unload", this.Da);
this.ka.ya(this.ea, "beforeunload", this.ab);
Ypa(Zd(a), this);
this.ia()
}
I tried to reproduce this behavior in Firefox but I think google ships different javascript codes for different browsers so I can't reproduce it.
I was wondering if there was anyway I could make another browser within my webpage. Basically I want this browser to be an interactive area on my webpage (about half the page).
The main page should be able to detect where every click was made within the mini browser.
Is there some apis that would help me out? Or would my best bet be to stream a remote desktop?
Programming your own browser engine in Javascript will take you years, and it will inevitably be slow, cumbersome, and prone to errors. Furthermore, your Javascript cannot really have direct access to other website's HTML code, it will have to go through your own server anyway.
You can use an
<iframe>
tag. To detect clicks and mouseovers, you could transform the HTML on your server first, potentially adding "onclick" events. This would let you have XSS access too, and cookie control.
You can embed another page within yours using an <iframe>. Once you do, however, you can't control much of what happens within it, or detect where clicks are made, unless the page within the iframe is from the same domain, for security reasons.
You could try the <iframe> tag.
No, it really can't work that way. My suggestion would be to embed an iframe and then control it using JavaScript. However, you won't be able to control it very well (like, for example, limiting where the user can browse with it).