Page MenuHomePhabricator

Lazy loading images breaks ResourceLoader-blacklisted JavaScript clients
Closed, ResolvedPublic5 Story Points

Description

Set your browser user agent to a custom device with user agent "Opera/9.80 (J2ME/MIDP; Opera Mini/9.80 (S60; SymbOS; Opera Mobi/23.348; U; en) Presto/2.5.25 Version/10.54"
Make sure JavaScript is enabled

Now load a page where wgLazyLoadedImages is true
The page loads without any images.

Expected: We should serve an image via some minimal JavaScript which is only run for Grade C browsers.

<noscript><img></noscript>
<script>NORLQ.push(function(){ /* trigger image load */; })</script>

See: https://etherpad.wikimedia.org/p/ImagesOnGradeCBrowsers

Details

Related Gerrit Patches:

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
DeclinedNone
OpenNone
Resolveddr0ptp4kt
DuplicateJhernandez
Duplicatedr0ptp4kt
OpenNone
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson

Event Timeline

Jdlrobson raised the priority of this task from to Normal.
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a project: MobileFrontend.
Jdlrobson updated the task description. (Show Details)Feb 16 2016, 10:04 PM
Jdlrobson set Security to None.
Jdlrobson moved this task from Backlog to Tasks on the MobileFrontend board.Feb 18 2016, 6:25 PM
dr0ptp4kt added a subscriber: dr0ptp4kt.

I'm landing this in sprint 67, but we'll be discussing next steps on lazy loading stage gating.

I recommend we figure out how to get JS-based lazy loading working for ResourceLoader impaired, yet JavaScript capable UAs. Generalizing, there are roughtly two cases: compression proxy browsers and everything else.

This is expressed in T124390: [GOAL] Load images with care as follows.

  • For UAs known to have JavaScript executed in a compression server environment (e.g., Opera Mini), iterate through all of the <div>s and make their content be <img> tags, but without qlow / chroma sub-sampling.
  • For UAs with JavaScript executed in the client, attach the logic described earlier for lazy loading images. Consider chroma sub-sampling, but not qlow.

Notice the first point explicitly acknowledges that in common compression server environments JavaScript actually does execute at the server (cf. https://dev.opera.com/articles/opera-mini-and-javascript/). In this case the trick is to make the JavaScript run so the images are in the page when the binary document is delivered to the client. Once we've put the images in place, the compression server environments and their respective clients do further adaptive compression we can get for free, as before.

Notice that the second point does not exclude ResourceLoader impaired UAs from lazy loading. It's suggesting that if there's client side JavaScript support, we ought to use lazy loading for them.

dr0ptp4kt renamed this task from No images show in Opera Mini to No images shown for ResourceLoader-blacklisted JavaScript clients.Feb 20 2016, 3:02 PM
dr0ptp4kt updated the task description. (Show Details)
Krinkle renamed this task from No images shown for ResourceLoader-blacklisted JavaScript clients to Lazy loading images breaks ResourceLoader-blacklisted JavaScript clients.Feb 20 2016, 6:11 PM
Jdlrobson set the point value for this task to 5.Feb 26 2016, 10:32 PM

We have left this in needs analysis as we need to talk about what a solution to this problem would look like. Hoping to setup a meeting with at least @Jhernandez, @Krinkle and myself.

@Krinkle and @Peter wrote down their thoughts here:
https://phabricator.wikimedia.org/T124390#1987128

The current approach shows no images for grade C browsers, but shows an image for browsers with JS disabled.
We should probably optimise for grade C browsers rather than browsers with JavaScript disabled.

We seem to have these options:
1) Do nothing (keep status quo)
Pros:

  • Works for non-js users without any penalty

Cons:

  • Grade C browsers see no images, only link.
  • There are more grade C browsers than non-js users.

**2) Follow [[ https://jmperezperez.com/medium-image-progressive-loading-placeholder/

medium example ]] and prepend a blurred thumbnail and a noscript tag. Hide the blurred thumbnail when no JavaScript

**Pros:

  • non-js users see noscript image without any penalty
  • Grade C browsers see a blurred image, depending on the level of blur may be somewhat useful for context.

Cons:

  • Larger HTML.
  • Non-javascript users make double the number of HTTP requests for images.
  • HTTP requests for images is the same (albeit paylod is lower) - note we could use data-uris at expense of HTML size to avoid HTTP requests.
  • Grade C experience is worse than non-js experience.

3) Show a blurred thumbnail and drop the noscript tag.
Pros:

  • Grade C browsers and non-js users see a blurred image, depending on the level of blur may be somewhat useful for context.
  • Both grade C and non-js experience is the same
  • No HTML size change

Cons:

  • Both grade C and non-js experience is sub-par to modern browsers running JS
  • Number of HTTP requests is the same, which may still choke really slow / older devices.

4) Inject JavaScript in the HTML for grade C browsers that loads images on window.load
e.g. window.onload = function () { var nodes = document.getElementsByTagName( 'noscript' );};

Pros:

  • Non-js still has support via noscript tag
  • Grade C browsers see the full scale images

Cons:

  • We are now supporting grade C browsers somewhat.
  • Inline JS is nasty.

I guess the question is what are we trying to achieve here. What kind of experience do we want to give grade C browsers? Do we want to give them no images, a sub par image or the full image?

CC @Nirzar @JKatzWMF I strongly recommend that Grade C browsers with JavaScript (i.e., those in the blacklist see non-degraded images, which is option 4.

As the existing bootstrapper already works for enforcing specific behavior on the relevant clients, would it make sense to just get the necessary JS loaded into the bootstrapper?

A few of us discussed this and here are the notes:
https://etherpad.wikimedia.org/p/ImagesOnGradeCBrowsers

The preference is to go ahead with solution 4 and run some minimal JavaScript embedded in the HTML for grade C browsers to load images via the ResourceLoader NORLQ object.

Jdlrobson updated the task description. (Show Details)Mar 7 2016, 7:10 PM
Jdlrobson moved this task from To Do to Doing on the Reading-Web-Sprint-67-If, Then, Else...? board.

Change 276026 had a related patch set uploaded (by Jdlrobson):
Allow us to distinguish grade C browsers from JS disabled browsers

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

Change 276052 had a related patch set uploaded (by Jdlrobson):
WIP: Add Grade C browser support

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

Patch is waiting on @Krinkle who was not sure about introducing a new class in the startup module.

Change 276026 abandoned by Jdlrobson:
Allow us to distinguish grade C browsers from JS disabled browsers

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

phuedx added a subscriber: phuedx.EditedMar 16 2016, 1:47 PM

I'd like to have a brief chat about where exactly MobileFormatter::gradeCBrowserSupport should live. Otherwise, 276026 276052 LGTM.

@phuedx I've fixed up the patch.

Change 276052 merged by jenkins-bot:
Add Grade C browser support to lazy loaded images

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