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.
Related
I know there are lots of javascript plugins and libraries to allow users to pick emojis for text inputs, but windows and mac already have native emoji pickers (⊞ Win. or CTRL⌘Space), Is there a way for me to open these native emoji pickers when a user clicks in a text field instead of installing plugins in my website?
I already tried emulate button key press, but it didn't work at all.
Short answer is no.
In order to access any OS feature from javascript, you need a corresponding browser API to support.
AFAIK, there isn't an API for that. There's a discussion here which suggests adding <input emoji /> to standard but seems no traction gained.
Edit: Below is my original answer, revised. Comments pointed out I was focusing on the wrong aspect of the question, I totally agree.
However, the OP obviously has some wrong idea about what you can do in javascript to leverage browser ability. So I think it's still worth clarification.
You can't send arbitrary emulated keyboard event from js and hoping the OS will respond. Were it possible, it'd be a severe security issue on browser's part. Imagine open a website and it fires a series of keyboard event to your OS and wipes out your desktop (totally feasible through shortcuts).
You need to understand the runtime env inside the browser is basically isolated from the one of native OS. Whatever OS feature that's accessible to your javascript is totally up for browser vendors to decide. For security reason, they are super careful in making these decisions.
Also, make a distinction on "what browser can do", and "what browser allows you to do in js". Seeing Chrome has an "Emoji & Symbols" context menu item, doesn't necessarily mean it decides to grant you the same ability in js.
To further clarify why the emulated keyboard event is fundamentally different from the native one, I include a graph here. The blue arrow is how emulated keyboard event flows. The farthest place it can reach is the browser's internal event bus. It never got a chance to reach the OS event bus, so no way to notify native emoji picker.
I am trying to print a pdf created from code in an asp.net webforms app, but before the actual print I want to show the print preview popup that appears for example when I use javascript's window.print()
Basically, I need the exact same popup to appear, without changing the page I am curently in, but instead of showing in the popup the page I curently am in, I want to show the PDF created.
The problem is I can't find anything that would get me to this result. Maybe I don't know what to look for, so thanks in advance for any advice.
window.open("path to pdf"); or window.location.href = "path to pdf";
this will open your pdf in a new window. I don't know about a print preview but it will allow them to view the generated pdf.
Short answer, no, Print Preview is a common but optional client-side feature and preference that in an uncontrolled environment (the Internet) you do not have programmatic access to.
If you do have a controlled environment then you can just install custom software that you can program against. But since you're asking in the first place I'm assuming this won't be an option for you.
As #jaredlee.exe said, your best best is to pop open a new window but instead of linking directly to the PDF you could try linking to a simple page that has a full-page iframe or object (or possibly embed) that points to your PDF. Then you could bind an onload (or onreadystatechange or domcontentloaded or whatever else) event that fires the print() method for that specific object.
That all said, there's a really big point to understand and that's that web browsers having the ability to render PDFs natively is a relatively new thing. Adobe shipped a plugin for IE (and maybe Netscape) in the 90's and over the years newer browsers like Chrome and Firefox were added. Overtime, however, these programs started to add their own PDF renderers and once they did that they actually disabled Adobe's. On top of that, operating system vendors (who often happened to also be browser vendors) started to add native PDF renderers directly to their operating system. Some people (myself included) believe that all of these renderers pale in comparison to Adobe's reference renderer so we then disable the built-in ones wherever we find them. So for me (and I know I'm weird) all of these options would still, at best, result in an empty window that's trying to print a blank page and a downloaded PDF.
To restate the above, a web browser is most commonly used to view web pages. The moment you switch to PDFs you are no longer in the "web world" but the "PDF world" and you aren't controlling a "web browser" but instead a "PDF renderer". Unfortunately there's no specification for talking to "PDF renderers" out there because the field is still too new.
To restate my restatement, this all might work some or most of the time, but also don't be surprised if there are edge cases that completely fail.
Recently, we found that Firefox had made a change towards plugins, such that the user will be temporarily blocked from running them if they are not using the latest version. Our site requires Flash to play sound and interact with the user's webcam/microphone, so we need to do whatever we can to ensure they're not getting these warnings.
One way suggested to me is to create a small Flash control, and wait for it to tell Javascript that it's been initialized. If not (and the user is using Firefox) then they are taken to a page prompting them to update. This may work, but I worry about its reliability, and about running it on every page in our site.
Alternatively, I've been researching a way to use Javascript to detect versions, without making a Flash control. I not only need the user's current version of Flash, but also the version Firefox will expect - and I haven't found an autonomous way of doing so. I don't want an admin to have to change a small value each time Adobe releases a new version. Does anyone have any advice how I could find Flash's latest available version, or an alternate way to solve my problem?
I recommend you have a look at SWFOject and the Express Install option which should ease upgrading considerably.
I just noticed someone upvoting this question, so I thought that I would provide my eventual solution, which I think reduced the impact of a recent issue where Firefox blocked the most recent edition of Flash, pending Adobe's fix.
Basically, I went with a variation on the second paragraph in my question. It does not direct the user to a new page; instead, it opens a dialog over the current page that explains it's having issues communicating with Flash. (It does not specifically say "Your Flash is out of date" because this can also happen if the browser is hiding flash under a Yes/No user dialog). It also contains a small fake flash object, with the idea being that if the browser wants to display a security warning, accept prompt, etc., it can do it inside that space.
The dialog goes away on its own if said Flash control ends up making its callback to JavaScript. It also installs a variable under sessionStorage so we don't bother checking for it again (Flash takes enough time on some computers that you might see the dialog for a split second).
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.
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