In this fiddle Chrome and Firefox display the expanding tree significantly differently. This causes a problem in Chrome. When one expands the tree by moving the cursor down the right side of a visible node, the node that one is moving to jumps to the left. Depending on where the cursor is, it's possible to lose the entire tree, forcing one to start at the top again. Firefox simply expands to the right, and this problem doesn't occur.
Any idea how to get Chrome to display like Firefox?
Thanks.
P.S. IE is like Firefox. Chrome is the odd man out.
Related
I'm building a site for a client and man I'm having a hard time with CSS Scroll Snap in Chrome...
{{redacted URL}}
I'm using Chrome 109.0.5414.87 on OSX. After the intro animation (FYI I hate these but clients love them) you should see:
Scrolling from first red section into blue I see a flash
Scrolling from first red section into blue, often times it will almost get to blue, but then glitch back to red.
You can actually scroll UP past the top of the page
Works great on Firefox and even Safari (OMG).
All the issues seem to be related to going from first slide to the second.
I have noticed that the length of the scroll-handle seems to change when going from section 1 to 2, I have no idea why but perhaps that is related?
Any tips or help would be most welcomed!
OK looking into this now, I see that it was because I had an element (footer) at the bottom of the page that was toggling to display:none. Not sure why this should effect scroll snap, but I suppose it's because it is changing the length of the scrollbar and Chrome didn't like that.
This doesn't stop the scroll up issue (#3), but it does seems to solve all the visual glitches.
So for all future people: When using scroll-snap, make sure you aren't doing anything that might change the height of the page during scroll, Chrome doesn't like that. 100vh on mobile was another culprit of this.
I've got a safari-specific problem with a hover effect:
When the user moves over a circle, another circle should appear over it (offset).
This works, but when the user moves his cursor off the circles, parts of the hover-circle still remain until the browser redraws the site (not sure if "redraw" is the right term) . You can do this with Cmd+A to select all text, for example. The hover--leftovers will disappear then.
I think an example shows it the best:
http://jsfiddle.net/L81h9hjr/3/
<div class="wrap">
<h1><span>Reply<span>Our services</span></span></h1>
</div>
The example works flawlessly in other browser I tested, so you need a Mac Safari (I tried 8.0.6).
This is a repaint/redraw issue with Safari / webkit (not sure why it's only on Safari and not Chrome).
I worked around this issue by attaching a jQuery event to the hover element that forced it's surrounding/parent elements to redraw (in my case, a hide() and then a show(0)).
$('.hover-element').on('mouseleave',function(){
$(this).parents(".containing-element").hide().show(0);
});
Make sure you use show(0) not just show(), for some reason plain old show() doesn't get fired without an animation argument.
I'm developing a website in hebrew, and everything is fine in Chrome and Firefox (as expected), but I have an issue with IE.
When I place
direction:RTL;
unicode-bidi:embed;
the whole page gets shifted to the right, and a horizontal scrollbar appears.
On initial load of the page, IE loads it scrolled to the right side, so it looks good (no need for manual scrolling), but the horizontal scrollbar is there.
All the other elements are placed correctly and I can't find the issue. There is no element that would overflow outside the main wrapper, and the scrollbar is there only if direction:RTL is placed.
I can notice that the scrollbar appears near the end of the loading, but I don't know if there is some way to step through the loading of the page (something like breakpoint/debug/step).
I tested it on 3 different computers (IE8/XP, IE8/Win7, IE9/Win7, and also with http://netrenderer.com )
Some help/guidance would be greatly appreciated.
You can check it at:
http://southbeachsmoke.co.il/
http://southbeachsmoke.co.il/products/category/1
Recently I encountered a rendering issue in Webkit which I suspect to be a bug with the Webkit engine. But I am not confident enough to say so. So I would like ask here and see what you think.
It'd be a bit difficult for me to describe the case in plain text, so I prepared a snippet here:
http://jsfiddle.net/2eQXa/1/
First you can see a yellow background with red border. This is not a background of the <body> tag but a <div> with id "backdrop" which has 100% width and height. By default it links to the "backdrop-no-problem" class. Also there is a horizontal list with some images. The list is surrounded by a green border. Inside the list there are some Wikipedia logos wrapped with a dotted red border.
I tested the page with the following 3 devices:
1. Chrome 21 on Windows 7
2. Mobile safari on the first generation iPad (running iOS4, I'll call it iPad1)
3. Mobile safari on the "new" iPad (running iOS5, I'll call it iPad3)
Try clicking "right" or "left" to scroll the list. Pretty good.
To reproduce the my problem, first click on "Issue #1". This will change the backdrop div from "position:absolute" to "position:fixed". Then click "Issue #2". This will add "-webkit-backface-visibility: hidden;" to the element (The reason for adding this style is to ensure smooth animation on the iPad).
Now click "left/right" to scroll the list. You should see a strange behavior in all three browsers:
The green div is scrolling properly and smoothly, but not its child elements. The child elements simply "out-sync" with the position of the scrolling parent. The movement not only looks laggy, it sometimes even stuck. And the child elements will stop at a wrong position when the scrolling animation finishes. You have to move your mouse over the picture (or tap on it in a tablet) to trigger an update to have the element re-drawn at the right place. Even Chrome shows this weirdness makes me feel that it is a Webkit issue.
Things gone worse in iPad3. In iPad3 you don't need to add "-webkit-backface-visibility: hidden;" (Issue #2) to see this weird behavior. Just add "position:fixed" (Issue #1) will do. The strange thing is that this doesn't happen when you view the snippet in jsFiddle. In case you are interested I have put the source in a single file at pastebin:
http://pastebin.com/i4ARX4mD
When writing this question I saw quite a number of questions regarding backface visibility. I've checked some but none of them matches my problem.
Ideas or suggestions are welcome. Thanks!
(Post updated to fix many typos)
My site http://bit.ly/aokA4I has a search bar on the top right.
You can see it on IE7, FF, Chrome, Safari -- but not on IE8. It gets chopped off.
BTW if you happen to see it on IE8 just refresh the page and it will chop.
If I run IE8 on compatibility mode the search bar becomes visible.
Any ideas how to solve this?
Thanks!!
It's because IE8 is interpreting the nature of its parent container: header_widget_1. The sizing or formatting of this element is causing the <li> element to be clipped prematurely. If you have Google Chrome, you can right click the sidebar element you're asking about and choose "Inspect Element". This will show you what the elements are doing.
Edit: You also have a sizable horizontal scrollbar in IE7.
Edit 2:
You might try altering the height of your #header element to be the height you want. Since height is not expressed in the sidebar class, this may also be contributing to the problem.