Page MenuHomePhabricator

Move semi-protected page warning to before edit mode on iOS app
Closed, ResolvedPublicBUG REPORT

Assigned To
Authored By
stevenwalling
Jul 25 2022, 9:40 PM
Referenced Files
F36535411: AbuseFilter triggered.png
Jan 27 2023, 10:50 PM
F36535416: Article.png
Jan 27 2023, 10:50 PM
F36535418: Blocked page.png
Jan 27 2023, 10:50 PM
F36535420: Blocked page alert.png
Jan 27 2023, 10:50 PM
F36535414: Semi-protected page.png
Jan 27 2023, 10:50 PM
F36372939: Article-1.png
Jan 20 2023, 9:03 PM
F36372937: Article.png
Jan 20 2023, 9:03 PM
F36372924: Semi-protected pages-1.png
Jan 20 2023, 9:03 PM

Description

Feature summary (what you would like to be able to do and where):

  • on the Wikipedia iOS app, you can currently enter edit mode and attempt to publish an edit on a semi-protected page
  • the warning that the edit cannot be saved (because the page is protected) happens only after you attempt to save your edit, which is super frustrating because you can put a bunch of time into an edit and then you're stuck because it can't be saved
  • This is inconsistent with the mobile web and desktop behavior, where editing is prevented before you do the work of making changes to a protected page. On desktop Vector, the edit buttons are hidden completely and you only see View Source, which is also not very new editor friendly. The best experience is probably mweb, where you see the edit button with a lock icon and a toast error message is displayed (see screenshot).
    Screen Shot 2022-07-25 at 2.34.45 PM.png (1×3 px, 2 MB)

Benefits (why should this be implemented?):

Design proposition

If a page is semi-protected the editor should see an alert right after they tap on the edit pencil icon to edit the page.

  • The alert will display a message stating that the page is semi/fully-protected.
  • To dismiss the modal the editor will be able to tap on 'OK' or tap on the 'X' icon.
  • If the editor is blocked from editing and they decide to edit a semi-protected page (they tap the edit pencil icon) the block message will appear (T275118). This block message will prevent the editor from editing the page. In this case they will not see the semi-protected alert modal right after.

Screens

