Page MenuHomePhabricator

Switch article footer (read more etc) to use JS injection instead of native overlay
Closed, ResolvedPublic

Description

Benefits

  • No more native overlay hackery
  • Text side slider would cause footer (read more etc) text size to scale (presently the native overlay bits don't resize)

(I have proof of concept for the injection, and also shipped a version long ago that used css for the lead image in a way that cropped properly for face detection)

Note: this wouldn't change anything visually. It would just make everything on the article be rendered via the existing article DOM.
Also we could potentiall leverage the proxy server ease the JS injection.

I attached this as a parent task to the article pinch-zoom ticket.

Related Objects

Event Timeline

Mhurd updated the task description. (Show Details)

I'd really like to work on this! :)

@Mhurd ping for potential tech debt candidate...

JMinor triaged this task as Medium priority.Mar 8 2017, 12:10 AM

Leaning towards scoping this to just the bottom native overlay for now, doing the lead image as a follow-on if needed.

Mhurd renamed this task from Switch lead image and article footer (read more etc) to use JS injection instead of native overlay to Switch article footer (read more etc) to use JS injection instead of native overlay.Apr 10 2017, 10:04 PM

@JMinor I updated the title to narrow the scope to just the footer.

I spent an hour or so this afternoon looking at my old "Read More" footer JS injection proof-of-concept and was able to get it working with the proxy server. Would need to clean and pretty it up and generalize it to server up the footer's Menu and License parts too, seems pretty straightforward.

Tap image for animation:

m.mov.gif (480×264 px, 3 MB)

@JoeWalsh regarding the proxy server proof-of-concept from the comment above, I think we may actually want to do the Read More fetch and transform in pure JS - that way we could eventually move it to "applib" (as a JS transform which just gets passed the article url) so the Android folks could use it too, or even the MCS. Could simplify things a bit as well. I'll hold off on any more exploration with this until we can chat, but I imagine a spike to implement a proof-of-concept JS transform would be pretty easy.

@JoeWalsh I got the API proxy bits working the way you suggested was able to hook up a JS transform too. I'll try to get it cleaned up tomorrow.

Testing criteria:

NOTE: these testing criteria are about the functionality of the footer. That is, the way we build the footer has changed so we want to double-check that everything in the footer still appears and responds to taps appropriately.

Footer "About this article" menu

  • Load the "enwiki > Lake Superior" article
  • Tap the table of contents icon
  • Choose "About this article" from near the bottom of the table of contents list
  • Ensure a menu appears beneath the "ABOUT THIS ARTICLE" header
  • Ensure the items in the menu respond to taps appropriately

Screen Shot 2017-05-02 at 4.33.39 PM 2.png (1×862 px, 200 KB)


Footer "Read more" items

  • Load the "enwiki > Lake Superior" article
  • Tap the table of contents icon
  • Choose "Read more" from near the bottom of the table of contents list
  • Ensure some read more articles appear beneath the "READ MORE" header
  • Ensure the read more items "Save for later" button works
NOTE: the read more cards design is undergoing tweaks - the read more cards will probably be stacked vertically instead of side-to-side as they are in the screenshot below.

Screen Shot 2017-05-02 at 4.33.39 PM.png (1×862 px, 194 KB)


Footer "Legal"

  • Load the "enwiki > Lake Superior" article
  • Scroll to the very bottom of the article
  • Ensure the "CC BY-SA 3.0" link responds to taps appropriately

Screen Shot 2017-05-02 at 4.33.39 PM 3.png (1×862 px, 192 KB)

ABorbaWMF subscribed.

Tested on an iPhone 7+ with iOS 10.3 and an iPad Mini 2 Retina on Beta App 5.5.0 (1129)

This is fixed

@Mhurd, FYI @Dbrant reports that XHRs work on our oldest Android devices!

/cc @Fjalapeno