Page MenuHomePhabricator

Sections on mobile views jumps around after load (FOUC)
Closed, ResolvedPublic3 Estimated Story Points


Implementing solution 1 from T147338: Prototype solutions to avoid FOUC on section collapse
When loading a MobileFrontend page on my phone, the content is visible for a few seconds, and then the page loads and the following things happen:

  • The watch star appears below the edit (pencil) icon. [captured in blocking bug] FIXED
  • The search box changes from being empty to containing a "Search Wikipedia" placeholder. [captured in blocking bug] FIXED
  • All sections are collapsed.

Video of loading an MF page in portrait mode:

mf-portrait.gif (449Γ—283 px, 227 KB)

(Google Chrome simulating a Nexus 5 with network throttling set to regular 3G)

Video of loading that same page in portrait mode, but scrolling before loading finishes:

mf-portrait-scroll.gif (450Γ—285 px, 598 KB)

Note how the collapsing of all sections interrupts reading.

Video of loading that same page in landscape mode:

mf-landscape.gif (334Γ—596 px, 540 KB)

Note how the appearance of the watch star causes the first paragraph to reflow, pushing down the rest of the content a bit.

Reproduction Steps

  1. Go to on a mobile browser
  2. Scroll up and down through the article making a note of how section headers appear
  3. Ensure sections are collapsed by default
  4. Note if flashed of unstyled content or other issues appear on page (or while collapsing/uncollapsing sections)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Update: field research will be testing an expanded sections view relatively soon, which will inform whether we take that relatively simpler approach to addressing the flash of unstyled content instead of, for example, applying a norlq approach or its like. The practical ramification of that the remediation probably starts a sprint later.

The field research suggests users prefer the collapsed ("closed") sections to all sections expanded ("open").

Okay so with that constraint a solution would look like the following:

  • Using CSS and JS collapse all sections by default when client-js class is present.

There are a couple of problems with this:

  1. on slow connections it will not be possible to open a heading until JS finishes loading
  2. If a JS error is encountered it will never be possible to open the heading.

To counter these 2 cases we'd need to add an inline script that either opens sections after a certain period of time has elapsed or an inline script after every heading which makes the previous heading clickable.

@ovasileva please sync with @Jdlrobson on this (per prioritization meeting)

@Jdlrobson There are also all kinds of CSS-only collapse/expand (β€œaccordion”) solutions that might be worth considering as fallback solutions.

If it turns out to be technically infeasible to collapse the sections ahead of time, is there a way to at least avoid the autocollapsing when the reader is in an expanded, pre-collapsed section?

@Jdlrobson, I believe what you're saying is domContentLoaded can and does perceptibly come after a user has
(a) as of today, scrolled past the first section
(b) supposing sections were collapsed by default (not the current behavior), tapped on a section heading to expand it
and therefore JS execution necessarily would be blocked from expanding a section.

Do I understand correctly?

The CSS spike concluded we can't do this in CSS so this means we have to do this in JS.
@dr0ptp4kt you do understand correctly.

It's not impossible to do this in a nice way but it's tricky.
Options include

  1. Only loading the lead by default, loading all sections content with JS and creating a suitable fallback for viewing those sections without JS
  2. Inserting JS after every single section heading to add event handlers to them
  3. Accepting the trade off

This feels like it would benefit from some exploratory work. #3 could easily be tested in a prototype.

@Jdlrobson - sounds like we should have another spike looking at JS options

Option #3 is really a design/product decision, so I think we can rule that out as an option pretty quickly.

#1 is a large architectural decision which could easily be turned into a long term project. #2 is actionable, although is likely to be tricky.

I'd suggest starting with whether #3 is an option. I'd suggest no as on 2G it's a pretty terrible experience:

slow.gif (371Γ—913 px, 406 KB)

and if not we repurpose this card as #2 on the short term. This would look something like this - a script tag after every single section:

		$id = 'section-script-' . $sectionNumber;
		$js = 'console.log(document.getElementById("' . $id . '").previousSibling.previousSibling.onclick=function(ev) {var n = ev.currentTarget.nextSibling; if ( n.className.indexOf( "open-block" ) === -1) { n.className += " open-block"; n.onclick = null; }});';
		$script = $doc->createElement( 'script', $js );
		$script->setAttribute( 'id', $id );
		$el->appendChild( $script );

Option #4: Don't collapse sections. Bring back the ToC (styled in a useful way). This is what the apps do and with lazy loaded images being enabled now, I think it's worth it.

