Bug introduced in 3.6.7 - fixed class


(Nextstep) #1

I updated to Hype Pro 3.6.7 and I noticed this bug.

When I have an element with the class fixed it will not scroll within Hype and some appear transparent. But, only when zoomed 100% all the way to 3200%. When zoomed at 75% or lower it works fine as it always has.

Using this in the Head Html:

.fixed {
position: fixed !important;
}

Then in the Identity panel > Class Name = fixed

I have reset all preferences and still there. Also this bug is also found in the latest 4.0 beta.

Thanks for such a great product, use it to make simple basic apps for small ministries.


(Hans-Gerd Claßen) #2

position: fixed is not part of hypes runtime.
it’s not nice and it’ll be great to have the opportunity within hype,
but after all there’s no guaranty that elements manipulated by outside css work as expected.


(Jonathan Deutsch) #3

Thanks for this report. I’d like to have a solution but it is a bit of a tricky problem – Hype’s scene editor uses a web view to show your content, so if you use your own CSS overrides it will probably interfere in unexpected ways like this!


(Nextstep) #4

Sure that is fine, wondering why it never was an issue before. Also looks like the bug was introduced earlier possibly in version 3.6.6

Thanks for a great product!


(Jonathan Deutsch) #5

Thanks, though are you sure the bug didn’t exist even earlier? It is pretty inherent to how Hype works so I think it should have occurred since v1.0!


#6

It’d be good to get some kind of shielding (whatever that’s gonna be :smiley: ) as came across this when helping a user with a “lightbox” adaptation recently. It was an external script / styling but it would run inside Hype if clicking on an image. And wouldn’t close so had to close and re-open Hype doc. Annoying but not the end of the world :slight_smile:


(Jonathan Deutsch) #7

Yeah - the reason there isn’t any right now is that most CSS/head changes are genuinely useful or would be nice to have in the preview. There’s not a great way to know what is/will be dangerous and just filter those out. Maybe I can do a small subset though based on common actions.


(Nextstep) #8

Yes, take a look at the same file, one saved from Hype 3.5.5, the other from 3.6.6.

You can see version 3.6.6 stays in place while, version 3.5.5 scrolls together with all elements. Elements have always stayed in place since version 1 or 2 from what I remember, just noticed it in version 3.6.6 I believe it changed.

Thanks.

Hype 3.5.5.hype.zip (34.3 KB)
Hype 3.6.6.hype.zip (34.4 KB)


(Jonathan Deutsch) #9

Thanks for the sample documents!

It looks like you are correct, this did change from v3.6.3 -> v3.6.4. The reality is that it should never have worked - I think it is probably a Safari bug that it ever did.

The exact change was this removal from Hype’s scene editor head:

- body * {		
-			-webkit-transform: rotateY(0deg);		
-		}

This code previously told all elements to use webkit graphics acceleration (by hacking it to think it is a 3D object), but interfered with SVG rendering so was removed in v3.6.4. I do not plan to add this back, as it also still better simulates exported documents (and hence the element being fixed!).


(Nextstep) #10

Fair enough, will use that work around you posted or just zoom it to 75%.

Side note - I never stated this bug, but another issue is that when you place the same type of element on the bottom of the viewport instead of the top, it disappears if out of view. Meaning it becomes transparent, if it has the .fixed class. Same bug/issue but when at the bottom it is not viewable rather than static.

Thanks for a great product.


(Jonathan Deutsch) #11

Ha, interesting workaround – zooming down actually uses a transform on the scene so probably has a similar effect!

Thanks for the other report - same issue fundamentally :confused:.