I'm currently developing a Chrome Web App using the Chrome Platform APIs and Javascript and I simply can't find a way to display a prompt() dialog to ask the user for a value, in a way that prevents him from clicking anywhere else until he enters a value and accepts or cancels (meaning, EXACTLY how it works with Javascript).
My problem is, I just can't find a way to do this with the Chrome Platform APIs (note that prompt(), alert() and confirm() can't be used in packaged apps). I already checked questions similar to mine and they all point to the Google App Script documentation, which doesn't work for Chrome Apps.
The only "solution" that I've really found is making a new window, enabling singleton so that it can only be an instance of it and displaying a form there, getting the value when the user accepts(I haven't really finished that last part, I need a way to check when the window is being closed by a button). Still, this is kind of a lot for a simple dialog.
Is there a simple way to do this that I'm missing or is the "intended" way to do this to use multiple windows?
window.prompt has two features:
It requests input from the user.
It does this in a synchronous way, i.e. execution of JavaScript in your page is suspended until prompt() returns.
The first feature can be emulated, but the second feature cannot. So, you will be able to get user input, but only in an asynchronous way. There are two ways to prompt the user for input:
In a popup.
In a lightbox.
A lightbox is similar to a popup, except that it's embedded in the page itself. All implementations of a lightbox involve at least two containers:
A div that covers the whole page, so that the user cannot click on anything else. (CSS: position:fixed;top:0;left:0;width:100%;height:100%;z-index:1000;)
Other HTML elements that together resemble a dialog (input fields, buttons).
There are plenty of existing UI libraries to show an inline dialog, e.g. jQuery UI.
Related
Google has recently announced its deprecation of its Google Sign-In for Websites library. They will be transitioning to the new Sign In With Google SDK for the Web in 2023. The new SDK requires less effort to set up, but I find there are fewer settings available for configuration.
One of the configurations that I am missing is the detection for user closing the One Tab Sign In Pop up. Previously, when the user manually closes the Sign In modal, the library returns the popup_closed_by_user error code. But I am not able to find any detection for this on the new JavaScript Web SDK.
Is there a way to detect the manual pop up closing on the Sign In With Google SDK?
I am also interested on detecting "Exponential cooldown". That is, when user has closed the pop-up multiple times and Google SDK won't show the login button on the screen. Is it possible to trigger a callback when this case occurs?
Yes, you can observe the outcome using the PromptMomentNotification object, using the data-moment_callback when rendering the button in HTML or by throught the notification returned by google.accounts.id.prompt.
One tap can be closed a couple of ways, so the older popup_closed_by_user is now best handled by looking at two values:
user_cancel or tap_outside. The former is a result of pressing the X in the dialog or cancel button if present, while the latter is from simply clicking outside of the popup dialog. Both terminate the sign-in flow, the two values allow you to see if user behavior differs. Some users might click elsewhere, while others may explicitly close the popup.
I am building a UI testing framework which uses a headless browser (phantomJS in my case) to interact with html documents - without using jQuery I need to display a prompt (which is fine) and then programmatically enter text into the prompt dialog and then click OK, all with pure javascript. This will then add some text to a div so that I can verify the result.
Everything I have read online seems to suggest that this is not possible as the prompt/dialog boxes are built-in to the browser itself and not part of the DOM. I cannot see any properties/methods on the DOM to get the dialog and document.activeElement is returning me back the page, not the prompt. So I'm stumped.
How do I do this?
Alert & prompt are not part of DOM, they are part of browser. You can't simulate their invoke behavior from your code.
I think you need an external program (i.e. a program that runs besides the browser) which can detect prompt windows from the browser, and then fill them with text and submit them. I suggest you start with programs that can simulate key strokes like this user asked.
The gist: What's the best way to escape a Flash object's focus on a webpage?
Context:
I have a hotkey listener (an AutoHotKey script) running in my tray. If the script detects the command Alt+Shift+F6 while I am clicked into a Flash object on a webpage, it activates and sends key combinations to Flash to pull certain data logs. After this process completes, I want to call up a JavaScript file on that same browser tab that requests additional information from the user - basically, a tiny UI with additional text fields available in a third-party bug tracker. To do this, I want to send a javascript: command to the address bar using Ctrl+L and having AutoHotKey paste in the full call to the JS file.
A visualization of a possible environment:
The problem:
I need the user to be clicked INTO Flash in order to pull the data logs. However, I need the user to be clicked OUT of Flash for Ctrl+L to actually work - Flash appears to eat all keystrokes at the browser-level when one of its objects has focus.
A possible solution: The easiest way to go about this would be to simulate clicking on the stage, which borders my Flash object on every side. This should work, but I must assume the stupidest possible user. Such a user would somehow limit their current browser window to only be as big as the Flash object (if not smaller), click into it, and attempt to use the hotkey. In this case...I have no idea where I should click, because it could be outside the browser. Further, I don't believe I can assume that all browser address bars are similar amounts of pixels south from the top of the window.
Additional complicating factors:
I want this to work for the user's default browser. (IE, Chrome, Firefox, Safari are my big targets.)
AHK does not provide any native DOM or COM hooks to anything except IE.
Ctrl+Tab and Alt+Tab shenanigans do not appear to work. That can get me to other tabs/windows, but returning to the tab/window with the Flash object still causes Flash to 'eat' further keyboard input.
While I'd be open to using another scripting language than AHK if it could overcome this Flash focus hurdle, I do not know how to create a keylistener that sits in the users tray until activated by a hotkey.
I have no access to the Flash object's code, and it contains no logic to interpret a key combination as a way to break focus or launch a script.
Would it be possible to use WinMaximize to maximize the size of the window? If you do that it should be easier to set up the script to avoid clicking outside the browser.
Perhaps look at ControlFocus and/or ControlSend (using the "edit1" control in IE and FF -- unfortunately, Chrome doesn't expose the "address bar" as a "control" this way but if you test for Chrome first, you can implement your "click outside the Flash box" method for that case).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Disable browser's back button
Is there any way to disable browser(specifically IE) BACK button, FORWARD button, REFRESH button by javascript. So that, when ever any user will click on any button nothing will happen.
No, you cannot reliably, reasonably do that. Even IE's "kiosk mode" allows back, forward, and refresh (via keyboard shortcuts).
On an actual web page (a real page out on the web), disabling back/forward/refresh would of course be extremely inappropriate behavior and I assume that's not what you're trying to do. (Instead, use history libraries and such to ensure your page/web app actually works with the back and forward buttons to do what the user expects.)
Mind you, if you provide a link that opens a new window (which will probably actually end up being a new tab in most modern browsers), your page will be the first page in that window's history and so the Back button will automatically be disabled. And if your page doesn't offer any links anywhere else, it'll stay that way. And if the user hasn't gone Back, by definition they can't go Forward. Nothing you can do about Refresh, though.
If you have a genuine reason for actually disabling those actions (some kind of intranet application, that sort of thing), you'll probably have to distribute an actual application (for instance, .Net app via No Touch Deployment or similar) that incorporates a web browser control, which gives you the HTML/CSS/JavaScript environment but with dramatically higher control over that environment.
As far as I know, you can't modify the buttons in a browser with scripts.
Since you're working with IE, you may be able to use either VBScript or JScript, but I doubt you'll be able to disable the reload button.
More reading:
http://www.webdeveloper.com/forum/showthread.php?t=62177
I want to open a file dialog via FileReference.browse() but I get #2176 error which means that this action can only be invoked upon some user interaction. I'm aware of security considerations but in my scenario I have a thin flash movie which merely displays an image and the whole UI is in javascript (I heavily use javascript <-> actionscript communication).
So the question is - do you think it would be possible to invoke FileReference.browse() upon the user interaction coming from javascript?
No. If it is anything like accessing the clipboard, then you are stuck out of luck. I have tried all sorts of hacks to get around that, from setIntervals to using apply, I even tried using a ByteArray to manipulate code directly. No soap.
For that matter, you'll have to upload the file to a server using FileReference (unless you're using AIR). This is really annoying if you need to have Flash look at it.
The problem is that when Flash makes this type of decision, they are not making those aspects of the classes accessible by code directly. The code responsible for actually accomplishing these things is locked in the native code which is built into the FlashPlayer. We're black-boxed out.
Back when Adobe first updated their security model, and in turn broke quite a few running flash based upload services, there was a
pretty
big
stink.
I believe that some people were working around the new limitation by essentially creating a transparent flash movie, and overlaying on top of an otherwise normal HTML element, to 'trick' the user into giving the flash app input from which to trigger the interaction (where they think they are clicking on a simple html button labeled 'upload' they are actually clicking on the invisible flash element sitting on top of it.)
I've not tried this method myself, but it may give you a direction in which to search for a solution that might work for you.
Isn't this the purpose of object and embed tags in html? When you say the whole UI is in javascript I am assuming you are using html markup as well, though I guess this may not necessarily be the case.
How to embed a flash file in html
How to start a flash file with javascript
Ok. I've found this link: Flash Player 10 FileReference Changes. Apparently there's no workaround for this limitation. I guess I'll have to display a prompt for the user from within the flash movie, so that he/she can "interact" and allow to open the dialog.