Edit: To clarify, keep sections collapsable, but leave them expanded by default. Flip the usage of the "expandedSections" LocalStorage feature to track which sections where collapsed instead.

Suggestion: Use <details> and <summary> elements to have native no-javascript collapsing of sections (avoiding FOUC), and then add a JS fallback for the few non-supporting browsers (Opera mini, IE mobile). This reduces the problem to a much smaller set of users.

Thanks @Yair_rand for the suggestion. Certain browsers do not render HTML5 elements without JS (e.g. IE6). @bmansurov previously dismissed this but I'd love to see a prototype of that if anyone is willing to have a go....

ovasileva set the point value for this task to 3.
phuedx removed phuedx as the assignee of this task.
phuedx updated the task description. (Show Details)
phuedx subscribed.
phuedx moved this task from Doing to To Do on the Reading-Web-Sprint-84-Zero-minutes-left board.

I seem to be spending more time reviewing and testing T147846: opened in new tab events logged incorrectly for hovercards off group in chrome. Someone should feel free to pick this up.

Change 319067 had a related patch set uploaded (by Jdlrobson):
Collapse sections by default

Update: Two hygiene patches are long and tedious but ready for review: rEMFR9efeaab8c068: Hygiene: Make use of makeSectionHtml helper and rEMFRe9e74eee19ba: Hygiene: Tests should make use of helpers

said he might be able to have a look

Thanks @Yair_rand for the suggestion. Certain browsers do not render HTML5 elements without JS (e.g. IE6).

No, this is not true. In IE6 unknown elements (e.g. HTML5 tags) do render. They just can't be the target of custom CSS styles. The contents within render fine.

Working example without any JS (note that parent A and child C render fine, including styles):

Screen Shot 2016-11-01 at 23.26.10.png (481Γ—829 px, 261 KB)

The IE6 bug with styles for B can be trivially worked around by creating a wrapper and styling the parent instead. Or shim the element by having JavaScript no-op "create" 1 instance of that element (e.g. document.createElement('summary'); in <head>).

More importantly I don't we should worry about IE6 for the mobile site. It's of minor concern as Grade C for the desktop site, but is it of concern for mobile web?

And even if you'd want things to render nicely there, as indicated above, it would fallback fine in IE6. The interactive collapse/expand wouldn't work in IE6, but that is already the case as IE6 is a Grade C browser where we don't run JavaScript - sections are expanded by default there, which would continue to be the case.

@Krinkle do you want to add those comments to T148591. They are likely to get lost here since we decided css only solutions were too complex to achieve at this time.

The two hygiene patches are merged.
rEMFR14adf55512ad: is +1ed from me after Piotr's change.
rEMFR80cb07e58587: is verified by Jenkins and needs review.

Change 319067 merged by jenkins-bot:
Collapse sections by default

I believe all of the associated patches have been merged!
/cc @bmansurov

let me add one more hygiene task

let me add one more hygiene task

The patch @pmiazga mentioned does not block signoff of this task, to be clear.

β€’ bmansurov removed Jdlrobson as the assignee of this task.

Tested section collapsing on on a 2G network with and without JS.

Is this not an important thing to QA more thoroughly via the specialist guild? I found T150237 while testing.

Also did someone confirm how it behaves on cached HTML..? I think the worse case would be sections are collapsed and cannot be expanded, which may be a necessary penalty on the long term.

I agree with @Jdlrobson - this one is a pretty big task, I think this should go through QA first and then I'd like to test it as well before signoff

This is still an issue on Android as seen in two videos I've attached for different browsers,

Web Browser for Android (globe)


Chrome on Android

This as far as I've noticed was an Android-specific situation and I haven't noticed it in Safari or Chrome on iOS 10.0.2 (iPhone).

collapsing seems to be unavailable for first section - arrow disappears

This was merged on Monday so should be live on English Wikipedia on Thursday. It can be tested in the meantime on (which is why this appears to still be an issue).
@ovasileva the bug you refer to is captured in T150237

sorry - that was my (early morning) fault - I forgot to add reproduction steps - moving back to QA

I've noticed on Web Browser for Android (globe)

and Chrome on Android that this seems to be now fixed as sections are collapsed by default and do not open without being tapped. (I haven't noticed other flashed/unstyled content issues.)

ovasileva claimed this task.

T126825#2784553 was half the work. We should have tested if sections would expand upon tapping on a slow network while the page is still loading.