Body padding too large, displace calculation inconsistent (IE10, IE11, and iPad2)

I think problem with this core\modules\toolbar\js\views\BodyVisualView.js

49: .css('padding-top', this.model.get('offsets').top);

But I dont found a solution yet. Have any suggestions?

Similar to this issue I bet
#2779317: Toolbar Anti-flicker adds height=400px on Boostrap theme causing a very large spacing at top of page

Im looking into it.

Also, it seems you using other modules or hacked the Drupal Core. the toolbar isn't sticky on top in my testing

You can solve this issue by using CSS:

Try below CSS code

body {
  top: 0;
  margin-top: 0;
  padding-top: 0;
}

Note: Replace selector if gap appear in other div.

Hope this helps you.

I'll take a look at this at DrupalCon Dublin 2016. Unassigned as it's been assigned for 2 months.

I've been able to replicate this issue in the MacOS simulator using 'Ipad Air 2' and I'm still struggling to find a good solution. This indeed happens when the padding is set via javascript. I tried to create a div and set the height instead, but this issue is continuing to happen. I think it may be related to how javascript is rendering in this browser. Perhaps a different way to calculate the height than is currently being used?

Going to stop working on this for now.

I can confirm this behaviour on IE10 and IE11 on Windows 7 to 8.1 (tested on Browserstack).

The values calculated for this.model.get('offsets').top in core\modules\toolbar\js\views\BodyVisualView.js are not consistent for e.g. Chrome and the above mentioned Browsers.

The calculation of this value is done in core\misc\displace.js in function getRawOffset(el, edge) (Line 159). The final value is built from placement (not consistent, see attached screenshots) and $el.outerHeight() (consistent).

Since placement is somehow wrong built by IE11 (and maybe iPad2?), these line(s) in displace.js (near line 159) should be where to look for:

// Get the offset of the element itself.
var placement = $el.offset()[horizontal ? 'left' : 'top'];
// Subtract scroll distance from placement to get the distance
// to the edge of the viewport.
placement -= window['scroll' + (horizontal ? 'X' : 'Y')] || document.documentElement['scroll' + (horizontal) ? 'Left' : 'Top'] || 0;

According to developer.mozilla.org window.scrollY is not supported in IE (except Edge):

For cross-browser compatibility, use window.pageYOffset instead of window.scrollY. Additionally, older versions of Internet Explorer (< 9) do not support either property ...

(a work around is provided on that page).

I will try to create a patch for this.

Patch with window.pageYOffset instead of window.scrollY (window.pageXOffset instead window.scrollX respectively). Tested in IE, could not test iPad.

Since it is in core/misc/displace.js setting Component to javascript.

I was able to reproduce the bug on IE9 on Windows 7 in a VM with simplytest.me. The header had to be in the fixed position to reproduce the issue. I tested in chrome 53 and firefox 49 to see if there were any adverse side-effects and there doesn't seem to be any.

Great work all!

It's not possible for this to be tested automatically due to the specific browsers on this issue.

Isn't this kind of the same problem as #2702891: Internet Explorer adds excessive padding to body when toolbar present and page resized after scroll

Both are changing same row but a bit different.

Thanks for the review and the hint at the related issue! I suggest to combine both, this should be safe and more compatible, since window.pageYOffset has wider browser support than window.scrollY and element.scrollTop. And fixing the tenary wrapping as done in the related issue is still a good idea.

This should fix this for IE, but maybe someone can test on (real) iPad?

I believe we didn't need the fallback since we remove the IE8 and below in D8.

https://github.com/jquery/jquery/blob/master/src/offset.js#L77