Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Back face always visible on Chrome #39

Closed
Sartoric opened this issue Aug 5, 2015 · 43 comments
Closed

Back face always visible on Chrome #39

Sartoric opened this issue Aug 5, 2015 · 43 comments

Comments

@Sartoric
Copy link

Sartoric commented Aug 5, 2015

Hi
I've got this strange issue with v1.0.15 (jquery v1.11.2) and maybe it's related to bakface:hidden stuff.
I have a png with transparent background on front, and in chrome the back face (flipped) is always visible. FF and Safari are ok.

If I revert to v1.0 (the version I was using till today) the back face visibility works properly.

EDIT: I've noticed that the problem seems to be related to Back's children div , since background color and text of the main div are, in fact, not visible

@JemarJones
Copy link
Collaborator

Could you set up this problem in a small jsfiddle perhaps?

@Sartoric
Copy link
Author

Sartoric commented Aug 5, 2015

EDIT: Here it is : https://jsfiddle.net/ycLb142q/

Working on the fiddle I probably found that the problem is related to overflow:hidden setting I had to use in css, but anyway it works on FF and Safari

@JemarJones
Copy link
Collaborator

Hmm, so this problem seems to be introduced by 0ac07a7, my fix for #31. I'll let you know once i figure this out.

@JemarJones
Copy link
Collaborator

@Download Perhaps we should undo 0ac07a7? The original problem in font awesome has been fixed and i can't quite figure out what about the change is causing this new issue.

@Sartoric
Copy link
Author

Sartoric commented Aug 8, 2015

I've done some testing and it seems that adding (-webkit-)transform-style: preserve-3d; to the main dom instead of "faces" may solve the problem. This should manage 3d position for all the dom's children (I don't know if it was applied to faces to solve some issue).

      $dom.css({
        perspective: perspective,
        position: "relative",
        "transform-style": "preserve-3d"
      });

Just to check : https://jsfiddle.net/ycLb142q/3/

Set the preserve-3d on faces will apply it to front and back children, but not to front & back that are set as flat ... maybe :-)

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

I think the reason the styles are being applied to faces instead of main DOM is because that's the only way that we can get it to support Internet Explorer.

See for example this page:
https://teamtreehouse.com/forum/3d-flip-transform-in-ie10

"At this time, Internet Explorer 10 does not support the preserve-3d keyword. You can work around this by manually applying the parent element's transform to each of the child elements in addition to the child element's normal transform."

Or, this page:
http://davidwalsh.name/css-flip

You've all asked for it and now I've added it: Internet Explorer support! Annoyingly enough, the change involves rotate the front and back elements instead of just the container.

So yes, apparently it was set up like that for a good reason :)

However, as Internet Explorer apparently does not support the preserve-3d style at all, it might be a solution to apply that particular style at the dom level instead of at the separate front/back faces level.... I'm pretty sure we have to keep the perspective and transform styles at the faces level though.

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

It seems that just adding transform-style: preserve-3d to the main dom element (without actually removing it from the individual faces) solves the issue:

https://jsfiddle.net/ycLb142q/4/

This also seems to work fine on IE11... I tested with the IE10 emulation mode of IE11 and that also worked fine but I don't have access to a 'real' IE10.

@JemarJones
Copy link
Collaborator

I can download the modern.ie vm, what might we expect to go wrong?

@Sartoric
Copy link
Author

Sartoric commented Aug 8, 2015

I've tested it on Chrome, FF, IE11 and Edge , seems to works, but testing on Safari I'm getting some strange flickering with mutiple elements (no problem if I remove the preserve from dom)
I'm trying to sort it out

@JemarJones
Copy link
Collaborator

I'm also seeing some flickering on load in safari, but it doesn't go away when removing the preserve. I think that may actually be a separate issue. It appears that for some reason it takes a moment longer for flip to be applied in safari, i honestly think that may just be because Safari is slow and doesn't run the javascript in time..

@JemarJones
Copy link
Collaborator

Okay so i've now tested it in IE10 and i am seeing some behaviour where backface visibility seems to only take to only take effect when the card is static and no longer transforming. but this behavior appears to exist in every version of flip thus far. The change discussed on this issue doesn't seem to cause any problems.

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

We may have to .. shudders .. do a browser sniff and only apply the workaround in IE??

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

Mmmm I just had a lightbulb moment...

