Built a Jekyll website based on a 3-party theme (MASSIVELY).
Code of website available here: https://git.ikrypto.club/FNB_Japan/FNBJapan
When you visit the deployed website, the background image does not remain constant as expected (You can kind of see the expected behavior on the theme demo, https://iwiedenm.github.io/jekyll-theme-massively/ (Edit: This is actually a better example, https://massively.ghost.io/ ). Basically, the background image is expected to remain constant, and the foreground should scroll with the user.).
You can witness the difference in behavior if you go on our website, https://fnb-japan.info .
However, when the code is ran locally and built with
bundle exec jekyll serve
The background image does not move (as expected). What's happening and how can I remedy it?
Note: It appears that this problem only appears on FF Nightly, and not Chrome
Edit: This appears to be a problem with Firefox Nightly, as opposed to the website. This question is technically resolved.
Edit 2: It appears that the problem persists, and is due to a bad implementation of parallax scrolling causing parallax to flicker.
Edit 3: This problem only occurs once the window is of a certain width, and the difference isn'ta ctually between local/deployed but rather different window sizes.
The background div (#bg)
is being transformed by
this code in the bundled parallax plugin (as evident from setting a "break on attribute modification" on the bg element in the Chrome inspector), which in kind seems to be activated by this invocation:
// Background.
$wrapper._parallax(0.925);
Removing those lines should get rid of the parallax effect too.
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.
I'm building an app using Vue 2. There's a page that contains a simple image gallery that contains about 20 images and one large page background image.
The background image of the page itself is actually contained in a fixed div element that is position: fixed;, has 100% width and height and uses background-size: cover; to display the image.
All of the ~20 items in the gallery as well are using div elements with background-size: cover; displayed in a 3-column grid and the images are displayed using the dynamically generated background-url CSS property using a Vue computed property. The image paths are never being changed so they aren't being recomputed constantly AFAIK.
The performance of this page in Chrome is abysmal, loading takes forever (those are some high resolution images, though, 4K in width) and once the images are loaded I can somewhat interact with the page but everything is extremely laggy and sometimes the page stops responding completely.
On the other hand, in Firefox and Edge everything is basically buttery smooth, both during the loading of the images and during the scrolling/rendering. The interaction with the app is never blocked.
What I remember trying to fix this is replacing the div elements with regular img tags and loading up images using those. Also, I've tried caching the images, I've tried using static image URLs for testing purposes - the same thing happens every time - other browsers handle it well, Chrome is choking on it.
Here's a screenshot of the performance summary in ~30 seconds, from the moment I click the page URL to the moment that basically everything is loaded and the browser is still struggling to render anything and process any interaction with the page. Obviously the painting phase is an issue here:
Any advice? Thanks!
This question is hard to answer as it is a very specific problem.
You can analyze what is causing this behaviour in chrome by using the developer tools:
Open the developer tools in chrome by pressing "Ctrl+Shift+I".
Go to the tab "Performance".
Hit the record button and do the action which has low performance.
Hit stop and you get a breakdown what happened in the background.
If you don't find the issue with above suggestion, you can post a detailed screenshot of the performance breakdown here, I might be able to help you with it.
I am trying to make a website with a minimalist feeling to it, so I put a fullscreen image on the background as background-image of body. I have a transition: background-position 1s set as a CSS rule for body and an easing function, to create a smooth scrolling effect when going to other pages in the same HTML file (I have no actual scrollbar, just navigation elements). The thing I noticed was that once I started scrolling, the memory reserved by the page went from a small 77MB to over 500MB! I tested this in Firefox, but it doesn't seem to happen (either because pages have no separate processes or memory allocation works differently, I imagine). Why does this happen in Google Chrome and not in other browsers? And how can I reduce the enormous amounts of memory reserved by my page?
To give some information on what I am using:
Browser: Google Chrome
RAM: 8GB The page uses javascript with the
following plugins:
jQuery
Bootstrap
Background image dimensions are: 1440 x 540
A few possible causes of the problem:
The image is too big to be rendered with a transition and an easing function.
I should not use background-image for this, but create a new <img/> as a background.
I somehow only checked it with developer tools open in Chrome, increasing the memory allocated.
It's not the image causing the problem, but the web fonts I scroll simultaneously with the background image, also using transition and an easing function.
And I want to add that maybe this is not even a problem after all, it's just that I have never seen a page go over 300MB with memory allocation.
Not sure if this should be posted as a comment instead, however:
Nothing you can do about that. Chrome trades RAM for performance.
For instance each chrome tab runs on its own process for that purpose.
I had cases when a single youtube tab took over 1.5gb memory & virtual memory.
Even a blank tab takes 45mb memory for me.
So there is no issue with your code at all.
I am trying to debug this and can't make any headway. I've got this HTML5 JavaScript library I am building and the test page for it can contain large volumes of output as I am piping console.log and exceptions out into the DOM to quickly inspect them on mobile devices (it is the only way I know of inspecting state on an Android device for instance)
Here is the page. So long as I don't push up broken code while I work on this you should be able to produce plenty of debug output which will be pumped into the <body> thus allowing the page to scroll. Note also to toggle the visibility of the big blue debug panel you can tap the header text at the top of the page (like a button).
The issue is specific to iOS: Tapping the iOS status bar does not work in either portrait or landscape modes, and I am not sure what it is I have done with JS or otherwise that has disabled this quite handy feature.
Use of -webkit-overflow-scrolling: touch appears to be the culprit for iOS6 here. It actually looks like iOS5 is less broken w.r.t. this issue.
I think there may be a way to work around the issue by dynamically setting -webkit-overflow-scrolling: touch on the elements that need it by catching touch events on them. Or just leave it off as they still remain usable (just have no momentum).
I have an issue with jQuery ScrollTo.
It skips and there is a lag when applied to my page.
Here's a link to the jsFiddle example that works and here is the same code applied to my page that does not work.
It might function correctly on some machines but all the machines I have tested this on don't!
Might there be an issue with the amount of images I am using?
Is there anything I can do to overcome this?
The problem there is the background image. On "poor peformances machines", using a full page background image like you did and scrolling is not very efficient.
For instance, my machine at work lags as hell on your page, either using the top menu or regular scrollbar. On the otherhand, my MacBook Pro handles your page perfectly with a smooth feel when using the top menu to scroll.
I tested it using chrome on my machine, and removing the background image using developers tools. It now works perfectly. As soon as I put the background image back, it starts lagging again.
Its a bit jumpy on my machine (your site that is), but one thing i noticed that may help is that it is really nice and smooth smooth if i very quickly click back and fourth between 'Senior Executive' and 'Experienced Hire'.
Is there any callback or some calculation being done before, during or after the scroll perhaps?