Page MenuHomePhabricator

mobile-html page footer handling
Open, NormalPublic

Description

Background information

The apps display information in the footer of each article. It should be possible to append this footer via a js function call in mobile-html articles.

What

pagelib.c1.PageMods.appendFooter(articleTitle, menuItems, hasReadMore, readMoreItemCount, localizedStrings)

There's existing functionality in the page library for this that might be able to be adapted to work with mobile-html. The iOS app wraps the existing page library code to append the footer here:

https://github.com/wikimedia/wikipedia-ios/blob/develop/www/js/footers.js#L11

In practice, the call would look something like:

pagelib.c1.PageMods.appendFooter(
    'Knight Lore',  // articleTitle
    [pagelib.c1.MenuItemType.languages, pagelib.c1.MenuItemType.lastEdited, pagelib.c1.MenuItemType.pageIssues, pagelib.c1.MenuItemType.disambiguation, pagelib.c1.MenuItemType.talkPage],  // menuItems
    true,  // hasReadMore
    3,  // readMoreItemCount
    { 
        "readMoreHeading":"READ MORE",
        "menuDisambiguationTitle":"Similar pages",
        "menuLanguagesTitle":"Available in 9 other languages",
        "menuHeading":"ABOUT THIS ARTICLE",
        "menuLastEditedSubtitle":"Full edit history",
        "menuLastEditedTitle":"Edited today",
        "licenseString":"Content is available under $1 unless otherwise noted.",
        "menuTalkPageTitle":"View talk page",
        "menuPageIssuesTitle":"Page issues",
        "viewInBrowserString":"View article in browser",
        "licenseSubstitutionString":"CC BY-SA 3.0",
        "menuCoordinateTitle":"View on a map"
     } // localizedStrings
)

And produce something like:

Design TBD and can be iterated on after functionality is delivered, but would be ideally unified across iOS and Android T226094

The menu items are different for different articles, so all available menu item types should be supported:

const MenuItemType = {
  languages: 1,
  lastEdited: 2,
  pageIssues: 3,
  disambiguation: 4,
  coordinate: 5,
  talkPage: 6
}

There should also be an additional menu item type, references: 7 to support native references handling: T218144

Open questions

The mobile-html js would have to have a way to ask the apps whether or not the user has the related pages saved to display the appropriate bookmark state. It would also need to communicate taps on other footer items as well as save/unsave events when the user taps the save/unsave button on an article. This could be handled by the same interaction handler defined in T219998

Event Timeline

JoeWalsh created this task.Feb 28 2019, 5:27 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 28 2019, 5:27 PM
JoeWalsh added a subscriber: bearND.Mar 1 2019, 5:03 PM

@bearND I was thinking the interface for this could take two callbacks: wmf.fetchAndAppendRelatedPages(isSavedHandler, saveButtonHandler)

isSavedHandler would be a function that takes a string with an article URL

(articleURL) => { ...native message handling here... }

When receiving the isSavedHandler callback, the app would figure out whether or not that article has been saved by the user, and call:

wmf.setArticleIsSaved(articleURL, isSaved)

saveButtonHandler would be a function that takes a string with an article URL and a boolean with whether or not the user intended to save or unsave the article

(articleURL, isSaved) => { ...native message handling here... }

When receiving the saveButtonHandler callback, the app would save or unsave the article and then call:

wmf.setArticleIsSaved(articleURL, isSaved)

with the correct save state after the action is completed.

In practice on iOS this would look like

wmf.fetchAndAppendRelatedPages((articleURL) => {
    window.webkit.messageHandlers.isSavedHandler.postMessage({"articleURL": articleURL})
},
(articleURL, isSaved) => {
    window.webkit.messageHandlers.savedButtonHandler.postMessage({"articleURL": articleURL, "isSaved": isSaved})
})

Open to other suggestions if this wouldn't work on the JS side or if there's a cleaner way to do it.

bearND added a comment.Mar 5 2019, 4:37 AM

@JoeWalsh I think this should work. Thank you!

Pending discussion with the team, the save button handler part of this could be taken care of by T219998 depending on if it makes more sense to have a single interaction handler or multiple interaction handlers

LGoto triaged this task as Normal priority.Apr 10 2019, 2:50 PM

Pending discussion with the team, the save button handler part of this could be taken care of by T219998 depending on if it makes more sense to have a single interaction handler or multiple interaction handlers

@JoeWalsh is the discussion still pending? Should we discuss at App engineering sync? If not, is there anything to add to the task?

Thanks.

@MSantos this was discussed and the interaction handling portion should be part of the shared interaction handler defined in T219998. I will update the description to reflect this.

JoeWalsh updated the task description. (Show Details)Tue, Jun 18, 7:37 PM

Yes, the saved state could be handled as part of the interaction handling, in a follow up to T219998.

The main part for this task could be done independently from the interaction handling work: We still need to get the list of related pages. To do that it'll make a separate network request. That fetch could be done either shortly after the DOM is loaded or lazily when the user scrolls down close to that area.

@bearND I was thinking the fetch should happen when the clients call a method like pagelib.c1.PageMods.fetchAndAppendRelatedPages(). That way there wouldn't need to be a determination when to append the related pages, the clients could decide if and when they wanted to fetch them.

JoeWalsh renamed this task from mobile-html related pages footer handling to mobile-html page footer handling.Wed, Jun 19, 10:50 AM
JoeWalsh updated the task description. (Show Details)Wed, Jun 19, 11:03 AM
JoeWalsh updated the task description. (Show Details)Wed, Jun 19, 11:15 AM

@MSantos @bearND I updated the task description with a clearer definition of the request. Let me know if you have any questions

JoeWalsh updated the task description. (Show Details)Wed, Jun 19, 11:37 AM
bearND added a comment.EditedWed, Jun 19, 2:28 PM

@JoeWalsh Thank you for updating the description. One part is not clear to me yet. Maybe I have missed it.
Where are the readMore items coming from? Is the app providing this list or is the JS layer expected to query that?

Update: Ah, I see pagelib.c1.PageMods.fetchAndAppendRelatedPages() in your previous comment. So, the apps call pagelib.c1.PageMods.fetchAndAppendRelatedPages(domain, title), which then in turn fetches the read more titles. But then it would also have to call back to the app to get the saved state for each read more article.

@bearND JS layer would query for that - it looks like that's already in pagelib