Chrome used to improperly exclude the scroll bar in its media queries. This means that with 1000px of visible space and a 17px scroll bar, other browsers would report 1017px as a width so far as Media Query is concerned, but webkit browsers (such as Chrome and Safari) did not do this.
These browsers could hit a specific size where a scroll bar would appear in one resolution, then change resolutions to another where it would appear, then it would go back to when it didn't... the solution caused an ugly blank space to appear where the scroll bar should, but it did not. It came out looking like a glitch, and the DOM resize events did not fire properly so it was not something you could react to properly in JS.
However, now in Chrome 29, this appears to have changed. Now they are going off of how the specification works and including the scroll bar in their media query calculations... just like Firefox and Internet Explorer (and how the specification says they should have all along). This fixes the bugs, but causes another problem in that the JS to try to detect the Chrome/Safari issue now will have false positives, because it is not a concern with newer versions of Chrome and I assume eventually Opera and Safari as well.
In light of all of this, I cannot find any information anywhere on when this was fixed in either Chrome or Webkit. I hate having to resort to browser version testing in my JS to work around these flaws, but I am just guessing blindly on Chrome 29+ for the moment as a temporary patch and would love an authoritative answer... I have tested in Safari 6.0.5, but the old method is still being used...
Does anybody know in what version of Chrome and/or Webkit this was fixed?
Chrome is no longer using the webkit engine as of Chrome v. 28 it now uses the Blink Rendering Engine. So no need to be detecting this for chrome unless you need it for previous versions.
For more on Blink: Blink Documnetation
For more on the Release: Next Web Article on Webkit/Blink Switch
Related
Recently I've been working on building a tree-view component library for Angular, as ngx-tree.
Problem
Soon after I figured out how to implement a virtual-scroll feature for this library for performance with large data set, and got it to run properly in Firefox, I am trapped by a weird scrolling behavior in Blink-included browsers(like Chromium, Chrome, Opera).
Demo link
Here is the demo plunkr -- https://embed.plnkr.co/xMpmK5EBC46tDKpYFpw8 see Update #1 below
Situation
In Firefox, Edge and IE 11, my library with virtual scroll feature works in expectation with smooth scrolling.
However, in Chrome and Opera, when I scroll to some positions inside the tree-view, the position of the scrollbar(which is the scrollTop property of scroll area) jump up and down, causes a flickering tree-view and break down the virtual-scroll feature.
browser detail version
Chrome - 59.0.3071.115
Firefox - 54.0
Edge - 40.15063.0.0
other browsers
In China, there are some shelled browsers derived from Chromium project(like 360se, QQ browser, Sogou browser, UC browser) with older version of V8 and blink. And they don't have that weird scroll behavior.
Some Assumption
Is it caused by some optimization on the scroll implementation(like smooth scrolling) by the Chromium team?
Hope to get some guides!!! (≧﹏ ≦)
Update #1
Demo link update with event log: https://embed.plnkr.co/GpQBZsguhZZOQWWbZnqI/
One must test the scrolling before opening devtool to see the logs
I have to explain a little more how the virtual-scrolling works and what's causing the flickering.
First, see the design of Virtual Scrolling.
A key point of virtual scrolling is， we create a fake scroll area the same size as that area without virtual scrolling instrumented. So in an optimal situation, the scrollbar position of the scroll area ought not to change until some expected events trigger its changes. For scroll event, we update the view for every animation frame.
Within a height-fixed scrolling area, we assume a truth that the scrollTop property will not change with a large percentage, if we simulate the those unrendered elements' height properly(there could be a bit of deviation for the calculation accuracy) within an animation frame.
However, based on my observed results, the blink-series browsers seems to perform a different strategy to update the scrollTop of the scrollable element. Its timing to update the scrollTop is different than none-blink-series browsers. That all I've figured out so far.
Sample gifs
Here I made some gifs to show the output of Chrome, Firefox, and Edge.
Chrome
Firefox
Edge
You're pulling the library from the virtual-scroll-demo-branch branch:
'ngx-tree': 'https://rawgit.com/e-cloud/ngx-tree/virtual-scroll-demo-branch/src/lib',
That branch is 105 commits behind master. It incorrectly sets margin-top on one of the inner elements. This is fixed in newer versions.
Edit: The developer actually referenced this Stack Overflow question in their commit message.
I'm working on a wordpress website that uses the fullpage.js plugin.
My main goal is to make it go fullscreen on iOS devices, latest versions are the main targets. By making it go fullscreen I mean getting rid of the ugly top and bottom bars, as you can see on this picture, in landscape mode those bars take up more than 25% of the space.
I've tried this, but of course all browsers are compatible except safari iOS.
I've also tried all tips I found on here like including the meta "apple-mobile-web-app-capable" but nothing seems to work.
On Apple devices in Safari, getting rid of the anchors option of fullPage.js will do the trick.
Not sure about other mobile phones or browsers, but it is well known browsers don't provide a way to deal with those bars and therefore there won't be much you can do about it.
I'm developing a personal website, http://www.miketurley.com.
In any Webkit browser (Chrome, Safari) or Firefox, when you mouse-over the text on my site's opening screen, you get a slick animation which slides the text around and reveals the menu ("waking up" my website.) This may not be too necessary, but I like it and I think it's appropriate to showcase skills like that on my portfolio website.
Anyway, if you go to my website in Internet Explorer, the animations do not appear at all. The same duration of time goes by, and then the page "snaps" into the post-animation state in one frame, with no motion in between.
How can I fix this?
An explanation of this particular animation along with source code is available here: http://www.miketurley.com/index_explain.html
Leaving eval aside, you site is failing to quirks mode in IE. Using dev tools I switched to different Document Mode and the animations ran just nice. Can't find out what activates quirks right now but you have an issue to investigate. Start with passing the strict validation or moving to transitional or html5 <!doctype html>
So, by now we all know that iOS mobile Safari uses viewports (as does Android browser), rather than a 'standard' browser window. And this causes issues with overflow:hidden, and position:fixed.
This unfortunately is the same case with the iPad. I presume this is the case for other Android tablets too.
Rather than browser sniffing each time, is there an easy way to determine if the browser has a viewport or if it is standard?
Unfortunately, there's currently no good fix for mobile browsers' lack of support for position:fixed. The reason position:fixed is "broken" in the first place is because—among other things—no browser vendor knows exactly how to handle what happens when zooming in on the document. If you have some time to do some reading, I highly recommend the following articles, which will explain browser viewports and the problems surrounding fixed positioning on mobile in great, painstaking detail:
A tale of two viewports – part two — how viewports work and the problem of mobile browsers. (If you're not familiar with viewports in desktop browsers or want the background info, see also part one.)
The fifth position value does a fantastic job of explaining the problems surrounding position:fixed in a mobile browser, and suggests we might need a new position value – device-fixed.
Those articles will give you the why, but not the how to fix it. For a truly fixed position, you're mostly out of luck. However, if your goal is to have a fixed toolbar below scrolling content, there are a few ways to hack it. I've had success with iScroll.
Edit: The correct way to determine if you are running on a touch-based device is the following feature detection:
var isTouch = ('ontouchstart' in window);
ontouchstart is an event fired in mobile Safari and the Android browser. It is not present on desktop browsers, where you can just use overflow:auto and have regular scrollbars. If isTouch is true, you can then use iScroll.
Try media queries: you can include stylesheets, or apply parts of a stylesheet conditionally, based on the device and viewport dimensions the browser reports.
This article gives a decent enough introduction: http://www.alistapart.com/articles/responsive-web-design/
I want to make a mini timeline with jquery and for this timeline to have a width more than 32767 px. When I change it with jquery $(".timelinecontainer").width(32767); in Opera does not change it, but in others browsers it works.
Can you give me advice on getting it to work in Opera ?
I suspect that Opera keeps the window width as a short and thus is not able to handle values larger than 32767. You should probably change your approach anyway and scale the timeline to fit the current window, then give the ability to zoom in on portions of it. I think your interface will look and work better this way. The way you seem to be doing it, the user will have to do a lot of scrolling to view the timeline and won't ever be able to see it in its entirety.
I'm sure I'll get flamed for saying this but--you could just ignore Opera.
If you like how things look in the other browsers (IE,FF,Safari/Chrome), then I'd say you've got 99% of your bases covered.
You may want to file a bug against Opera, of course. (though I guess it could be jquery--it may have a different code path for Opera). If you could make a simple HTML page to reproduce the problem, you'd know. Then, attach it to the bug report.
This is a very old Opera bug which for some reason they can't resolve. Opera is popular only in some regions and mostly this bug is ignored by the developers.
There is no automated solution for this. As a quick solution you can detect web-browser in your script and limit the width for Opera. As an example - scroll this guitar tab to an end in Opera.
I can confirm that this is indeed a bug in the current Opera versions. The good news is that we're working on fixing it (I work for Opera, so I know what's going on there :)), so in the not too distant future your script should start working as you expect.
I'd actually suggest that if the workaround the first answer above suggests is too hard to implement, you should ignore the problem and wait for the Opera upgrade that fixes it.
This is a bug and it has been fixed in the Opera 12 pre-alphas available from http://my.opera.com/desktopteam
This is definitely a bug with Opera.
Coincidentally, I was seeing it for the first time just yesterday. In my situation I have an inner container with width:9999em and an outer container that uses overflow:hidden and scrollLeft() to create a carousel. In Opera the scrollLeft() stops responding at that width.
File a bug with Opera: https://bugs.opera.com/wizard/
Sounds like an Opera bug to me, too.
Why not take a look at Simile's Timeline project (http://simile.mit.edu/timeline/) and see how they've done it?