I've been exploring the limits on SpeechSynthesis.speak on iOS Safari. I believe the current rules are more restrictive than there were in the recent past.
Are the rules documented anywhere?
These are the rules that I think apply.
Speak in direct response to a click on a <button> always works.
After the initial speak initiated by a button click additional speaks are allowed on the same page. They may be triggered programmatically by timers or whatever.
Initial speak on a change/input event does not work.
Initial speak on a click event on a <tr> does not work.
Any change of page, relative or not, puts you back to square one requiring a direct user action.
When a speak is suppressed you don't get any events nor any error indication.
You want tell if the speak was suppressed by watching for SpeechSynthesis.speaking and timing out if it isn't seen after some delay.
Are these consistent with your recent experience?
I've been testing on BrowserStack watching the events that get fired to determine which cases work.
I can confirm that you can't use SpeechSynthesisUtterance programmatically without a user action before. In my case I have in my web app a button to enable/disable audio, if the user enable the audio and later I try to speak something, it doesn't work
To solve it I had to trigger a fake speak (empty text new SpeechSynthesisUtterance('')) right after the user click on enable audio and then the audio works during all the session.
Related
Would you please help me to resolve "Blocked Pop-up Window" problem ?
When I submit our app to AppSource, we get following failure message from partner center.
Customer Control 1100.5.4.2 Blocked Pop-Up Window
Pop-up windows triggered by user interaction must not be blocked by browser pop-up blockers on their default settings. A pop-up blocked appears in the browsers when we click on the "insert" button within your add-in. Please update the offer to correct pop-up window behavior and re-submit your offer.
This is happened when our app calls displayReplyAllForm by user interaction. How can I resolve this problem technically ?
Because of following investigation, IMO, Office team should handle this problem.
In general, I should call window.open directly from user-interaction for avoiding popup blocker.
For detecting and handle popup blocker, I can utilize returned value from window.open.
But, I can't do this because window.open or something popup logic is wrapped in displayReplyAllForm. So, I think it should be handled by Office team.
My suggestion is that Office team provide promptBeforeOpen option for displayReplyAllForm. I can avoid popup blocker with promptBeforeOpen when I use Dialog API, and want to use it in other functions provided by Office.js.
Microsoft product team has repro the issue and has added this to their backlog. Let's wait they'll fix the problem and we can avoid bad UX in the future.
https://github.com/OfficeDev/office-js/issues/1377#issuecomment-690049886
When we ask the user to allow us to use their Camera and Microphone the browser presents some sort of interface asking the user to accept or reject this action.
In Google Chrome this interface looks like this:
Our users seem to be missing the appearance of these Deny and Allow buttons.
Is there any cross browser utility that serves as "visual encouragement" for the user to click allow?
For instance, in the case of Google Chrome, something like a big yellow arrow would appear in the upper right of the page window and point at "Allow".
Agree that the default presentation in the major browsers leaves a lot to be desired. That pop-down menu bar is (typically) visually isolated from whatever the user clicked on to trigger the permission request. That is, their locus of attention is on an element that's disconnected from what they need to do next. This problem is exacerbated (1) by banner blindness (which means that people are used to ignoring animations in their peripheral vision, assuming that it's an ad) and (2) on larger screens.
So those are the issues causing the problem.
Here's a quick video walkthrough of one way to solve the problem by the site and by the browser itself, using Google Maps' "use my location" feature in the web browser:
http://cl.ly/2h2f382A143F/so-browserpermissions.m4v
I'm developing an app that needs to generate mouse events on a window Win32/WPF which may be minimized or hidden from view on the desktop.
I have tried the user32.dll APIs SendInput, SendMessage, PostMessage etc. These work only if the window is visible on the desktop. Would you know about any methods that work for hidden/inactive windows?
I've also tried .NET's UI Automation library. In this case, a window is brought to the front or I'm not able to get a clickable point for the control.
Any ideas how I can proceed? If I can proceed?
I don't know if you're still interested in an answer (I just stumbled upon this question out of sheer dumb luck), but have you tried making a global windows hook?
I have no honest idea on how to properly go about implementing one; but I know you should be able to add a global windows hook to, well, Windows, to listen for whatever events you want (should include mouse and keyboard events!)
Good luck...
In Firefox (or IE or whatever), when the tab is closed, I remember you could be notified of this, and I'd like to notify my Flex app and tell it to close (whenever it's possible) all the connexions that are opened.
Does anybody know the way to do this?
You have to listen to the onbeforeunload event from the browser.
See here for more details : http://seanmonahan.org/2009/03/19/preventing-users-from-accidently-navigating-away-from-your-flex-app/
Generally you have no control over when tab is closed and when flash/flex application is destroyed. So you should not attempt to take any actions on such event, since they may be easily preempted and your deinitialization logic would be disrupted.
In your case (closing connections) you should note that all connections are closed automatically upon application destruction by Flash Player.
Edit: Actually there is a way to catch page unload event in some cases (see the other answer). But there is no guarantee that such methods will always work (i.e. they may not work on browser application close), therefore you still should not completely rely on them.
In an Access (2002 / 2003) data-bound form, a turn of the mousewheel moves to the next/previous record, even if the cursor is inside a multiline text field or a listbox. This is a major annoyance to users and cannot be turned off easily.
I recently discovered a DLL called MouseHook (http://www.lebans.com/mousewheelonoff.htm) which can effectively block this mousewheel behavior and replace it with more expected behavior.
However, when an external ActiveX control is added to an Access form, this module does nothing. For example, I have a form with a FlexGrid control on it, and it can contain a lot of rows. When a user tries to scroll in there using the mousewheel, Access again simply goes to another record instead, even with MouseHook DLL loaded.
Is there a solution like MouseHook DLL but which also works for external ActiveX controls? Or is the source code of the MouseHook DLL available so it can be modified to deal with controls like FlexGrid?
PS: I wanted to ask the author of MouseHook DLL, but he is currently "on a hiatus" until June 2009.
If you really have to alter the UI and change how the user expects the mouse wheel to work, I would actually recommend just disabling it rather than altering how it scrolls. While it's scrolling may seem odd to you, it is how the program works. What would you do if you had to read PDF's all day, and then one day one person decided that the way the mouse wheel scrolling worked wasn't good enough and changed to so it defaulted to huge jumps or horizontal or whatever. Yes, it may have been a better solution, however it is annoying to the user because it doesn't do what it is supposed to do.
Why are you using a flexgrid in Access? To me, this is a read flag that you likely are approaching the project with an Access-hostile point of view, since you seem to be choosing non-native controls to do things that are almost always much more easily accomplished with Access's native controls.
Hook the flexgrid, intercept the WM_MOUSEWHEEL message, ignore it and call your intended behaviour.
Not a direct answer to your question, but the way we deal with the mouse wheel movement is to prevent accidental changes of records after the user has started editing. When the user opens the form, the wheel moves the records willy-nilly as normal. As soon the user edits something on the field, and then moves the mouse wheel, the BeforeUpdate event fires, which causes our code to put up a prompt saying they must save the record first. We have a save button which the user must explicitly press to supress the warning in the BeforeUpdate event.