Hover problem with Safari


(Uli Zappe) #1

Hi everyone!

I’m new to Hype, so I’m not sure whether I did something wrong or ran into a problem with Hype & Safari.

Here’s a simple Hype document that demonstrates the issue:

HoverTest.hype.zip (70.3 KB)

The starting scene in this document has two buttons; one links to the tumult.com web site, the other to a second scene. As long as the mouse hovers over one of the buttons, a text box appears.

This always works as expected in Firefox and Chrome.

It also mostly works in Safari. However, there is one scenario where it doesn’t work in Safari:

  1. Move the mouse over the Go to Tumult button. As expected, the text box appears.
  2. Click on the button. As expected, the tumult home page appears.
  3. Click on the Back button of Safari. As expected, the starting scene reappears.
  4. Move the mouse over the Go to Tumult button again. The text box should appear, but it does not.
  5. Move the mouse away from the Go to Tumult button. Then, move it over the Go to Tumult button again. Now, it again works as expected and will keep working as long as you don’t click on the Go to Tumult button again.

Contrary to the Go to Tumult button, the Go to Scene button works as expected in Safari.

So the question is: did I do something wrong, or is this a bug/compatibility issue with Safari and Hype?

If it is the latter, is there a workaround?

Thanks in advance for your replies!

Uli


#2

Hi Uli

You’ve found something “interesting” here regarding Safari. I set the “Hover” state on the “Go To Tumult” button in the Hype app to show a blue color. When, in Hype’s “Preview” mode, I went to the Tumult web page & back (“Return” view - in image just below) the button still showed the “Hover” state as it was when we left the original document. The “Hover” state is not being “cleared” (reset) in Safari as it is in Chrome. (Please see image just below.)

Note 1: In my Demos that follow below Hype’s blue hover state is not employed - the above test was used to find out what the issues were.

Note 2: You set these “button state” controls in Hype by selecting an element then choose “Show Button Controls” from the “Edit” menu.

So a simple fix, with out any JavaScript, is to place a rectangle (“Safari Trigger”) behind the “Go To Tumult” button with its “On Mouse Over” Action is set to “None”. (You can group this rect & the button as in my Demo.) The “Safari Trigger” rectangle clears~resets the “Hover” issue for the “Go To Tumult” button in Safari and there’s no impact on the functionality of your set-up.

Demo Hype Project: HoverTest_JHSv1.hype.zip (24.2 KB)

Demo here.


In the screen shot below this rectangle - “Safari Trigger” - is colored in blue to show its boundaries. You can of course set its color to “None” - or give it “0” opacity - so there is no visual interference with anything below. I found that a tighter rect boundary with the button will not have the desired effect with a fast moving mouse.



“Safari Trigger” rectangle - “Actions” setting.
Note 3: Even though we are using “On Mouse Over” with Action=“None” - having no Action at all will not Clear~Reset the “Hover” state for the “On Mouse Over” of the “Go to Tumult” button.




Possibly there is some JavaScript jujitsu that can accomplish the same effect (window.location.(reload)?) - but I’m not sure it would be any more effective~easier than the above solution.

In any event - this is one idea. And it’s dead simple.


(Greg) #3

It looks like the first mouse over fails, but a second mouse over works. Also, In the "Go to URL section - if you check the box to “Open in new window” it works as expected. Maybe it’s a problem with the back button in Safari - swipe to go back also fails.


(Mark Hunte) #4

The problem is that Safari is caching the page.

You can see this by using the developer menu to Disable Caches


(Mark Hunte) #5

And a search on google confirms this. The Caching is to do with back page load speed as I suspect and why I tested Caches.

Putting this in your head file seem to work.

	<script type="text/javascript">
	window.onpageshow = function(event) {
    if (event.persisted) {
        window.location.reload() 
    }
};
	</script>

It will also work in a Hype function on Scene load…


(Uli Zappe) #6

Thanks everyone for your insightful replies!

Now I even have the luxury of being able to choose among several workarounds. :smiley:

Uli


(Uli Zappe) #7

After some testing, I decided to go with Mark’s solution (the Javascript in the header), as it covers one case that Jim’s solution (the Safari trigger rectangle) cannot cover:

When you click on the Go to Tumult button and then, without moving the mouse (so that it’s still in the hover position) press Command-Left Arrow on the keyboard to go back to the starting scene, the Javascript solution works (i.e. displays the text box again, as it should since the mouse is still in the hover position), while the Safari trigger rectangle does not work, since the mouse is never moved over the rectangle.


#8

Nice sleuthing Mark! :eyeglasses:


(Uli Zappe) #9

After more testing, I have to revise my choice.

As it turns out, Mark’s solution (the Javascript in the header) can lead to ugly “flicker” depending on the browser & operating system combination. In the worst case, after returning to the starting page, you’ll see the (cached) starting page for a very short moment, then the page becomes blank, and then the starting page starts to appear again.

This does not happen with (at least newer versions of) Safari, which is why I did not discover it immediately. But when it happens, it’s ugly. And of course, going back to the starting page happens all the time, whereas the one situation that Jim’s solution (the Safari trigger rectangle) cannot cover will rarely happen (clicking with the mouse on the Go to … button in Safari, and then immediately going back with Command-Left Arrow without moving the mouse first).

So while neither solution is a 100% fix, I now think the Safari trigger rectangle is preferable.


(Mark Hunte) #10

Thanks for reporting that back…

I did look out for that as when I tested I had a simple JS console.log() run on sceneload to let me know the scene really has reloaded.

What I would see was two lines of the loaded text I used and then it would disappear.

This made me think that I was hitting the cache first and then the reload but it did not manifest into anything I was seeing in the browser. But that looks like because I am in the latest Safari…

Maybe @Daniel or @jonathan know of a real fix for this,


#11

What if you did a check for Safari & detect the onpageshow event (on scene load)?

var isSafari = /^((?!chrome|android).)*safari/i.test(navigator.userAgent);

if (isSafari == true) {
    var currentScene = hypeDocument.currentSceneName();
    window.onpageshow = function(event) {
        if (event.persisted) {
            hypeDocument.showSceneNamed(currentScene, hypeDocument.kSceneTransitionInstant);
        }
    };
}

HoverTest-onpageshow.hype.zip (23.3 KB)

Safari checker via here.


#12

Nice Daniel - works for me (Safari 7.0.6).


(Uli Zappe) #13

Perfect – that works 100%!

Thanks a lot!!