Page MenuHomePhabricator

mobile-html: Consider moving /page/metadata endpoint into mobile-html
Closed, ResolvedPublic


Background information

The /page/metadata endpoint contains information that is buildable from the mobile-html page


Consider removing the /page/metadata endpoint and adding the JS required to build it to the mobile-html page


Expose the information available via /page/metadata via new functions in pagelib.c1.Page

Open questions

Is the parsing slow enough in a mobile browser that'd it be better to download the cached, pre-processed data from the server?


Related Gerrit Patches:
mediawiki/services/mobileapps : masterMobile-html: Add meta tags indicating page protections

Event Timeline

JoeWalsh created this task.Aug 7 2019, 3:53 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 7 2019, 3:53 PM
Jhernandez added a subscriber: Jhernandez.EditedAug 13 2019, 4:17 PM

Re: Open questions, it seems like the JSON blob can be quite big, so embedding it in the HTML may have implications for the time to interactive on the browser. Scraping it from the HTML is doable and it shouldn't necessarily cause repaints/reflows that would impact performance, but it may take a chunk of main thread UI time. I'm not sure if that would have an impact on the user's interactions with the webview.

From grooming:

TOC generation could be done client side, but we are getting language links, categories and other things from the mediawiki API and bundling it there.

So moving it into mobile-html would mean the mobile-html endpoint would be slower and not improve the bandwidth usage.

Another option could be move some of the things on metadata (the ones that depend only on the parsoid HTML) to the page library JS client side. Categories, table of contents, and some of the other things could be moved. Others like language links would not, would still need language links.

It was commented that it would be interesting to make an audit of what is actually needed by apps from this service before making any decision, given there may be information we can deprecate that would help on making the right call here.

Waiting for @JoeWalsh to come back and discuss.

Jhernandez lowered the priority of this task from Medium to Low.Aug 14 2019, 3:52 PM
bearND added a subscriber: bearND.Aug 16 2019, 4:20 AM

The things we can't get from Parsoid are:

  • language links
  • protection
  • description source

I think if for language links we just need the number of language links then we could embed that in the head of mobile-html. If a user does click on the languages button then the app could make the MW API request.
Protection is fairly small.
Description source is small, too. Not even sure if the latter is needed anymore since mobile-html already provides the correct edit description header.

@bearND description source is already in /page/summary so it could be removed here. If it's easier to move language links or protections to summary I think that'd be fine as well, but I think at last check the thought was to try to remove as much from /page/summary as possible due to performance concerns

@JoeWalsh I don't see description_source in
I think we want to avoid adding more to /page/summary without the web teams consent. They use the summary endpoint for their page previews.

language links: Do we need more than just the number of language links for the footer?

@bearND ok - I was wrong, I'm not seeing the description source there either.

I believe language links were removed from the footer in the new designs in T226094 and the only way to access the language list would be through the native toolbar button. CC @cmadeo @schoenbaechler to confirm that the language links item was removed from the unified footer

@bearND + @JoeWalsh confirmed, we would like to encourage users to access languages via the toolbar button.

Do you show the number of language links in the toolbar button? If not we could probably consider delaying getting the languages list for this until the user actually clicks on it.
I'm assuming that this is relatively rare. Do we have any data showing this?

@bearND we do not show the number of language links in the toolbar button

@Mholloway language links could be requested on-demand separately by the client instead of being included in /page/metadata. Description source isn't necessary because that's checked in mobileapps services in addPageHeader.js and updates the header appropriately. Protection status could be moved into the page in a similar way to update the edit pencils - right now the clients are expected to pass it in to setEditButtons because they are pre-hidden in the hideEditButtons transform on the server.

Change 540757 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/services/mobileapps@master] Mobile-html: Add meta tags indicating page protections

Change 540757 merged by Joewalsh:
[mediawiki/services/mobileapps@master] Mobile-html: Add meta tags indicating page protections

As of the next mobileapps deployment (next Monday), any page protection will be indicated in mobile-html via meta tags (e.g., <meta property="mw:pageProtection:edit" content="autoconfirmed">), and a function to get a structured table of contents for the page will be exposed via pagelib as pagelib.c1.Page.getTableOfContents(). Per prior discussion, a raw description_source value isn't needed, categories and langlinks are straightforward MW API calls and not needed via REST API, and structured hatnotes and page issues are also not needed (and functions to parse them can be added to pagelib similar to getTableOfContents if they become necessary).

I think this means we're all set to sunset /page/metadata once the new stuff is deployed?

@Mholloway yes - all set to sunset /page/metadata. The iOS app will need page issues and hatnotes but that doesn't have to block the sunset of /page/metadata. I am working on a patch for issues and hatnotes now.

JoeWalsh closed this task as Resolved.Oct 7 2019, 3:56 PM
JoeWalsh claimed this task.