I've never faced this issue ever, so I completely updated my mac + Safari (macOS Big Sur 11.2.3, Safari 14.0.3). The problem is that whatever js interaction I use on my page is bugged in Safari only (work perfectly in FF and Chrome). You can see the kind of animations I use (gradual hiding + showing of elements via max-height + opacity on click of elements) in this snippet.
The problem is that Safari behaves very weirdly with these. Sometimes, the clicked element also disappears; disappeared elements fail to reappear when the animation is reset; sometimes one of the not-clicked elements disappears on hover; etc.; really weird things. All this while no console / js error is reported, and things work perfectly smooth in FF and Chrome.
In the Internet I found countless reports about similar behaviour in Safari, but mostly the answer referred to js / css errors. My script's even written in ES5.
I checked about 100 times now, and have none of these errors.
Then I came across this post, which made me try to change the font. And indeed, everything also works in Safari when I use a default browser font as Arial, etc., but that's obviously not what my client wants.
The font of that site is Bank Gothic Light & Bank Gothic Medium, and I'm using ttf and woff files as font source files, which I define as custom fonts using #font-face in my stylesheets, and then I apply them via font-family in my stylesheets. With this, the animations have the mentioned weird behaviour in Safari. Simply when changing the font of the concerned elements to let's say Arial, it all works.
Ideally, I want every animation to work, while sticking to the Gothic fonts in all FF, Chrome AND Safari. Any clue what to do here / why this happens?
Problem solved by getting a new font source file (ttf and woff) from another source; seemed to be buggy (Nothing at all changed in my HTML, CSS, JS, PHP, not in whichever code!). I changed the title of my question to be more general, as one may (at least that was the case for me) totally not think that these Safari - rendering issues are due to the used fonts... To avoid that people with the same issue may not need to search for the reply for hours..
Related
When working on a website on my local server, I came across an issue with Croppie.js. The issue only happens when a modal is used to crop the image — for example, everything works fine here:
[codepen](https://codepen.io/azerafati/pen/VzOGRe)
I was able to reconstruct the issue on Codepen using the following image.
The Issue
With a modal on Codepen, the issue only happens in the Editor view — Image B:
[codepen](https://codepen.io/amatek/pen/GREvEbG). Surprisingly, everything seems to work as expected in the Details view — Image A: [codepen](https://codepen.io/amatek/details/GREvEbG).
Normal behaviour: When using the zoom slider on the modal in the Details view, the image is transformed from the center.
The bug: However, the image is transformed from a corner when in the Editor view. This somehow leads to a black image being uploaded when the crop button is clicked.
Sometimes (depending on the amount of zoom applied), instead of a black image:
only the left side of the image is uploaded with the right side is
cut off; or
the image is uploaded zoomed in to the corner.
There is still misalignment even when the zoom is not applied.
Environment
From my tests so far, this issue does not happen on mobile browsers (although I only tested with Google Chrome and Mozilla Firefox). I have noticed the issue on Desktops with Windows 7 and 10 (I am yet to test on other Operating Systems).
Bug Present
Windows 10: Google Chrome and Microsoft Edge
Windows 7: Microsoft Edge
No Bug
Windows 10: Mozilla Firefox
Windows 7: Google Chrome and Mozilla Firefox
My Efforts so far
I have tried debugging the croppie.css and croppie.js files, but to no avail. However, I strongly suspect the problem lies in the js file. It might have something to do with the the css transform-origin property or the functions for obtaining the image dimensions returning different values on modals. Does anyone have an idea on what the cause of this issue might be?
Got this problem on latest Chrome when used croppie inside of modal
Helped me to change style in bootstrap modal .modal-dialog class
image
Style that you need to update
Setting transform to unset instead of using translate function.
Hope it helps you too
It appears that the extra padding applied to the outer modal div by bootstrap when triggering the modal('show') was what caused the problem, for me at least. Once I removed the extra padding the problem was fixed. Seems like this padding somehow messed with the point calculation when cropping or moving the viewport. I'm still using an older bootstrap version though, so I'm not sure if that would be a fix for the newer ones.
I had this problem on Chrome only probably caused by their last update, since everything was working fine for some time now. On Mozilla there were no issues to begin with.
We have a website whose background is a stack of images through which we go with JavaScript.
We check whether the next image is loaded before switching to it, and it works fine on Chrome, Safari, IE, and all mobile browsers, however on Firefox we sometimes get a white flash.
This problem also happens if we make sure that all the images are preloaded so it's not a problem that FF shows the image before it has finished loading. I've seen the question asked elsewhere but from the user's perspective, and the solution was to disable hardware graphics acceleration, which does not solve completely the problem but reduces it. However we obviously can't ask that from our users.
Similar problems were reported in other questions:
jquery animate (height) causes background-image flickering in firefox
Image Flickering only in Firefox
Firefox background image flickering when using multiple instances and background-size
skrollr background image flicker in Firefox
However none has a clear solution. Does anyone know how to correct for this?
Cheers!
We have PrimeFaces 3.4 application that was working very fine until it was tested under firefox. However, after going to test, the problems have arised:
Application will be launched in IE only (IE 9)
Application is launched inside frameset
We are using p:autocomplete in many places, that includes dialogs. The panels for those autocompletes are usually not displayed after click when:
Running inside frameset (rarely happens in normal mode)
IE developers tools are closed (rarely happens when they are opened, making the bug hard to debug)
The browser window is not maximized
The last thing is the key from our observations. The solution is to either maximize browser (which can work because we have big screens) or to zoom out the content. Therefore, I suspect that it's the issue with calculating the position where the autocomplete panel must be displayed. The algorithm must take into account several conditions, such as if the parent is positioned (dialog: position fixed), if there is scroll, whan is the offset - here the frames could mess up some things.
However, debugging is hardly an option, first because there is no official non-minimized primefaces.js, second because opening the IE developers tools somehow stops the error from occuring.
Under those circumstances, I ask how the autocomplete can behave such way, and how it can be affected by any of the elements of the puzzle: frameset, dialog, IE development tools?
Related with: IE8 and Primefaces p:selectOneMenu misbehave when having a lots of p:selectOneMenu in a form
The problem is that PrimeFaces relies on visibility:hidden to make a lot of dimension calculations. When the invisible components were out of page bounds, IE wasn't calculating dimensions as supposed. I haven't gone into details of PrimeFaces rendering engine, but simply activating always scroll solved the problem:
body { overflow-y:scroll; }
This answers the question why the problem was often seen when the frameset was used (less place) or why maximizing browser was helping.
This is the closest I've seen:
Changing font-size with jQuery css() function is crashing Chrome
But it didn't help.
Other threads mentioned that it's a bug in Webkit, but those were old threads and I couldn't find the bug report on Webkit's site.
The problem is that the header has a fixed width picture background and the navigation menu needs to stay within that width. I've since given up on HTML or CSS methods of accomplishing this. If you know of any, then please do share. So I've resorted to JavaScript (jQuery). And it works reasonably well, except in Chrome. The text actually increases in size for some odd reason.
Here's the simplified code in JSFiddle:
http://jsfiddle.net/alininja/j4jD9/12/
This gist of the code is this line:
$('body').css('font-size',(content_size-1)+'px');
For FireFox and Opera, the text size decreases to fit the header width, but not in Chrome.
If I run JSFiddle in Chrome everything works, but the funny behavior shows up on the actual website. This is happening on Chrome 17.0.963.56.
Thanks in advance!
If you want presentation consistency cross browser there is more involved than just setting font-size. You are assuming other font property defaults such as font-family are the same cross browser which they are not.
Use of a css reset will help
Despite my most convincing cries to the contrary, I was recently forced to implement a horizontal drop-down navigation system, so I opted for the friendliest one I could find - Son of Suckerfish.
I tested in various browsers on my machine and all appeared to be fine. However, some (but not all!) IE7 users are experiencing an issue where sub menus do not close after they have been hovered over. The most annoying thing is that the affected users are using the exact version of IE7 that I am (7.0.5730.13), with the same privacy and security settings (I even had them send screenshots of the tabs in Internet Options) on the same OS (XP). I cannot verify if Vista is affected or not.
Obviously trying to debug this issue is a nightmare since I cannot replicate it, so I am wondering if anyone here can and might know how to solve it. I have set up an example page here:
http://x01.co.uk/menu_test/
Additionally, there's an annoying flicker on rollover of the sub items which I have also tried to solve with no success, so any help with that would also be appreciated.
This is a problem that occurs in IE7 when another part of the page has focus (ie, you clicked somewhere and then mouse-over the menu). It seems to be an issue with the :hover pseudo-class.
Adding a hasLayout trigger to the :hover style should fix the problem.
#nav li:hover {
position: static;
}
There are other solutions too. There's a great write-up about the problem here:
Sticky Sons of Suckerfish
For testing why not download the Vista IE7 VPC image from MS themselves?
http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF
Not sure about the bug though. Remember having similar issues I think its because you need a JS. Will try and find out