It is not going to be possible to do this, without a visible flash of unstyled content, without also collapsing the sidebar at full width.

Given our ambitions in T302073 to make this a fly out (see prototype), it seems like doing that would be a better use of our time with a similar amount of effort?

In T316191#8196727, @Jdlrobson wrote:

It is not going to be possible to do this, without a visible flash of unstyled content, without also collapsing the sidebar at full width.

Given our ambitions in T302073 to make this a fly out (see prototype), it seems like doing that would be a better use of our time with a similar amount of effort?

@Jdlrobson - what would the flash here consist of? The sidebar opening and then collapsing? (discussing with @alexhollender_WMF and that could potentially be preferable to the issue as it currently is)

In T316191#8198838, @ovasileva wrote:

In T316191#8196727, @Jdlrobson wrote:

It is not going to be possible to do this, without a visible flash of unstyled content, without also collapsing the sidebar at full width.

Given our ambitions in T302073 to make this a fly out (see prototype), it seems like doing that would be a better use of our time with a similar amount of effort?

@Jdlrobson - what would the flash here consist of? The sidebar opening and then collapsing? (discussing with @alexhollender_WMF and that could potentially be preferable to the issue as it currently is)

Demo: https://patchdemo.wmflabs.org/wikis/dcb2317c72/wiki/Spain?useskin=vector-2022
Code would look like this:

function closePanelForSmallScreens() {
    if ( window.innerWidth < 1000 ) { $('#mw-sidebar-checkbox').prop('checked', false ); } 
}
$( closePanelForSmallScreens );
$( window ).on( 'resize', mw.util.debounce( closePanelForSmallScreens, 500 ) );

@Jdlrobson thanks for the demo. would it be possible to either:

• reduce the delay where the sidebar is full-width (before it collapses)?
• do this in the same way we do the table of contents?

reduce the delay where the sidebar is full-width (before it collapses)?

No. The delay on page load is the time it takes for the page and JS to load. It's not possible to do that any sooner. We don't know what the screen resolution of the user is until JavaScript has loaded. On resize, we need to debounce to add the delay for performance reasons.

do this in the same way we do the table of contents?

The table of contents is always collapsed by default at lower resolutions on page load. What's complicating things here is that there is a requirement that the sidebar persists state across pages for logged in user so can sometimes be open by default on page load.

I understand the difference now, thanks for clarifying.

The table of contents is always collapsed by default at lower resolutions on page load. What's complicating things here is that there is a requirement that the sidebar persists state across pages for logged in user so can sometimes be open by default on page load.

Ultimately we want this to also be true for the main menu. Regardless of logged-in/logged-out, or previous states, the main menu will always be collapsed if you are on a screen less than 1000px. I believe the thing that's preventing this from being possible currently is that we don't yet have the ability to open the main menu as a floating menu (below 1000px), as we do with the table of contents. It would work like this:

Regarding this interim solution (if we decide to go with it): I'm fine with the menu temporarily being full-width then disappearing if you resize your screen with it open, or having it flash on the screen if you load up Wikipedia on a browser below 1000px (and previously had the menu open). Neither are great, but they are preferable to what we have now.

