I am using Chrome on OSX and have encountered an infuriating bug which makes JSFiddle unusable:
As the screenshot shows the CSS and Result text areas are squeezed off the screen with no handle to pull them back. How can I make them visible and usable?
It hasn't always rendered like this, but I'm not sure what has caused it.
What I've tried
Disabling all chrome extensions
Resizing the browser to a ridiculous width
Clearing local, session and cookie storage for JSFiddle on Chrome
Removing secondary screens
Changing my screen resolution
None of which have changed anything.
Update
The bug is not replicated when using safari.
Related
Seeing a weird issue where opening one page will load our network graph with filled circles of images, but jumping to another page will not display the circles. MOF two observations have been made:
Issue does not exist with Safari but only Chrome
Removing the image fill results in the circle being drawn
I've tried old and new versions of d3 v5, v6, v7. It's hard to test on jsfiddle because this is related to page changes inside Salesforce
The issue is not cache related as I've turned off cache and can see the images being downloaded in Chrome Dev Tools. Generally a refresh will fix the issue.
Good Render
Bad Render
Firefox sometimes hasn't been displaying my website's logo image. There's nothing in the code I can find that would make this happen. From what I can tell, the image displays fine in WebKit, and displays fine when the FF web inspector is open, and displays fine after a hard reload (Ctrl+R), but sometimes won't appear after a soft reload. When I right-click on the image, or open the web inspector, the image suddenly appears, as if it had been there the whole time. What could be causing this?
i think it can be something about page resizing.
When you open the webkit your website browser window change dimension, and you see the logo.
maybe this two things are connected.
try to resize the browser window without opening the webkit.
hope this works to catch the problem.
I tried disabling all the Firefox plugins, thinking it was some extension that was causing this, but no luck. I finally got it to work as expected by completely resetting Firefox using this guide.
I am developing a website: http://www.techniquetolife.com
It's basically a div 5x as big as the window inside window sized div, with other divs within the large div, using the overscroll and scrollTo plugins to navigate.
The website works perfectly fine in Safari and Firefox for OS/X. But I am having serious trouble making it work in Chrome. I'm not sure if it's an Chrome OS/X only problem, but whenever I scroll over one of the inner divs within the large div, the whole browser slows down, this only happens in Chrome...
If I disable overscroll and use the scrollbars it works 100% fine, but I really want to use the overscroll drag to scroll plugin.
I am no good at coding so any help would be greatly appreciated.
All of the plugins / browsers are on the latest version.
Okay, well I posted an answer to a similar question that I think this might be related too. I could be wrong though, but you could test it.
See the full question and my full answer here: Chrome slow scrolling with fixed position elements
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 Page -> Inspect Element -> Timeline -> Frames
► Hit Record on bottom
► Go back to the page and drag scrollbar up and down
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 no downside as of now. By adding
-webkit-transform: translateZ(0);
To your fixed panel, putting that div in its own compositing layer.
I've got a Wordpress site with some CSS3 rules applied to some images that rotate the images and have a hover effect on rollover too. Problems are showing up in Safari & Firefox when you hover on and then off these images and I can't seem to locate any similar issues by people on the Interwebs.
See http://tinyurl.com/3n2eude and hover on and then off the images (the slightly rotated ones):
Member name goes blurry and then back to normal (Firefox)
Member image border becomes jagged (Firefox)
A big black line displays to the side of the member images sometimes when you hover back and forth between two member images (Safari)
If I disable the transform:rotate rules, it's all fine. So seems to be an issue with that rule. Just can't work out how to get around it.
Anybody got some ideas on how I could get around these or what might be causing it?
Thanks for any ideas you might have!
Bit old of a question but that problem is related with rendering on browser (from what I understood). It cannot be fixed on CSS/HTML side. It must be fixed on user side.
Fix: http://www.askvg.com/how-to-enable-direct2d-directwrite-hardware-acceleration-in-mozilla-firefox/
More information about problem: CSS3 rotate - rendering problems in Firefox and Safari
We have a website that currently serves drawings to users via the SVG Viewer plugin. We have one client that sees it through IE8. With IE8, when they do a Change Zoom Level on the browser to anything other then 100%, the viewer tries to occupy the new space and zooms correctly. However, when the user tries to manipulate the frames inside that bound the viewer (it's a frameset website with the viewer being in the center) the entire site hangs. IE8 also shows that it takes up CPU cycles on the client computer, so it's trying to do something but hitting a loop.
I don't think this is actually our code and might just be something with SVG and how IE8 handles plugins and it's zoom. Does anyone know if this is a real problem and if there's a good solution?
If you are referring to the Adobe SVG Viewer plug-in, then I recommend that you (ideally) get your clients to start using a web browser that supports SVG natively — i.e. Chrome, Safari, Firefox, Opera; even IE9 (to some extent) — or use a different shim like SVGWeb to provide SVG support for those users of older browsers who also have Flash installed.
I found out what the problem was. I thought it was the SVG viewer trying to do something with the frames, when it turned out that I was just setting the frameset's initial size to the clientHeight and clientWidth, and then subtracting something from the height. That subtraction was a toolbar based in the frameset and, when you change the zoom level in the browser, there's a lock up that can occur with you trying to pull a components size and the client's size. At least, this is what I was seeing.