@Sartoric mentions the problem only existing in Chrome... The fix works for Chrome but causes issues in Safari...

If we use -webkit-transform-style we only target webkit-based browsers, then if we make an exception for Safari all should be well right?

For now I hacked this into the Fiddle as a css hack, but if this works well we could detect Safari from Javascript and only apply the fix to non-Safari browsers to begin wirth...

Anyway... @Sartoric could you let us know if this works in Safari? (I have no access to a Mac unfortunately)

https://jsfiddle.net/ycLb142q/10/

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

We may need to test on Opera as well as that is now webkit-based as well if i remember correctly

@JemarJones
Copy link
Collaborator

Maybe i'm being a little confusing. To be clear in my testing i'm seeing both the safari flickering and the IE10 backface issue when testing with any version of flip (including that new updated fiddle), so i think both of those are existing(/possibly separate) long time issues. But maybe the flickering that @Sartoric is seeing is different than what i'm seeing? The flickering i'm seeing is on load.

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

LOL yes it's hard to tell :)

@Sartoric
Copy link
Author

Sartoric commented Aug 8, 2015

Tried in Chrome and Opera (back face was visible too) and it seems to works fine.

Regarding the flickering issue in Safari, I can't replicate in a fiddle what I'm facing in a website I'm working on, since it seems to be related more to some css conflict/overlapping (there's also masonry involved) just for everyone knowledge, the issue is this: only half-element is visible when rotating.
Now I'm applying as a test "preserve-3d" to the parent div too (masonry brick) and it's seems to fix the flickering.

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

Ok... so we could do something like:

if (! safari) {
     $dom.css({'-webkit-transform-style': 'preserve-3d'});
}

@Sartoric
Copy link
Author

Sartoric commented Aug 8, 2015

Yep :-)
Tested using

 var is_safari = ((navigator.userAgent.toLowerCase().indexOf('safari/') > -1) && !(navigator.userAgent.toLowerCase().indexOf('chrome/') > -1));

Tested on IOS simulator and it looks good too.

@JemarJones
Copy link
Collaborator

navigator.vendor.indexOf("Apple")==0 && /\sSafari\//.test(navigator.userAgent)

seems a bit more future proof i think?

Edit: Actually, we're only seeing the issue in chrome and opera right? The issue must be specific to the Blink Engine (Chrome and Operas fork of webkit). I wonder if there is some way to specifically detect Blink?

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

Probably we should best rely on jQuery for the sniffing:

http://api.jquery.com/jquery.browser/

Nvm, it's deprecated.....

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

Mmmm... could it be this simple??

if (window.chrome) {

}

http://stackoverflow.com/questions/20655470/how-to-detect-blink-in-chrome

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

we're only seeing the issue in chrome and opera right?

I'm not sure... @Sartoric mentioned it only for chrome...

starts downloading Opera

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

Confirmed that Opera suffers from the same issue. It seems that @JemarJones is right that it is indeed a Blink issue.

In that case (according to the stackoverflow page) we should use:

if ((window.chrome || (window.Intl && Intl.v8BreakIterator)) && 'CSS' in window){
    //Blink Engine
}

@JemarJones
Copy link
Collaborator

Yes i found the same thing. I think that's sadly our best choice due to the ridiculous user agent spoofing that every browser is doing.

@Sartoric
Copy link
Author

Sartoric commented Aug 8, 2015

Sorry guys, I'm having a beer at the pub :-)
Anyway , as you 've already seen, Opera is affected too.
Regarding the detection I've ever had issues in browser recognition ... So any solution is good to me :-D

Download added a commit that referenced this issue Aug 8, 2015
@Download
Copy link
Collaborator

Download commented Aug 8, 2015

I made a basic fix that seems to be working well. It's in a separate branch for now.
I modified the JS Fiddle to use the updated code so if you guys could see if it helped?

https://jsfiddle.net/ycLb142q/11/

@Download
Copy link
Collaborator

Download commented Aug 8, 2015

@Sartoric In the pub on a Saturday night?? Ridiculous! :)

Anyways... I tested now on FF, Chrome, Opera and IE (11) and it seems to work as intended... I am just not able to test on Safari so if any of you would check that? If that's ok as well I suggest we merge it in and call it fixed :)

@JemarJones
Copy link
Collaborator

