#27220 closed defect (bug) (fixed)
Twenty Fourteen - masthead-fixed does not work on IE when using header image
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 4.0 | Priority: | normal |
| Severity: | normal | Version: | 3.8.1 |
| Component: | Bundled Theme | Keywords: | has-patch commit |
| Focuses: | Cc: |
Description
Twenty Fourteen adds the
masthead-fixed
class to the #masthead element when a user begins to scroll but in Internet Explorer this is not the case if the user is using header image functionality
In Chrome the html output is
<body class="home page page-id-701 page-template page-template-template-page-with-sidebar-php custom-background group-blog header-image full-width grid masthead-fixed">
but in IE you get
<body class="home page page-id-701 page-template page-template-template-page-with-sidebar-php custom-background group-blog header-image full-width grid">
Without the header image the masthead-fixed class is added when page loads so functions as expected
Attachments (4)
Change History (16)
#2
@
11 years ago
- Keywords reporter-feedback removed
Hi Lance
Firstly if you look at Twenty Fourteen without a header imnage will see that it behaves consistently on IE, Webkit, Chrome when user scrolls up the page the menu remains in view as the 'masthead-fixed' class is added to the body class on page load. Now the bug
1) Go to Appearances >> Header and add a header image... Notice as per Ticket-27220-twentytwelve-sticky-menu-1.png in this situation the 'masthead-fixed' class is NOT added to the body class on page load.
2) Open up a Webkit browser or Chrome. As you scroll past the header image notice the 'masthead-fixed' class is added to the body class (see. Ticket-27220-twentytwelve-sticky-menu-2.png) forcing the menu to stick to the top. This is the expected behaviour
3) Now fire up IE and and repeat step no 2. As you scroll past the header image 'masthead-fixed' class is NOT added to the body class (see. Ticket-27220-twentytwelve-sticky-menu-2.png), thus, the menu never sticks to the top of the page. This is incorrect behaviour
FYI Chrome on left and IE on right on both screenshots
#3
@
11 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
#5
@
11 years ago
- Keywords has-patch added; needs-patch removed
The Bug is rather easy to fix. IE dos not support window.scrollY but as WP is using jQuery, just use $( window ).scrollTop() instead (or something like document.body.scrollTop which should also be cross-browser and probably a lot more efficient).
I've added a path with the jQuery variant fixing the bug. I hope to see this fixed in 3.9 or upcoming versions.
Here is some reference for compability: https://developer.mozilla.org/en-US/docs/Web/API/Window.scrollY
And here for performance: http://jsperf.com/jquery-el-scrolltop-vs-el-0-scrolltop/2
#6
@
11 years ago
Thanks for the patch, we'll look for after 3.9 as it's a bit too late now to make a change.
#8
@
11 years ago
- Keywords needs-testing removed
Patch works for me in IE11 Desktop & Immersive on Windows 8.1, and doesn't break Chrome or Firefox.
#10
@
11 years ago
I don't think the patch is quite right. The $( window ) call should use the local variable that is instantiated at the top of the file.
Also, the version for the JS file needs to be bumped in the functions.php file.
#11
@
11 years ago
- Owner set to lancewillett
- Resolution set to fixed
- Status changed from new to closed
In 28758:
#12
@
11 years ago
You are right @lancewillett. If there is already a stored jQuery object for window, we should use this one (haven't seen it two month ago, when I was writing the patch). It would still be better to use the document native function, but I can live with the rather costly scrollTop() function. That's why my patch had it ;-)
Hi, thanks for posting. Can you describe in more detail what the bug is? What behavior did you expect to happen?
Screenshots / screencasts to help illustrate would be very welcome.