Why do elements with the CSS position: fixed applied to them cause Firefox to eat 100% CPU when scrolling the page they are in? And are there any workarounds?
I've noticed this behavior on a few sites, for example the notification bar at the top of the page on StackOverflow. I'm using Linux in case that matters.
This is bug #201307.
It's a bug reported in bugzilla
Apparently a work-around (with mixed reports of success..) is to disable smooth-scrolling
Just disable smooth scrolling in Edit > Preferences > Advanced.
As already stated, this is bug #201307. The workaround is to disable smooth scrolling:
Edit -> Prefrences -> Advanced -> General tab -> uncheck "Use smooth scrolling"
This website has a fixed element "First time at Stack Overflow? Check out the FAQ!", and it's slow as hell in firefox. Works better with Opera and Chrome though.
FF3, Windows XP, ATI.
it eats CPU because the browser has to repaint the entire viewport every scroll change rather than just the newly visible area
Are you sure that there's a direct link here? Have you created a static HTML page with fixed elements to verify your theory? Given how widely these CSS properties are used, I'd think someone else would have noticed it by now, whatever browser/OS you're running.
Related
I'm having a PITA issue with a website.
The Safari mac browser (the desktop one, specifically, mobile safari appears to work) is randomly ignoring some of my CSS -- most notably the background color applied to the HTML element. Refresh and it may -- or may not -- go away. Even more perplexing, the browser clearly knows that style is there! I'm using media queries to create a responsive site, and if you change the width enough to trigger a style sheet switch... it suddenly comes back, and everything works properly.
How the heck can I debug this? There's no error output in the console, the same data is getting sent every time (as far as I can tell...), it's not that one of the files is failing to be found (some of the CSS that is being applied is from the same stylesheet as the background...).
I'm at a total loss as to how to even begin debugging this one.
Edit:
If it's helpful, I just noticed that reader mode doesn't work on the refreshes the exhibit the broken behavior, even after the changing width trick fixes the background.
Edit:
This bug apparently also effects the mobile version, but instead of hitting the site-wide css, it's attacking my media-query based layout css.
You could, assuming you have the developer menu enabled, check Develop -> Disable Caches. This sounds like a caching issue.
If you don't have the developer menu enabled, enable it with settings (cmd+,) -> advanced -> show Develop menu in menu bar.
I'm seeing this in Safari 5.7.1 on Windows 7. It looks to me like Safari is actually ignoring commented out CSS. I removed all the comments, and now Safari seems to be behaving. But this is random for me as well, so I am not sure.
I have a div with an overflow on it to allow a calendar to scroll. But in FF 17 it seems to have a rendering issue that shows up if you scroll upwards. The top of the page just gets repeated inside (image attached). It corrects itself after a few seconds.
A few boards on the web have suggested switching this on in about:config (gfx.direct2d.force-enabled
layers.acceleration.force-enabled
webgl.force-enabled) which does fix the issue, but isn't really a viable option for customers using the web app.
This question here iframe won't scroll in Firefox 17 seems to be having issues with not scrolling at all, so close but not quite.
Has anyone else come up against this or have an idea on how to fix it?
This may be an issue with your video card and Firefox's hardware acceleration settings. I would go to Tools -> Options then under the Advanced panel, General tab, look for this region:
Try toggling those on or off and see if that helps.
Cheers!
This problem is only happening in Google Chrome on Mac OS X (Chrome 17). I've tested it on all the major browsers on Mac and Windows 7.
Here is the page in question:
http://dealsfortherich.com/drop/
As you can see, I'm loading divs via JQuery AJAX.
The page is always fine on "Refresh."
You can navigate pages with the left and right arrows. The problem happens when you change pages; especially when you change pages when scrolling the page quickly. Try scrolling the page down very fast and hit the right arrow.
The background images that were already loaded via CSS (for example):
.sort_block{ background: url(images/sort_block.png) no-repeat;}
start to disappear. Only background images that are loaded with CSS start disappearing. All are fine. If you open Developer Tools on Chrome inspect the elements, you will see that the browser has the correct syntax and it has already downloaded the image into its cache. For some reason, it's just failing to display it. The CSS display value is correct. In the Inspector, for the div with the missing background, if you modify a value such as "top: 8px;" to "top: 9px;" the image suddenly appears.
This is only happening in Chrome (v. 17) and Chrome Canary (v. 19) for Mac OS X (10.7.3).
Should I report this bug to Google or is there a known work around or fix? I guess I can replace the s with s but I would rather do it correctly and fix this weird issue.
I don't know if this is the same issue, but the root is probably the same: http://code.google.com/p/chromium/issues/detail?id=111218. Based on that report, I don't think there's a known fix yet.
I had the same problem and diagnosed it for hours, but it's not about your code, it's a memory related bug in latest chrome. In my experience it doesn't happen to small images, so a temporary solution would be to decrease the file size (to under 10kB or so).
I have a test file here, showing the difference between a big and a small background image.
http://kolina.fi/chrometest.html
We worked up a solution for this issue until Chromium/Chrome "fixes the glitch" (hi, Milton)...
My colleague, Andrew, posted our solution here:
http://blog.andrewcantino.com/blog/2012/02/15/fixing-the-chrome-background-refresh-bug/
You can see the page in question at:
http://www.mavenlink.com/tour
It sounds like this has worked for others as well, but it's ugly!
I've recently had this issue, and the fix was to use the complete url, rather than a relative path.
E.g. change url(images/image.png)
to
url("http://yoursite.com/images/image.png")
Use :url(.//images path. The .// should solve the problem.
In Webkit, will a 3D CSS transform set to repeat indefinitely, continue even when it or a parent element is hidden from view by styling (CSS)?
The reason I ask is that I am seeing unexpectedly high CPU usage on a page I am developing.
If anyone knows a good way to diagnose this issue (for example visualizing where CPU cycles are going on a page, as opposed to a blanket CPU usage per tab), I would be very grateful.
Anecdotal evidence (removal of the hidden CSS animation) would suggest that the animations do run in the background. Does anyone know how to prevent this?
In chrome 16.0.912.75, at least CSS animations appear to continue even when the element is set to visibility:hidden;. Setting display:none appears to resolve the issue.
you can debug this kind of situation with the developer tools
chrome / safari right click inspect element.
Go to the timeline tab and click on record, after that you can see what the browser is doing internally.
We've run into an optimization problem using WebKit on Mac OS X that we're hoping someone can help us with.
We've written a Cocoa app for Mac OS X that essentially manages a single WebView that points to our online web site. Everything is working fine for the most part. However our web site uses CSS's position:fixed to keep a thin "header bar" locked to the top of the WebView, similar to the big orange "Welcome" bar at the top of StackOverflow.com. We've determined that with position:fixed active, scrolling the WebView forces the entire web page to re-draw itself, which causes scrolling to be agonizingly slow. With position:fixed disabled, scrolling is very fast and fluid; only the page elements that are scrolled "into view" need to be drawn.
We know that this isn't a bug in our Cocoa app code, nor is it a problem with our HTML/CSS code. The same slow scrolling occurs using WebKit test code from Apple. We can point Apple's test code to http://www.StackOverflow.com as a test and we see the exact same behavior. There's also a test page in the Mozilla bug database that we've been using to test the problem (https://bug201307.bugzilla.mozilla.org/attachment.cgi?id=139911). The odd thing is that some WebKit-based browsers on the Mac (eg, Safari and Chrome) don't have this problem; scrolling is always fast on pages using CSS's position:fixed with those two browsers.
Has anyone else experienced this problem with WebKit on OS X? If so, what can we do to speed up our scrolling? Thanks.
I might be way off here as I'm not sure if the same will apply in your web view, but using a style that forces the nav onto its own layer may help.
Something like translateZ(0), or translate3d(0,0,0,). I've come across similar issues when building with Phonegap and applying some thought to layering really helped out.
I believe the browser can utilise hardware acceleration where a third dimension is involved.
I was having a similar problem: the fixed bar was flickering when I was scrolling the page.
So I forced the WebView to use layers and I fixed
[w setWantsLayer:YES];
I had a similar issue in my webview based mac app. It has header and footer with position:fixed css property. Latest webkit shipped with 10.10.x and above don't suffer from this issue. It happens in webkit for mavericks (10.9.x). I got it working by setting these properties for the webview
[self.webView setWantsLayer:YES];
[self.webView setCanDrawSubviewsIntoLayer:YES];