GearVR Samsung browser - vrdisplaypresentchange not firing on exit
I can catch when it starts presenting with the 'vrdisplaypresentchange' event and also with VRDisplay.isPresenting (returns true when presenting), but the problem is that 'vrdisplaypresentchange' doesn't fire when the user stops presenting ( when they click the back button ) and VRDisplay.isPresenting still returns true after exiting..
Obviously this is a bug with GearVR's webvr implementation, but I'm still searching for type of some work-around..
Note:
There doesn't seem to be any way to capture the backbutton event, it
doesn't trigger a mousedown or keydown event
Standard fullscreen events are not fireing on exit
Yes, there's no workaround for this. But it has been fixed in latest update (4.2, on 8/22) so won't need to.
Related
I have a paper-button with the on-tap function that opens a paper-dialog that contains a "Accept" paper-button that will close it when clicked.
The problem i'm getting is if depending on my screen resolution, and the dialog's "Accept" button is over the initial button to open the dialog, when clicked, the dialog opens and closes. I'm assuming the on-tap event is being fired to both.
I've tried these 2 methods but they do not seem to help.
event.cancelBubble = true;
event.stopPropagation();
The problem is that a capacitive screens or even mouses can generate multiple tap event on the same spot within a few milisec.
The mouses because a quick change in a high and low voltage (logical 1 and 0) generating an AC signal wich can jump trough on a capacitator (which can be the button two contactor between the air) if the conditions matching. But the onclick event is already catching this case and you does not require to do anything to solve it.
The capacitve screens are capacitators and just rolling your finger should trigger multiple tap events because your skin has different depth of insulation and hard to mark the tap begin and end in some cases.
This physical problem should be solved by the platform, but it is not in every situation currently (but most of the devices are filtering this). Im usally solving this isse with a transparent overlay element wich can catch the pointer events for a little duration so I could catch the "prelling" of a button or the capacitive screen for a few ms.
If a 10-20ms is enough for you then wait a frame in your on-tap function with requestAnimationFrame and then show the dialog. Cheap trick, but it does what it has to, but ultimately you can wait a fix timeout to show the dialog, because you have 100ms to respond a user interaction.
You cannot fix this by manipulating the browser events options though because as I know you dont have option to how much time need to pass until the next same event should happend. But if you wait a frame thats could behave like you add a delay between the events.
In my wxWidgets (wxPython) app, I am using a 50 ms timer to do some polling and update a window if there are any changes. If changes are detected it calls wxWindow.Refresh to update the window, and the actual updating of the widgets is done in the EVT_PAINT handler. It would be nice if I could disable the painting and/or the timer if the user is not looking at the window anyway. However EVT_PAINT is still being fired even if the window is iconized or hidden behind a different window.
Is there any way to detect if the window is not currently visible on screen, or to prevent EVT_PAINT events from firing unnecessarily?
There is the IsActive method and the EVT_ACTIVATE event to test whether the window has focus, but I want to keep updating the window if it is unfocussed but still visible. The wxWindow.IsShown family of functions doesn't help, they still return True for hidden/iconized windows.
IsShownOnScreen() could help with the iconized case. Edit: But actually does not.
Or you could trap wxEVT_ICONIZE to detect when the window is minimized.
But to be honest I'm rather surprised that refreshing a window hidden behind another one still results in a repaint. If the window in front is not transparent, this really shouldn't happen.
How can I do something (I want to increment a variable and display it on the screen) during someone pressed the button. Actually there is no event called OnPressed for a button in Windows Phone.
The Button has a Click event that you can handle and use to perform your logic.
In order to execute logic for the duration of the press, handle the ManipulationStarted and ManipulationEnded events.
In addition to the click event, you can use Tap event.
The problem is that your button will handle the event and prevent it from bubbling - if that wasn't the case you could use MouseLeftButtonDown/Up events to do this.
However there is a way to get around this and still get the event by using the more tedious UIElement.AddHandler method.
Ex:
myButton.AddHandler(UIElement.MouseLeftButtonDownEvent, new MouseButtonEventHandler(myMouseEventHandlerMethod), true);
The last bit ('true') is important since this overrides the event bubbling. 'myMouseEventHandlerMethod' is the method that you usually would use for handling a MouseLeftButtonDown event.
Handling 'Up' is the same thing. You probably also want to handle "Leave", or use CaptureMouse() when down triggers.
I have an image element, following is the html for the button
<input type="image"src="images/undo.png" onmouseover="this.src='images/undo-hover.png'" onmouseout="this.src='images/undo.png'" id="btn_back" onClick="back();" >
When my application makes this input disabled (attribute disabled="disabled") all browsers stop firing mouse events. So I don't get hover images. But opera still keeps firing these event, and I keep getting the hover images on disabled elements.
Can you please try making the INPUT element disabled by default (add disabled="disabled" in the INPUT tag from start). Then see if Opera is still responding to mouse hover. This may not fix the issue right away but will help in figuring out the cause.
Also, another approach could be to call the JS function on mouse event and check if the element is disabled or not. If it is disabled then dont change the src attribute.
HTH,
this is a bug in Opera as we're apparently doing something different than other browsers. Please report it on https://bugs.opera.com/wizard/ and give me the bug ID.
That said, I don't think what you are relying on is standardised anywhere, so possibly you should not write code that depends on this somewhat quirky behaviour. The "disabled" attribute merely means that the element will not do its normal action when clicked. I don't really see any reason why setting disabled should prevent firing mouseover/move. It's easy to check from JS if the button is disabled and not swap the image if it is.
It seems like an expected behavior in opera, Please see the following link.
http://www.quirksmode.org/dom/events/click.html
It says that "A click event on a disabled form field does not fire events in Firefox and Safari. Opera fires the mousedown and mouseup events, but not the click event. IE fires mousedown and mouseup, but not click, on the form. All these implementations are considered correct."
Thanks,
Unnikrishnan B.
Check the test page here http://rickchristie.com/testfocus.html
Correct me if I'm wrong:
onfocus happens when the element gains focus.
onblur happens when the element loses the focus.
In Firefox 3.6.12 (tested on mac and windows), using onblur without onfocus works fine. However when an input element has both onfocus and onblur element, it gets weird:
When you click at the input, onblur is fired instead of onfocus.
Right after onblur, onfocus fires immediately.
You can't type anything in the textbox.
Other browsers (Safari, Opera) works as expected. Is this a bug? Is it just me or is everybody using Firefox experiencing this?
Update
This behavior seems to happen only when onblur and onfocus contains alert - not when I use something like window.log.
When the alert box opens, focus is removed from the text box. Notice that the "BLUR" alert box opens right on top of the "FOCUS" alert box (the latter opened first), so that's why it looks like onblur fired before onfocus.
Look at my test page, which increments a counter when either event handler is called and also adds a second alert box after both of the others. It seems that Firefox actually starts executing the blur handler as soon as the alert box from the focus handler opens, despite the conceptually single-threaded model of the browser. However, when the first (focus) alert box is closed, the second (blur) alert box has to also be closed before the third (after focus) alert box opens.
I don't know Firefox why does it the way it does. Chrome keeps firing the focus handler again and again, and Opera, Safari, and IE do it the way you would expect — not taking away the text box's focus.
EDIT: I've found https://bugzilla.mozilla.org/show_bug.cgi?id=31889 and will be posting this test case there – apparently it used to be even worse.