• in the patchdemo if my screen is below 1000px and I open the menu, it closes a second later. I assume we'd be able to fix that?
• in the patchdemo if the saved state of the menu is collapsed, then I open a new window below 1000px, I don't see the flash of the menu, which is great. So to clarify the flash will be seen by people who:
  • have the main menu open + resize their screens to below 1000px (they will see the menu temporarily full-screen, then it will go away)
  • previously had the main menu open (so it's saved state is open), and open a new browser window to Wikipedia that is below 1000px (this can only affect logged-in people)

does that sound right to you?

I talked to Olga and one possible option here is to disable sidebar persistent at low resolutions (opening or closing the menu won't set a preference for the next page view). I'm hoping to have a look at this tomorrow if time allows and answer your questions.

In T316191#8199018, @Jdlrobson wrote:

In T316191#8198838, @ovasileva wrote:

In T316191#8196727, @Jdlrobson wrote:

It is not going to be possible to do this, without a visible flash of unstyled content, without also collapsing the sidebar at full width.

Given our ambitions in T302073 to make this a fly out (see prototype), it seems like doing that would be a better use of our time with a similar amount of effort?

@Jdlrobson - what would the flash here consist of? The sidebar opening and then collapsing? (discussing with @alexhollender_WMF and that could potentially be preferable to the issue as it currently is)

Demo: https://patchdemo.wmflabs.org/wikis/dcb2317c72/wiki/Spain?useskin=vector-2022
Code would look like this:

function closePanelForSmallScreens() {
    if ( window.innerWidth < 1000 ) { $('#mw-sidebar-checkbox').prop('checked', false ); } 
}
$( closePanelForSmallScreens );
$( window ).on( 'resize', mw.util.debounce( closePanelForSmallScreens, 500 ) );

NOTE: since the sidebar state is persistent, this would also mean subsequent pages would load with it closed but I don't see anyway around that.

This looks good to me given our current constraints. I'm also noticing the same issue as @alexhollender_WMF with the sidebar closing when explicitly opened. Is that just a bug with the prototype?

Change 829070 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Sidebar: Collapses at lower resolutions

https://gerrit.wikimedia.org/r/829070

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/f248c9898a/w

@alexhollender_WMF @ovasileva OKAY the patchdemo above is likely the best we're going to get this. Please take a look and let me know what you think.

In T316191#8207269, @Jdlrobson wrote:

@alexhollender_WMF @ovasileva OKAY the patchdemo above is likely the best we're going to get this. Please take a look and let me know what you think.

It looks good to me! If @alexhollender_WMF approves it as well, let's go ahead with this.

In T316191#8207269, @Jdlrobson wrote:

@alexhollender_WMF @ovasileva OKAY the patchdemo above is likely the best we're going to get this. Please take a look and let me know what you think.

looks great. I think it's definitely better than what we've got currently. thanks so much @Jdlrobson.

$( window ).on( 'resize', mw.util.debounce( closePanelForSmallScreens, 500 ) );

Using matchMedia in JS might be a possible performance improvement over listening to the resize event as it will only trigger when a change at a specific breakpoint is observed:

const mediaQuery = window.matchMedia('(min-width: 1000px)');
mediaQuery.addEventListener('change', () => console.log(window.innerWidth))

Change 829070 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Sidebar: Collapses at lower resolutions

https://gerrit.wikimedia.org/r/829070

@Jdlrobson this is looking great. Is it expected that if you have the main menu open → narrow your screen to less than 1000px (main menu automatically collapses) → then you increase the width to more than 1000px, the sidebar remains collapsed? I expect it to re-appear in that case, however if that's a limitation we have to work with here that's fine.

then you increase the width to more than 1000px, the sidebar remains collapsed? I expect it to re-appear in that case, however if that's a limitation we have to work with here that's fine.

My initial thinking here was it's more infuriating to have it reappear unexpectedly then to have the inconvenience of clicking to show it again and that if the reader is resizing the browser they probably don't need the sidebar.

It's not really a limitation, I think we could add this behavior with a bit more complexity... I just wasn't sure if it was worth it, since I don't fully understand the use case and how important the sidebar is within it.

Let me know either way.

@Jdlrobson my goal is to have as much consistency as possible between the main menu and the TOC, with regards to showing & hiding. Currently if you load an article with a window less than 1000px wide, and then expand the width of your window to more than 1000px, the TOC will appear. I think the same should be true of the main menu (assuming you have the preference saved for it in the open state). Does that make sense?

I'm fine with that work happening in a follow-up task if that's easier.

Change 832005 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Sidebar: Collapses at lower resolutions, expands when resized

https://gerrit.wikimedia.org/r/832005

Change 832005 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Sidebar: Collapses at lower resolutions, expands when resized

https://gerrit.wikimedia.org/r/832005

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Test 1
Expand sidebar
Resize browser window to 500px
✅ AC1: Expected: Sidebar should collapse

Test 2
Login
Expand side bar
Open a new window and resize it to 500px.
Load the site in the 500px window
✅ AC2: Expected: Sidebar should be collapsed (okay if this happens after a delay)

Please have a look at the comments I posted at https://phabricator.wikimedia.org/T300826#8568297.

Change 885267 had a related patch set uploaded (by Gerrit Patch Uploader; author: Anne Haunime):

[mediawiki/skins/Vector@master] Separate the fake resize event from the API save

https://gerrit.wikimedia.org/r/885267

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/f248c9898a/w/