Editor decides to edit a semi-protected page
Note for QA: This screen was not done; it is not technically possible. (See https://phabricator.wikimedia.org/T313772#8757317)

Editor taps to edit a semi-protected pageEditing screens open with an alertTapping 'Ok' brings the editor back to the editing screen
Article.png (667×375 px, 65 KB)
Semi-protected page.png (667×375 px, 34 KB)
Semi-protected pages-1.png (667×375 px, 63 KB)

Editor decides to edit a fully-protected page

Editor taps to edit a fully-protected pageEditing screens open with an alertTapping 'Ok' brings the editor to the editing screen that is disabledTapping on the 'X' icon takes you back to the article
Article.png (667×375 px, 65 KB)
Blocked page alert.png (667×376 px, 63 KB)
Blocked page.png (667×376 px, 87 KB)
Article.png (667×375 px, 65 KB)

Editor that is blocked tries to edit a semi-protected page

Blocked editor taps to edit a semi-protected pageBlock message appears
Article.png (667×375 px, 65 KB)
AbuseFilter triggered.png (667×376 px, 55 KB)

QA Notes

This task can be tested in TestFlight 7.3.0.

Event Timeline

(In Android we check the protection status of the article upon entering the editing workflow, and if the article is protected, we disable the edit box, i.e. you can still see the wikitext but can't edit or submit it.)

Some notes for engineering implementation:

Android call to get wikitext of a page looks like this:

https://test.wikipedia.org/w/api.php?format=json&formatversion=2&errorformat=html&errorsuselocal=1&action=query&prop=revisions|info&rvprop=content|timestamp|ids&rvlimit=1&converttitles=&intestactions=edit&intestactionsdetail=full&titles=IOS

Response looks like this:

{
  "continue": {
    "rvcontinue": "20230117211033|555591",
    "continue": "||info"
  },
  "warnings": [
    {
      "code": "deprecation",
      "html": "Because <var>rvslots</var> was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used.",
      "data": {
        "feature": "action=query&prop=revisions&!rvslots"
      },
      "module": "query+revisions"
    },
    {
      "code": "deprecation-help",
      "html": "Subscribe to the mediawiki-api-announce mailing list at &lt;<a class=\"external free\" href=\"https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/\">https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/</a>&gt; for notice of API deprecations and breaking changes. Use <a href=\"/wiki/Special:ApiFeatureUsage\" title=\"Special:ApiFeatureUsage\">Special:ApiFeatureUsage</a> to see usage of deprecated features by your application.",
      "module": "main"
    }
  ],
  "query": {
    "pages": [
      {
        "pageid": 97325,
        "ns": 0,
        "title": "IOS",
        "revisions": [
          {
            "revid": 555860,
            "parentid": 555591,
            "timestamp": "2023-01-20T16:35:12Z",
            "contentformat": "text/x-wiki",
            "contentmodel": "wikitext",
            "content": "Testing problematic links on iOS.\n\n[[google:blaäh|Test link]] - google w/ ummlat unencoded here\n\n[[google:blah|Test link]] - google with normal text\n\n[https://duckduckgo.com/?q=bla%C3%A4h&t=h_&ia=web offsite with encoded text]\n\n[https://duckduckgo.com/?q=blaäh&t=h_&ia=web offsite with unencoded text]\n\n[[Äöü|On this wiki w/ ummlat]]\n\n[[:de:COVID-19-Pandemie_in_Baden-Württemberg|On another wikipedia w/ ummlat]] - encoded URL here\n\n[https://commons.wikimedia.org/wiki/Category:COVID-19_pandemic_in_Baden-W%C3%BCrttemberg?uselang=de on commons w/ ummlat encoded]\n\n[https://commons.wikimedia.org/wiki/Category:COVID-19_pandemic_in_Baden-Württemberg?uselang=de on commons w/ ummlat unencoded]\n\n[[:en:\"Weird_Al\"_Yankovic|On another wikipedia w/ unencoded quotes]]\n\n[[:en:%22Weird_Al%22_Yankovic|On another wikipedia w/ encoded quotes]]\n\n[https://commons.wikimedia.org/wiki/File:^8_Schickelgruber._He_was_sick_two_days_last_week_-_NARA_-_535224.jpg on commons w/ caret unencoded]\n\n[https://commons.wikimedia.org/wiki/File:%5E8_Schickelgruber._He_was_sick_two_days_last_week_-_NARA_-_535224.jpg on commons w/ caret encoded]\n\n[[:en:Who's the Man?|On another Wikipedia w/ question mark unencoded]]\n\n[[:en:Who's_the_Man%3F|On another Wikipedia w/ question mark encoded]]\n\n[https://commons.wikimedia.org/wiki/File:%3Fuestionmark_white.svg on commons w/ question mark encoded]\n\n[https://commons.wikimedia.org/wiki/File:?uestionmark_white.svgon commons w/ question mark unencoded]\n\nWhy not displaying?"
          }
        ],
        "contentmodel": "wikitext",
        "pagelanguage": "en",
        "pagelanguagehtmlcode": "en",
        "pagelanguagedir": "ltr",
        "touched": "2023-01-20T16:35:12Z",
        "lastrevid": 555860,
        "length": 1497,
        "actions": {
          "edit": [
            {
              "code": "protectedpage",
              "html": "<p>This page has been protected to prevent editing or other actions.\n</p><p><br />\n</p>\n<div class=\"mw-inputbox-centered\" style=\"\"><form name=\"commentbox\" class=\"commentbox\" action=\"/w/index.php\" method=\"get\"><input type=\"hidden\" value=\"edit\" name=\"action\" /><input type=\"hidden\" name=\"preload\" /><input type=\"hidden\" name=\"editintro\" /><input type=\"hidden\" name=\"preloadtitle\" class=\"mw-inputbox-input commentboxInput mw-ui-input mw-ui-input-inline\" placeholder=\"\" size=\"50\" dir=\"ltr\" /><input type=\"hidden\" value=\"new\" name=\"section\" /><input type=\"hidden\" name=\"title\" /><br /><input type=\"submit\" name=\"create\" class=\"mw-ui-button mw-ui-progressive\" value=\"Submit an edit request\" /></form></div>"
            }
          ]
        }
      }
    ]
  }
}

Android checks if actions.edit error exists, presents html value in toast, and disables the editing on the page so that the wikitext is view-only.

Note that this behavior exists from API and and on Android regardless of protection type (e.g. for admins only, everything looks the same, as well as for autoconfirmed users only). It might be nice to eventually explain the different protection levels to the user, in case all they need to do is log in. I'm not going to explore that at this point though.

I think the plan is to do something similar for blocked users as well (warn and disable editing as soon as they land on editor, if they are blocked - T169013). So moving to Waiting while we do the pre-work for Blocked users.

Don't pick up for development until https://phabricator.wikimedia.org/T327418 work is merged.

Aklapper changed the subtype of this task from "Feature Request" to "Bug Report".Feb 17 2023, 8:26 AM

@Mazevedo I think the blocked messages (red exclamation point) portion of this task description is already done, but the remaining bits of this task will be detecting a page protection error from the fetch wikitext API response on the section editor, then displaying the error modal (use`ErrorPanelViewController` from Panels.swift) with the orange warning image.

To simplify, I propose that we display the page protection warning modal after they land on the wikitext editor, just like where we currently display the blocked error modal.

Mazevedo added a subscriber: OTichonova.

I kicked a build for this one: Wikipedia Experimental 7.3.0 (19), in case you want to review it @OTichonova

@OTichonova

Heads up, I don't think it's possible for us to both enable the editor (because the user has permissions) but also show a page protection error. If the user has high enough permissions for the page protection level, the API does not return any error text for us to display. I checked on Android and they do not seem to show this state either.

This means the "Editor decides to edit a semi-protected page" flow will just show an enabled editor with no modal (assuming their level is high enough). Please let us know if we're missing something here though, thanks!

@OTichonova

Heads up, I don't think it's possible for us to both enable the editor (because the user has permissions) but also show a page protection error. If the user has high enough permissions for the page protection level, the API does not return any error text for us to display. I checked on Android and they do not seem to show this state either.

This means the "Editor decides to edit a semi-protected page" flow will just show an enabled editor with no modal (assuming their level is high enough). Please let us know if we're missing something here though, thanks!

That's correct! If the user has the correct level of permission, the API doesn't return the page protection info we need to display the alert (with the reason for protection and the useful links, etc.).

Changes are in Testflight 7.3.0.

Tsevener updated the task description. (Show Details)