I've experienced very strange behavior with the website size.
On mobile, the website appears bigger than its content (and its html & body elements)
There is no overflow happening (or at least I found none)
When I hover with my mouse over the React Developer Tools extension, it corrects itself and the website has now the correct size (which is the size of the screen)
Links:
A link to a screen recording
A link to the GitHub repository - feel free to fork it
I've deployed the site to GitHub Pages - the bug didn't get away.
A link to the GitHub Pages site
The bug will only appear when:
You don't resize the page to mobile size. You have to load it in mobile size.
You use a real mobile device or the mobile device emulator of the browser. It won't appear without that.
Note that everything will get pretty big and oversized after resizing and refreshing the page two to three times with the "responsive" device option in the mobile device emulator. But the oversizing doesn't change the size of the elements, they are still sized to fit perfectly in the window. It's just somehow scaled up.
Everything will then turn normal again after the mobile device emulator gets closed.
Maybe this scale issue is a completely different problem. (it doesn't get corrected by hovering over the React Devtools)
Maybe you will suspect these background circle shadows, but I've tried commenting them out - nothing changed.
This bug appears on Chrome (Chrome for Windows: version 92.0.4515.159 / Mobile: same version) and MS Edge (version 92.0.902.78). I haven't tested other browsers.
Apart from React, I am using Tailwind CSS, react-router, and framer-motion.
This problem was caused by Framer-Motion.
The Home component is animated with these variants:
const homeVariants = {
initial: {
x: "110vw",
opacity: 0.5,
},
animate: {
x: 0,
opacity: 1,
transition: {
duration: 1,
ease: "easeOut",
},
},
exit: {
x: "-110vw",
opacity: 0.5,
transition: {
duration: 1,
ease: "easeIn",
},
},
};
So when it initially slides in from the right, it is causing the website to expand.
I've added overflow-x: hidden; to the body, but that is not enough, as explained here.
To fix this, I added overflow-x: hidden; to both html and body and position: relative; on the body tag.
html,
body {
background: #130f40;
overflow-x: hidden;
scroll-behavior: smooth;
}
body {
position: relative;
}
<meta name="viewport" content="width=device-width, initial-scale=1">
Try This
You can visit this link for more description
Related
I'm working on updating my research lab website, and I'm using a Jekyll framework with Bootstrap. Whenever I navigate to a new page or refresh my current page, the font size grows slightly, then returns to its normal size. This makes for a jerky experience. My work in progress is currently on rigglemanlab.github.io, and the page where this issue is most noticeable is rigglemanlab.github.io/members. The code for this site is on github.com/benlindsay/lab_site.
I've tried some answers to similar posts like this one where the suggestion was to add the following to my css sheet:
body > div {
font-size: 1.4rem
}
I tried variations of that like em instead of rem and html instead of body > div and setting the #font-size-base variable to 1.4em or 1.4rem, but the same behavior persisted with each attempt. How can I clean up the rendering of my website?
As Mr Lister points out, it's probably a case of FOUT (flash of unstyled text), as it looks like you're using TypeKit.
A quick solution to this is to use TypeKit's built in events to hide text until the webfonts has loaded.
.wf-loading { visibility: hidden; } /* font is loading and hidden */
.wf-active, .wf-inactive { visibility: visible; } /* font has loaded and is visible */
When opening the demo application from core-layout with the embedded browser in the Facebook app on iOS 9.x (at least), the footer element is not visible when the device is in portrait mode. If you rotate the device to landscape mode, the footer will be partially visible. However, the footer (with a button) should be completely visible.
The first image shows how the demo app should look, while the second image shows how the demo app is missing the footer when viewed with the Facebook app's embedded web view (the images were grabbed from a Chrome desktop browser illustrating how the bug is manifested):
After testing a lot of different hypotheses, we concluded that the bug was caused by the browser making the page/viewport higher than the visible area.
This bug seemed related to iOS9 Safari viewport issues, meta not scaling properly? and Web page not getting 100% height in Twitter app on iOS 8.
The solution we came up with was a combination of other answers we found on StackOverflow, while paying strong attention to details. I will stress that implementing just some of the below changes did not fix the bug; all the changes had to be made.
The CSS defining the height of the wrapping div element (#outer-wrap) had to be changed from
outer-wrap {
position: absolute;
width: 100%;
height: 100%;
overflow: hidden;
}
to
html, body, #outer-wrap {
position: absolute;
top: 0;
left: 0;
bottom: 0;
right: 0;
overflow: hidden;
}
The following function was added to the library, and is called upon initialization:
function _fixViewportHeight() {
var html = document.querySelector('html');
function _onResize(event) {
html.style.height = window.innerHeight + 'px';
}
window.addEventListener('resize', _.debounce(_onResize, 125, {
leading: true,
maxWait: 250,
trailing: true
}));
_onResize();
}
_fixViewportHeight();
The viewport meta tag had to be
<meta name="viewport"
content="width=device-width, initial-scale=1.0, maximum-scale=1.0, target-densityDpi=device-dpi">
However, the scale values had to be 1.0, not 1; that caused the fix to break in one of our build processes where we applied html-minifier, which replaced the decimal values with integer ones. The html-minifier problem was fixed by surrounding the viewport meta tag with <!-- htmlmin:ignore --> comments.
Had the same problem, but all I had to do was use window.innerHeight, instead of document.body.clientHeight.
For those looking for alternatives to Martin's answer, you can also update your CSS when you detect Facebook in-app browser.
My problem was essentially CSS-related : bottom elements were hidden.
function adaptCSSFbBrowser() {
var ua = navigator.userAgent || navigator.vendor || window.opera;
if (isFacebookApp(ua)) { // Facebook in-app browser detected
$('.bottombar').css('height', '50vh'); // Update css
}
};
And then :
$(document).ready(function() {
adaptCSSFbBrowser();
...
To understand the reason for bug with the height you need to know how FB in-app browser opens: it has animation on opening and browser size is increasing from bottom to top.
And that is why on start page height calculated by JS could be incorrect
window.innerHeight,
document.documentElement.clientHeight,
document.body.clientHeight
element.style.height='100vh'
Height could be less than final page height because JS could be executed during opening animation while browser height is still increasing
I've solved this problem by reaching to screen.height which is always constant
to detect when app is opened in facebook in-app browser I use function from here How to detect Facebook in-app browser?
function isFacebookApp() {
var ua = navigator.userAgent || navigator.vendor || window.opera;
return (ua.indexOf('FBAN') > -1) || (ua.indexOf('FBAV') > -1);
}
P.S. same bug could be with width calculation,screen.width will help with it
In IE10, the scrollbar is not always there... and when it appears it comes on as an overlay... It's a cool feature but I would like to turn it off for my specific website as it is a full screen application and my logos and menus are lost behind it.
IE10:
CHROME:
Anyone know a way of always having the scrollbar fixed in position on IE10?
overflow-y:scroll doesn't seem to work! it just puts it permanently over my website.
It may be bootstrap causing the issue but which part I have no idea! see example here: http://twitter.github.io/bootstrap/
As xec mentioned in his answer, this behavior is caused by the #-ms-viewport setting.
The good news is that you do not have to remove this setting to get the scrollbars back (in our case we rely on the #-ms-viewport setting for responsive web design).
You can use the -ms-overflow-style to define the overflow behavoir, as mentioned in this article:
http://msdn.microsoft.com/en-us/library/ie/hh771902(v=vs.85).aspx
Set the style to scrollbar to get the scrollbars back:
body {
-ms-overflow-style: scrollbar;
}
scrollbar
Indicates the element displays a classic scrollbar-type
control when its content overflows. Unlike -ms-autohiding-scrollbar,
scrollbars on elements with the -ms-overflow-style property set to
scrollbar always appear on the screen and do not fade out when the
element is inactive. Scrollbars do not overlay content, and therefore
take up extra layout space along the edges of the element where they
appear.
After googling a bit I stumbled across a discussion where a comment left by "Blue Ink" states:
Inspecting the pages, I managed to reproduce it by using:
#-ms-viewport { width: device-width; }
which causes the scrollbars to become transparent. Makes sense, since
the content now takes up the whole screen.
In this scenario, adding:
overflow-y: auto;
makes the scrollbars auto-hide
And in bootstraps responsive-utilities.less file, line 21 you can find the following CSS code
// IE10 in Windows (Phone) 8
//
// Support for responsive views via media queries is kind of borked in IE10, for
// Surface/desktop in split view and for Windows Phone 8. This particular fix
// must be accompanied by a snippet of JavaScript to sniff the user agent and
// apply some conditional CSS to *only* the Surface/desktop Windows 8. Look at
// our Getting Started page for more information on this bug.
//
// For more information, see the following:
//
// Issue: https://github.com/twbs/bootstrap/issues/10497
// Docs: http://getbootstrap.com/getting-started/#support-ie10-width
// Source: http://timkadlec.com/2013/01/windows-phone-8-and-device-width/
// Source: http://timkadlec.com/2012/10/ie10-snap-mode-and-responsive-design/
#-ms-viewport {
width: device-width;
}
This snippet is what's causing the behavior. I recommend reading the links listed in the commented code above. (They were added after I initially posted this answer.)
SOLUTION: Two steps - detect if IE10, then use CSS:
do this on init:
if (/msie\s10\.0/gi.test(navigator.appVersion)) {
$('body').addClass('IE10');
} else if (/rv:11.0/gi.test(navigator.appVersion)) {
$('body').addClass('IE11');
}
// --OR--
$('body').addClass(
/msie\s10\.0/gi.test(navigator.appVersion) ? 'IE10' :
/rv:11.0/gi.test(navigator.appVersion) ? 'IE11' :
'' // Neither
);
// --OR (vanilla JS [best])--
document.body.className +=
/msie\s10\.0/gi.test(navigator.appVersion) ? ' IE10' :
/rv:11.0/gi.test(navigator.appVersion) ? ' IE11' :
''; // Neither
Add this CSS:
body.IE10, body.IE11 {
overflow-y: scroll;
-ms-overflow-style: scrollbar;
}
Why it works:
The overflow-y:scroll permanently turns on the <body> tag vertical scrollbar.
The -ms-overflow-style:scrollbar turns off the auto-hiding behavior, thus pushing the content over and giving us the scrollbar layout behavior we're all used to.
Updated for users asking about IE11.
- Reference https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537503(v=vs.85)
Try this
body{-ms-overflow-style: scrollbar !important;}
This issue is also happening with Datatables on Bootstrap 4. Mi solution was:
Checked if the ie browser is opening.
Replaced table-responsive class for table-responsive-ie class.
CSS:
.table-responsive-ie {
display: block;
width: 100%;
overflow-x: auto;}
JS:
var ua = window.navigator.userAgent;
var msie = ua.indexOf("MSIE ");
if (msie > 0 || !!navigator.userAgent.match(/Trident.*rv\:11\./)) //If IE
{
$('#tableResponsibleID').removeClass('table-responsive');
$('#tableResponsibleID').addClass('table-responsive-ie');
}
Tried the #-ms-viewport and other suggestions but none worked in my case with IE11 on Windows 7. I had no scroll bars and the other posts here would at most give me a scroll bar that didn't scroll anywhere even though there was plenty of content. Found this article http://www.rlmseo.com/blog/overflow-auto-problem-bug-in-ie/ which reduced to . . .
body {
overflow-x: visible;
}
. . . and did the trick for me.
I've noticed a white flicker that appears when ever I navigate between any html files in my project except for when I navigate away from my index file. I'm using JQM but I'm not using ajax because I'm linking to multipage documents.
I've read this happening to people who use JQM along with Phonegap when making apps but for a regular desktop site, I am confused as to why this is happening. Any idea?
Try this..
Remove data-position="fixed" on headers and footers if you are using it.
Then, apply the following CSS styles to your header, content and footer:
.header {
position : fixed;
z-index : 10;
top : 0;
width : 100%
}
.content {
padding : 45px 15px
}
.footer {
position : fixed;
z-index : 10;
bottom : 0;
width : 100%
}
This idea/snippet is borrowed from what Jasper's answer (not the OP's accepted answer) in this question. I was experiencing that flicker problem on a single-page jQuery Mobile v1.1.0 + Phonegap application and this solved it for me. Perhaps this same workaround will work for your multi-page application on v1.3.
On my I have a fixed DIV at the top, 3 fixed tabs and a fixed div at the bottom (this will only be shown when logged in - in the future).
I am getting poor scrolling performance on Chrome only - FF & IE are fine.
I have ready some problem reports about Chrome, Fixed Positioning and Scrolling and wanted to see if anyone had any suggestions? I really would like to fix these elements in their locations but I would also like good scrolling performance in Chrome.
Any Ideas on a fix?
Note: its much more noticeable when zoomed on chrome...
Update: I have read other people have a similar issues and updated this Chrome issue, which was later merged into 136555, allegedly fixed since Chrome 26.
Problem and How to Monitor It
The reason for this is because Chrome for some reasons decides it needs to redecode and resize any images when a fixed panel goes over it. You can see this particularly well with
► Right-Click ➔ Inspect ➔ Timeline ➔ Hit ⏺ Record
► Go back to the page and drag scrollbar up and down (Mouse-wheel scrolling not as effective)
Edit (9/1/2016): Since posting this, Chrome added new features to help monitor this:
► Right-Click ➔ Inspect ➔ Rendering (Bottom tabs)
➔ ☑ Scrolling Performance Issues
➔ ☑ Paint Flashing
➔ ☑ FPS Meter (less important, but can be useful)
This will help you identify exactly what elements require repaints on scrolls and highlight them clearly on screen.
This seems to just be a problem with the method Chrome is using to determine if a lower element needs to be repainted.
To make matters worse, you can't even get around the issue by creating a div above a scrollable div to avoid using the position:fixed attribute. This will actually cause the same effect. Pretty much Chrome says if anything on the page has to be drawn over an image (even in an iframe, div or whatever it might be), repaint that image. So despite what div/frame you are scrolling it, the problem persists.
.
The Easy Hack Solution
But I did find one hack to get around this issue that seems to have few downside.
By adding the following to the fixed elements
/* Edit (9/1/2016): Seems translate3d works better than translatez(0) on some devices */
-webkit-transform: translate3d(0, 0, 0);
Some browsers might require this to prevent flickering
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
This puts the fixed element in its own compositing layer and forces the browser to utilize GPU acceleration.
EDIT: One potential issue was pointed out to me by albb; when using
transform, all descendant position:fixed
elements will be fixed to that composition layer rather than the
entire page.
.
Alternative Solution
Alternatively, you could simply hide the top navigation while scrolling and bring it back in afterwards. Here is an example that could work on the stackoverflow.com's header or a site like theverge.com if pasted in DevTools > Console (or manually type "javascript:" into this pages URL bar and paste in the code below after it and hit enter):
/* Inject some CSS to fix the header to the top and hide it
* when adding a 'header.hidden' class name. */
var css= document.createElement("style");
css.type = 'text/css';
css.innerHTML = 'header { transition: top .20s !important; }';
css.innerHTML += 'header.hideOnScroll { top: -55px !important; }';
css.innerHTML += 'header { top: 0 !important; position: fixed !important; }';
document.head.appendChild(css);
var header = document.querySelector("header");
var reinsertId = null; /* will be null if header is not hidden */
window.onscroll = function() {
if(!reinsertId) {
/* Hides header on scroll */
header.classList.add("hideOnScroll");
setTimeout(function() { header.style.visibility = "hidden"; }, 250);
} else {
/* Resets the re-insert timeout function */
clearTimeout(reinsertId);
}
/* Re-insert timeout function */
reinsertId = setTimeout(function(){
header.classList.remove("hideOnScroll");
header.style.visibility = "visible";
reinsertId = null;
}, 1500);
};
The first solution of #Corylulu works, but not completely (still a little stutter, but much less).
I also had to add -webkit-backface-visibility: hidden; to the fixed element to be stutter free.
So for me the following worked like a charm to prevent scroll down stutter in chrome when using fixed elements on the page:
-webkit-transform: translateZ(0);
-webkit-backface-visibility: hidden;
Edit: Webkit-transform and webkit-backface-visibility both cause blurry fonts and images. So make sure you only apply both on the hover state.
Add this rule to your fixed element,
will-change: transform;
Read about solution from Here,
and read about will-change property from Here.
There's a recent bug report on this particularly annoying issue:
http://code.google.com/p/chromium/issues/detail?id=155313
It has to do with the combination of floating elements and large images. Still a problem on Chrome Canary 24.0.1310.0.
There are a number of ways you could speed up this front end, try out the PageSpeed Insights Chrome plugin for some ideas. Personally I'd recommend rebuilding this front end with the same design on top of a framework like Twitter's Bootstrap, but if you'd like some specifics on this front end:
As you say, the positioning of your header bar is causing the most time in terms of CSS rendering (CSS stress test results). Get rid of that big image that's in there and replace it with a 1px wide background image. You're also resizing images like your logo (and every other image in this header) unnecessarily, replace with actual-size versions
You could save a lot of bytes transferred by optimizing all your content images