mediawiki-skins-Vector/resources/skins.vector.legacy.js/vector.js

117 lines
4.4 KiB
JavaScript
Raw Normal View History

/**
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
* Collapsible tabs for Vector
*/
function init() {
var cactionsId = 'p-cactions',
$cactions = $( '#' + cactionsId ),
// eslint-disable-next-line no-jquery/no-global-selector
$tabContainer = $( '#p-views ul' ),
initialCactionsWidth = function () {
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
// HACK: This depends on a discouraged feature of jQuery width().
// The #p-cactions element is generally hidden by default, but
// the consumers of this function need to know the width that the
// "More" menu would consume if it were visible. This means it
// must not return 0 if hidden, but rather virtually render it
// and compute its width, then hide it again. jQuery width() does
// all that for us.
var width = $cactions.width() || 0;
initialCactionsWidth = function () {
return width;
};
return width;
};
// Bind callback functions to animate our drop down menu in and out
// and then call the collapsibleTabs function on the menu
$tabContainer
.on( 'beforeTabCollapse', function () {
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
var expandedWidth;
// If the dropdown was hidden, show it
if ( !mw.util.isPortletVisible( cactionsId ) ) {
mw.util.showPortlet( cactionsId );
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
// Now that it is visible, force-render it virtually
// to get its expanded width, then shrink it 1px before we
// yield from JS (which means the expansion won't be visible).
// Then animate from the 1px to the expanded width.
expandedWidth = $cactions.width();
// eslint-disable-next-line no-jquery/no-animate
$cactions
.css( 'width', '1px' )
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
.animate( { width: expandedWidth }, 'normal' );
}
} )
.on( 'beforeTabExpand', function () {
// If we're removing the last child node right now, hide the dropdown
if ( $cactions.find( 'li' ).length === 1 ) {
// eslint-disable-next-line no-jquery/no-animate
$cactions.animate( { width: '1px' }, 'normal', function () {
$( this ).attr( 'style', '' );
mw.util.hidePortlet( cactionsId );
} );
}
} )
.collapsibleTabs( {
expandCondition: function ( eleWidth ) {
// This looks a bit awkward because we're doing expensive queries as late
// as possible.
var distance = $.collapsibleTabs.calculateTabDistance();
// If there are at least eleWidth + 1 pixels of free space, expand.
// We add 1 because .width() will truncate fractional values but .offset() will not.
if ( distance >= eleWidth + 1 ) {
return true;
} else {
// Maybe we can still expand? Account for the width of the "Actions" dropdown
// if the expansion would hide it.
if ( $cactions.find( 'li' ).length === 1 ) {
return distance >= eleWidth + 1 - initialCactionsWidth();
} else {
return false;
}
}
},
collapseCondition: function () {
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
var collapsibleWidth = 0,
doCollapse = false;
// This looks a bit awkward because we're doing expensive queries as late
// as possible.
// TODO: The dropdown itself should probably "fold" to just the down-arrow
// (hiding the text) if it can't fit on the line?
// Never collapse if there is no overlap.
if ( $.collapsibleTabs.calculateTabDistance() >= 0 ) {
return false;
}
// Always collapse if the "More" button is already shown.
if ( mw.util.isPortletVisible( cactionsId ) ) {
return true;
}
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
// If we reach here, this means:
// 1. #p-cactions is currently empty and invisible (e.g. when logged out),
// 2. and, there is at least one li.collapsible link in #p-views, as asserted
// by handleResize() before calling here. Such link exists e.g. as
// "View history" on articles, but generally not on special pages.
// 3. and, the left-navigation and right-navigation are overlapping
// each other, e.g. when making the window very narrow, or if a gadget
// added a lot of tabs.
$tabContainer.children( 'li.collapsible' ).each( function ( _index, element ) {
collapsibleWidth += $( element ).width() || 0;
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
if ( collapsibleWidth > initialCactionsWidth() ) {
// We've found one or more collapsible links that are wider
// than the "More" menu would be if it were made visible,
// which means it is worth doing a collapsing.
doCollapse = true;
// Stop this possibly expensive loop the moment the condition is met once.
return false;
}
return;
} );
vector.js: Remove eager calculation of p-cactions width on page load With these optimisations applied, there is no longer any need for the width value during most page views, and even for most resize operations. As such, eagerly computing it ahead of time, even from an idle callback, no longer makes sense. It is still memoised because it's worth avoiding a recalc during some of the code paths that need it. Also because this way the logic stays compatible. I don't know for sure if all involved logic would be able to handle the value changing over time. Optimisations: * Where possible, don't depend on jQuery width() working on invisible elements. Specifically, don't depend on it giving you the width of the element *as if* it were visible when it is invisible. When logged-out and, when navigating special pages (e.g. Special:Blankpage), the #p-cactions element is an emptyPortlet with `display: none;` set. The animation logic was depending on initialCactionsWidth() providing the width the element would have if it were visible. This is because jQuery width(), will actually change 'display: none' to 'display: block', force render virtually, compute the width, and then change back. Instead of depending on this discouraged feature [1], move this calculation to the code dealing with the animation and calculating it there, ourselves, right after making it visible for real (but before shrinking it for the hidden-to-visible growing expansion animation). * Document our reliance on this discouraged feature for the remaining two callers in expandCondition() and collapseCondition(). Both of those need the initial width as-if visible and generally are not in charge direclty of making it visible (so there's no better place to measure it), and are in fact almost always called when the element is invisible, thus pretty much exclusively depending on it, not even as an edge case. * In collapseCondition(), optimise the logic to remember whether collapsing is needed. This way, it won't need to call initialCactionsWidth() if the loop iterated zero times (turns out to be impossible, but not obvious from the code). Follows-up 46f1d41 and 9b2bcbb. Change-Id: I6f3a5c937eb17d194a7e00ab273768a5f2cb7cd2
2019-10-02 02:18:14 +00:00
return doCollapse;
}
} );
}
module.exports = Object.freeze( { init: init } );