Yeup works in safari. Make sure to include the issue-40 branch in the release.

@Download
Copy link
Collaborator

Download commented Aug 9, 2015

Should be fixed in release v1.0.16.

@Download Download closed this as completed Aug 9, 2015
@Sartoric
Copy link
Author

It's me again ... Just for your happiness :)
I have an old version of Chrome (44.0.2403.125) installed on my Win virtual machine and I got some trouble after applyng v16 (probably also with v15 but I tested it only on chrome for mac that is .130).
I can't put it in a fiddle because I can't figure out which are the elements with messed up z-index an perspective.
Anyway I solved it ,after hours of blasphemy :-) discovering a couple of Chrome bugs (http://tiny.cc/a7xp1x and http://tinyurl.com/p6fzk7m) that seems to be solved now and applying "perspective: perspective" to faces in v16.

Maybe it could be useful to add it in order to avoid any other unexpected similar behaviour with old browser.
Hope it helps

@Download
Copy link
Collaborator

Ehm... can you elaborate a bit? :)

Are you saying we should add CSS rule perspective:perspective to the front and back faces?

@Download Download reopened this Aug 10, 2015
@Sartoric
Copy link
Author

Yep, you got it :)
I wrote the comment quickly without checking it, sorry.

This is what I changed

      faces.css({
        "backface-visibility": "hidden",
        "transform-style": "preserve-3d",
        perspective: perspective,
        position: "absolute",
        "z-index": "1"
      });

Tested it in Safari (7.1.7) Chrome (44.0.2403.130 and .125) Firefox(39.0.3) Opera(31.0.1889.99) IE 11 and Edge (20.10240) and everything seems to work properly.

@Download
Copy link
Collaborator

Pro Tip: Fork this repo and create a branch to experiment in. We can then even discuss right there on the commit pages. GitHub is wonderful once you get the hang of it.

@Download
Copy link
Collaborator

Can you try with this branch?

Include flip from here:
https://cdn.rawgit.com/nnattawat/flip/issue-39-2/src/flip.js

@Sartoric
Copy link
Author

Done, it works fine.
Actually I didn't tested on mobile version , trying it now.

@Sartoric
Copy link
Author

Well, I had been a little bit busy yesterday, sorry.
Tested in last mobile versions of Opera , Firefox and Chrome and it seems ok.

I just have some strange behaviour on Stock android but since I have CM12.1(Android 5.1.1) installed on my phone it could be a "non-stock" in fact. It looks like a refresh issue (image not showing or overlapping on scroll) maybe related to 3d transformation.
If you want to try it in different stock android here it is the fiddle : https://jsfiddle.net/ycLb142q/21

@JemarJones
Copy link
Collaborator

I am on an android device, chrome browser either way so I doubt it matters whether there's a skin. What's the behavior you're seeing? (For that matter what is this fix fixing?)

@Sartoric
Copy link
Author

Sorry, for CM12.1 I meant CyanogenMod ROM 12.1
The fix purpose (if you're talking about adding perspective:perspective to both faces) was to solve a bug on old Chrome version (similar to the IE one)
http://tiny.cc/a7xp1x
http://tinyurl.com/p6fzk7m

@JemarJones
Copy link
Collaborator

I have a copy of chrome on 44.0.2403.125, the version you mentioned. If i take the fiddle you've shown above and load v16 instead, should i be experiencing an issue similar to http://tiny.cc/a7xp1x? Because i'm not noticing anything like that happening.

@Sartoric
Copy link
Author

Maybe. I was not able to reproduce in a fiddle what I experienced in a website I was developing, probably due to the div hierarchy.
Long story short, the title in the backface was half covered by another layer (I was not able to understand which one) as if the z-index was incorrectly set.
Applying the perspective:perspective solved the issue. The issue appeared after v.16 and only in the "old" Chrome

@JemarJones
Copy link
Collaborator

It'd be nice to atleast be able to reproduce this before we fix it, so we can more clearly understand what we're doing. Also, I'm not 100% sure how much sense it makes for us to be retroactively fixing browser bugs that are already fixed in current versions.

@Sartoric
Copy link
Author

Yep, agree.
In fact I said that "could be usefeul" to add it , not that it must be added ;-)

Backward compatibility is something that you start thinking at when your client complains that "Everything works fine except your website, so it's your problem" 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants