Develop Reference

JQuery Mobile Listviews w/collapsibles inside panel – random extra vertical pixels in Chrome v67

I'm seeing some odd behavior that recently surfaced for me after the recent Chrome v67 update (tested in both Mac El Cap and on Windows 10 so far).
Using JQuery Mobile, I have some collapsibles nested inside a panel widget acting as a menu. This was working flawlessly for some time, but when I got temporarily sidetracked and then returned to the project, I noticed that now, in Chrome (v67 of which was released in late May, while I was away from the project), I was getting random 1px vertical spaces (white horizontal lines) between some menu items when opening the menu and then expanding a collapsible. It's impossible to predict which items will be effected, and even inspecting them is difficult, as the extra space disappears/resolves on rollover or when opening the inspector.
So far, I'm not seeing this behavior in Safari or FF (Mac), nor in Chrome v66 (Windows). While I'm unable to do more extensive cross browser testing at the moment, from what I'm seeing I'm operating under the assumption that something in the latest Chrome update is causing this issue.
I've sometimes seen similar unpredictable spacing issues when the browser's view is zoomed in/out slightly, but I've confirmed I'm viewing this at actual size.
It doesn't appear to be a CSS issue, as I'm not seeing a change in the computed values of an element after the space issue resolves on rollover. It appears for all the world to be some kind of Chrome rendering problem.
I realize this is a rather specific set of circumstances, but has anyone else experienced anything similar in Chrome v67, and if so have you found a way to resolve it?
Here is a fiddle that demonstrates this odd behavior (it's easiest to see when opening "List 2 of 6"):
https://jsfiddle.net/halfacre/p349ghvf/5/
EDIT: The issue seems to be originating from the math in my JS. This script is meant to smooth-scroll the chosen submenu to the top of the viewport (as these are long lists, and without the visual cue it's easy to get lost), and was working beautifully until the latest Chrome update. I'm including said JS below. As I'm not a programmer or particularly stellar at math, this script is crossing my eyes a bit... could this be due to remainders or rounding issues?
$(document).ready(function() {
$(document).on("collapsibleexpand", ".ui-collapsible", function(e) {
var self = $(this),
menu = $("#mainmenu"),
pageY = $(document).scrollTop(),
content = $(this).children(".ui-collapsible-content");
content.hide();
content.slideDown({
duration: 300,
step: function(now, fx) {
if (fx.prop == "height") {
var pct = ((100 * now) / fx.end),
itemTop = $(self).offset().top,
menuScrollTop = $(menu).scrollTop(),
amt = (itemTop - pageY) / 100 * pct;
menu.scrollTop(menuScrollTop + amt);
}
}
}
);
e.stopPropagation(); // don't bubble up
});
$(document).on("collapsiblecollapse", ".ui-collapsible", function(e) {
var content = $(this).children('.ui-collapsible-content');
content.slideUp(300);
e.stopPropagation(); // don't bubble up
});
});
Thanks for taking a look.
EDIT 2: Screenshot of what I'm seeing:

If I am not wrong here, I believe the question is how to zero-pad the JQM collapsible, i.e. the listviewand the collapsible heading inside the menu panel.
First, keep in mind that JQM is dynamically enhancing each div which has an attribute data-role by adding some DOM content and the corresponding CSS classes.
You can look at the JQM source code by searching for mobile.collapsible and You will find what's happen at widget instancing in the _enhance() function and what's happen when You click the collapsible heading in the _handleExpandCollapse() function.
Now, I strongly believe there is somewhere a conflict among the JQM classes and Your CSS styles:
li, ul {padding:0!important; }
h3{ margin:0!important;}
But, sadly, I am not able to explain to You why this happens, as You said, just only with the latest Chrome version. I also noticed these thin random lines, which belongs to the panel-content background.
Here is my proposal to reset the space between the panel inner and the content:
.ui-panel-inner { padding: 0 !important; }
.ui-panel-inner .ui-collapsible-content { padding: 0 !important; }
.ui-panel-inner .ui-listview { margin: 0 !important; }
.ui-panel-inner .ui-listview > .ui-li-static { padding: 0 !important; }
.ui-panel-inner .ui-listview > li h3 { margin: 0 !important; }
Instead of defining new rules, I am overriding the JQM styles. Now, I can't see any thin random line anymore.
Here is the Fiddle: https://jsfiddle.net/98b4r3w5/ any feedback welcome.
Moreover: a note aside, if You need a centered page content and a smaller footer, I would do it the same way:
.ui-content { text-align:center; }
.ui-footer .ui-title { padding: 0 !important; }

Why does Firefox fire a mouseenter event on page load?

When hovering over an element and then refreshing the page (without moving the mouse):
Chrome does not fire the mouseenter event on page load
Firefox does fire the mouseenter event on page load
Below is an example snippet. To reproduce the issue, hover over the div and then refresh the page. In Chrome, the div does not contain "mouseenter". In Firefox, it does.
Note that this does not work in the Stacksnippets environment since you need to click "run snippet" first. JSFiddle: https://jsfiddle.net/9fu6cx5d/7/
let div = document.getElementById('my-div');
div.addEventListener('mouseenter', function () {
div.innerHTML = 'mouseenter';
});
#my-div {
width: 150px;
height: 150px;
background-color: #aaaaaa;
}
<div id="my-div">
</div>
Which browser has the correct behaviour? How can I work around the difference in behaviour or at least make them both behave the same?
Chrome version: 59.0.3071.115 (Official Build) (64-bit)
Firefox version: 54.0 (64-bit)

As pointed out in the comments, Chrome's behavior is the correct one according to the specs. Below is an idea on how to work around the difference.
You can make sure you get the value right by checking whether the mouse is inside the bounds of the div on document load. Unfortunately there is no way in JS to check the mouse position without firing events, so you will have to resort to some hack involving CSS hover rules and checking against them on $(document).ready.
To quote this hilarious answer:
Overlay your page with a div that covers the whole document. Inside
that, create (say) 2,000 x 2,000 elements (so that the :hover
pseudo-class will work in IE 6, see), each 1 pixel in size. Create a
CSS :hover rule for those elements that changes a property (let's
say font-family). In your load handler, cycle through each of the 4
million elements, checking currentStyle / getComputedStyle() until
you find the one with the hover font. Extrapolate back from this
element to get the co-ordinates within the document.
N.B. DON'T DO THIS.
While you definitely shouldn't do this, the general idea of using non-effective hover styles for the sake of checking if an element is hovered without needing JS events is a good one if you just need to work around browser quirks. I'm using font-weight in the example below, but you can change it to whatever works for you.
The css
#my-div:hover {font-weight:700;}
The js
// Pseudocode!
var mouseIsInside = false,
div = $('#my-div');
$(document).ready(function(){
if (div.css('font-weight') === 700) {
mouseIsInside = true;
}
doStuffIfMouseInside();
});
div.on('mouseenter', function(){
mouseIsInside = true;
doStuffIfMouseInside();
})
function doStuffIfMouseInside() {
if (mouseIsInside) {
...
}
}

If you add (function(){})(); around your code it seems to work in both browsers.
It seems that firefox might be firing events before the dom is available causing problems with mousein/out events.
See: https://jsfiddle.net/9fu6cx5d/8/

Mac Safari 7 Rendering Issue scrollLeft() issue

I created a dynamic table that scrolls left and right, has resizable columns, has a fixed header, etc. This table works great on EVERY browser I've tried. Even IE8 looks good (missing features, but still good).
This issue arises when I try to view the table in Safari 7.0.4 on my Macbook.
Attached is what is should look like (the fixed header is on the bottom for demonstration purposes):
when you scroll, the fixed header, body, and fixed scrollbar all are connected via some jQuery scrollLeft() functions (scroll one, scroll all):
var tableHeaderSpace = $('.table-full-wrap-space'),
tableHeader = $('.table-full-wrap-header'),
tableBody = $('.table-full-wrap-body'),
tableScroll = $('.table-full-wrap-scroll');
tableScroll.bind('scroll', function() {
tableHeader.scrollLeft(tableScroll.scrollLeft());
tableBody.scrollLeft(tableScroll.scrollLeft());
});
tableHeader.bind('scroll', function() {
tableScroll.scrollLeft(tableHeader.scrollLeft());
tableBody.scrollLeft(tableHeader.scrollLeft());
});
tableBody.bind('scroll', function() {
tableScroll.scrollLeft(tableBody.scrollLeft());
tableHeader.scrollLeft(tableBody.scrollLeft());
});
$(window).bind("scroll", function() {
var tableHeaderOffset = tableHeaderSpace.offset().top;
if (this.pageYOffset >= tableHeaderOffset) {
tableHeader.addClass('isFixed');
} else {
tableHeader.removeClass('isFixed');
}
});
Again, this works great...but as you scroll right a bit more, the browser starts duplicating content within that fixed header:
The issue is is that no 'actual' content is being duplicated - this is some sort of browser fragmenting that is showing duplicates - without adding elements in the DOM.
The next picture is the browser doing some more "magic". at certain points in horizontal scrolling, the whole fixed header's colors gets inverted:
I wasn't able to get a snapshot of it, but it also once duplicated the "record count" bar below it.
Anyone have any ideas what's going on here? I tried to duplicate this in jsFiddle but no dice. From that, I would assume that this is an issue with my code, but the results are only with ONE specific browser on mac (safari), and it is doing some STRANGE stuff.
Last note - since I can't replicate this in jsFiddle, i'm not sure how I could report this to Apple (the working (or 'broken') example is proprietary and I can't give out access to it).
EDIT:
here's the jsfiddle where I tried to duplicate the issue (very rough - but it's functional):
jsFiddle Duplication Attempt

so - I knew this wouldn't be a hot topic question, but I thought I would still give it a go ahead.
as for the answer, I found some old table css that was overlapping my new stuff - which in turn was somehow flipping safari out so bad that it was fragmenting it.
previous old code: background: transparent;
new code: background: #fff;
This doesn't make sense to me - but until someone else comes up with an hypothesis, I'll mark this as the answer.
now my number-one contender for worst browser: safari - look out, IE.

window scroll method flickers in IE

This may come as a huge surprise to some people but I am having an issue with the IE browser when I am using the $(window).scroll method.
My goal:
I would like to have the menu located on the left retain it's position until the scroll reaches > y value. It will then fix itself to the top of the page until the scroll returns to a < y value.
My error:
Everything seems just fine in Chrome and Firefox but when I go to Internet Explorer it would seem the browser is moving #scroller every time the scroll value changes, this is causing a moving/flickering event.
If someone could point me to a resource or give me a workaround for this I would be very grateful!
Here is a fiddle:
http://jsfiddle.net/CampbeII/nLK7j/
Here is a link to the site in dev:
http://squ4reone.com/domains/ottawakaraoke/Squ4reone/responsive/index.php
My script:
$(window).scroll(function () {
var navigation = $(window).scrollTop();
if (navigation > 400) {
$('#scroller').css('top',navigation - 220);
} else {
$('#scroller').css('top',183);
$('#scroller').css('position','relative');
}
});

You might want to take a look at the jQuery Waypoints plugin, it lets you do sticky elements like this and a lot more.
If you want to stick with your current method, like the other answers have indicated you should toggle fixed positioning instead of updating the .top attribute in every scroll event. However, I would also introduce a flag to track whether or not it is currently stuck, this way you are only updating the position and top attributes when it actually make the transition instead of every scroll event. Interacting with the DOM is computationally expensive, this will take a lot of load off of the layout engine and should make things even smoother.
http://jsfiddle.net/WYNcj/6/
$(function () {
var stuck = false,
stickAt = $('#scroller').offset().top;
$(window).scroll(function () {
var scrollTop = $(window).scrollTop();
if (!stuck && scrollTop > stickAt) {
$('#scroller').css('top', 0);
$('#scroller').css('position','fixed');
stuck = true;
} else if (stuck && scrollTop < stickAt) {
$('#scroller').css('top', stickAt);
$('#scroller').css('position','absolute');
stuck = false;
}
});
});
Update
Switching the #scroller from relative to fixed removes it from the normal flow of the page, this can have unintended consequences for the layout as it re-flows without the missing block. If you change #scroller to use an absolute position it will be removed from the normal flow and will no longer cause these side-effects. I've updated the above example and the linked jsfiddle to reflect the changes to the JS/CSS.
I also changed the way that stickAt is calculated as well, it uses .offset() to find the exact position of the top of #scoller instead of relying on the CSS top value.

Instead of setting the top distance at each scroll event, please consider only switching between a fixed position and an absolute or relative position.All browsers will appreciate and Especially IE.
So you still listen to scroll but you now keep a state flag out of the scroll handler and simply evaluate if it has to switch between display types.
That is so much more optimized and IE likes it.

I can get flickers in Chrome as well if I scroll very quickly. Instead of updating the top position on scroll, instead used the fixed position for your element once the page has scrolled below the threshold. Take a look at the updated fiddle: http://jsfiddle.net/nLK7j/2/

jQuery scrolling DIV is jumpy and positioned incorrectly

Not too long ago I asked about setting up a DIV which scrolls with the rest of the page. Post can be found here.
I've set this up, using the following code:
JS..
jQuery(function ($) {
var el = $('#sidebar'),
pos = el.position().top;
alert(pos);
$(window).scroll(function() {
el.toggleClass('fixed', $(this).scrollTop() >= pos);
});
});
CSS..
/* profile sidebar */
#sidebar>div{ width: 300px; margin-top: 10px; }
#sidebar.fixed>div{position:fixed;top:0}
A copy of the page can be found here. The alert was just some debugging.
The problem is, when you scroll a small amount, #sidebar suddenly appears at the very top of the page. In addition, sometimes as you scroll further down, the sidebar appears - and sometimes it doesn't.
Any idea what might be causing such seemingly random functionality?

I'm still trying to figure out why it works in the first place in the jsfiddle example, but anyway, I know how to fix it:
$(window).scroll(function() {
if($(this).scrollTop() >= pos){
el.addClass('fixed');
}else{
el.removeClass('fixed');
}
});
I tested this by unbinding the event you had and replacing it with this code. It seemed to work fine.
The reason I can't understand why it works in the example: toggleClass should be constantly adding and removing "fixed" if you have scrolled enough, because the conditional is true (true here means whether to toggle). The constant adding and removing of the fixed class causes the jumpy behavior.
You can watch this on your page: open up some dev tools (firegubg or Chrome) and watch what happens to your sidebar element.
[UPDATE]
Actually, I misread the docs. True means the class should be added (I don't think the docs are very clear though). Thus... the only way I could explain this is if #dunc was running jQuery v1.2 and the switch was getting ignored completely...