I'm using a WebKit-based browser (OWB) and I would like to close the browser by using a JavaScript function call. It seems that window.close closes windows created by another window only (i.e. windows with parents) . It is possible to make a plugin for calling exit and kill the browser process, but this solution causes memory leak and unexpected behavior. I don't know if there is a function for this in ECMA standard, but maybe there can be one in WebKit API. Is there a function that I could use to close the main window (without any parent) of browser?
It's not possible, How would you like it if random sites can close your browser at will? I would definitely be looking for another browser. Can you explain why you need this (very annoying) behavior? I bet there are very good alternatives, from a usability perspective, to what you want to achieve.
As a side-note: WebKit is a HTML rendering engine and has in fact very little to do with javascript.
Related
I came across this question referring to alerts and confirm dialogs, like the one created by alert('Hello World!'), while searching for a way to change the text in the 'ok' and 'cancel' buttons (there isn't one). That question, or rather, an answer to that question, indicated that somehow the OS is used to generate the confirm boxes, rather than the browser.
I've hear them referred to as 'native' before, but I had assumed that meant that the dialogs were native to the browser, not the OS.
My question is, what exactly determines the rendering of these dialogs? Is it the operating system, the browser, or some combination of the two? Does the browser handle these on its own, or does it ask the OS to display a dialog, and then catch the result of that?
It's totally up to the implementation within the browser how the alert dialog is created/rendered and different browsers likely do it differently as it is not something that is specified by any standards nor does it need to be. I would expect Firefox to probably use it's own cross-platform XUL tech to render it (just an educated guess). I'd expect IE to use native OS stuff.
The main idea behind those dialogs is that they block execution of javascript (they are blocking prompts) and they are not customizable beyond what the function interface provides.
Is it possible to open an actual explorer window rather than have the look in directory on your browser?
So like the windows key + e window... preferably using html or JavaScript?
I've seen it been done in a Firefox add-on called new tab king, but i couldn't figure out how to split up this code.
Most, if not all, javascript is blocked from interacting with anything outside of the browser.
You maybe able to accomplish it with a flash based object. Like they use for some of the copy and paste techniques using javascript.
Its a huge security hole to open up the javascript to the windows environment.
I could ust open a hidden file browser and start coping files, or load something on to your system.
This is not reliably possible using pure HTML/JavaScript.
In general, website maintainers cannot use JavaScript to force the browser to open an application in a specific way, because that would heavily impact the user experience.
No, not definitely not using HTML and hopefully not in pure JavaScript.
Probably possible using some horrid ActiveX control in Internet Explorer but you really don't want to go down that route.
I've been having a crack at some of the problems over at http://projecteuler.net/ with JavaScript. I've been using a simple html page and running my code in script tags so I can log my results in the browsers' console. When experimenting with loops I sometimes cause the browser to crash.
Is there a better environment for me to do this kind of development?
a browser that has separate processes for each tab
debugger breakpoints
an if that breaks the loop if some threshold for time is hit
If you're running computationally expensive programs in your browser, you may want to look at using web workers. In short, they allow you to run code in a different thread which won't lock up the browser.
If you are just interested in running javascript programs as such, why don't you use something like node.js or even Rhino? That way you can easily log output without loosing it if it get into 'trouble'.
I can think of two ready possibilities:
1) Use a debugger that has breakpoints. Firebug is rather nice. Safari and Chrome also have some built-in debugging tools.
2) You could move your testing out of the browser using Mozilla Rhino and Env-js (see http://groups.google.com/group/envjs and http://github.com/thatcher/env-js )
All modern browsers (except Opera) should interrupt your script if it runs for more than 5-10 seconds (Source).
In Firefox you can even lower this threshold, if 10 seconds mean a too big punishment. Also note that this mechanism kicks in even when you run code from the Firebug console:
Stop Script on Firefox http://img819.imageshack.us/img819/9655/infloopsp.jpg
I think this feature alone should provide a pretty safe environment for these loopy experiments :)
There's nothing you can do to keep the browser from crashing other than fix bugs that cause the browser to crash.
You can at least mitigate the impact of the crash by using a browser like Chrome that generally segregates crashes in one tab from the others (so you lose only your own page), or just installing a separate browser specifically for testing.
In terms of keeping track of data that might have gone to the log, you might use a plugin like Firebug that has a built-in debugger so you can pause the script execution partway through and examine your variables, presumably before any crash occurs.
Okay so it's sorta pointless considering that even if there was support for this you could still open more than one instance if you have more than one browser installed, but I was wondering anyway.
Just to emphasize what others have said, No. This is entirely a server-side problem.
I hope not. This restriction would be a pain to users and only underline a problem in the Web Application Infrastructure.
JavaScript and HTML are rendered and run within the browser and have no control over the browser itself. It would be quite dangerous to give them the ability to manipulate and restrict the behavior of the browser.
What are you trying to achieve by restricting them?
If it is a webapp they need to log into I would just restrict a user from being logged in more than once at a time. Other than that would wouldn't want to restrict their opening of the actual window
We stumbled on the usual Friday afternoon bug...
We have a .NET 2.0 WinForms app that uses the WebBrowser control (deployed on XP tablet edition, with latest IE 7). At some point in a page, we are hiding a div and setting a textbox value using some JavaScript. At that point, the operation is working (text appears in the textbox), but the complete window is now frozen. Minimizing/maximizing the window does not respond, etc: it appears that windows messages are not being processed anymore.
If I click anywhere outside of this window (taskbar, another open window), the previously frozen window is now working properly. I redo the same operation, locking occurs again. This is systematic and can be reproduced on this particular machine anytime.
We cannot reproduce it internally using a variety of machines.
On the same machine, if I navigate to the same page and perform the same operation directly with IE 7, everything is working fine... very frustrating.
Any idea on what could cause this behaviour? what to check for? Apparently no JavaScript error is thrown by the page.
Thanks for any ideas or pointers
The .NET 2.0 WebBrowser for Windows Forms is buggy; we've ran into so many different bugs in the implementation, including some interop errors that cause crashing AccessViolationExceptions, that we're now moving away from embedded IE and using Mozilla.
I hate to be a pessimist, but the embeddable IE control is just junk.
You might want to look into Mono.WebBrowser control. Same managed programming interface, but is implemented with the Gecko engine from Firefox and an alternate implementation with the WebKit engine from Chrome and Safari.
Another alternative is to skip the .NET 2.0 WebBrowser wrapper and use the ActiveX IE control directly via mshtml interfaces. Unfortunately, there are even a few bugs in the generated mshtml wrapper.
Bottom line: I'd recommend Mono.WebBrowser.