Page MenuHomePhabricator

Show edit notices within mobile editing interfaces
Closed, ResolvedPublic

Description

This task involves the work with introducing an upstream implementation to make edit notices available on mobile.

Making these edit notices available to volunteers will happen via two config changes that will happen in T316178 and T316177.

NOTE: thank you to @AlexisJazz and @Xaosflux for all the work they've been doing to write and deploy the EditNoticesOnMobile which has informed the approach described below.

Deployment timing

Ideally, this patch will deployed via backport window on 10 Oct 2023 by way of T316178: [Config Change] Make upstream mobile edit notice implementation available at all wikis.

Stories

  • As an experienced volunteer who feels responsible for the integrity of a particular page and the content contained within it, I need a way to make people who have taken an action to begin modifying said content on a mobile device aware of information they ought to consider, so that they do not unknowingly subject themselves, or the content they are modifying and/or contributing, to undesirable outcomes.
  • As someone who is seeking to modify or create content using a mobile device, I want to know whether there is information I ought to consider before making the changes I have in mind so that I do not unknowingly subject myself, or the content I am modifying and/or contributing, to undesirable outcomes.

Requirements

  • People need a way to revisit the edit notice(s) they dismissed without sacrificing the changes they have already started making

Meta

  • Editing interfaces: MobileFrontend's source and visual modes
  • Namespaces: all
  • Platform(s): Mobile
  • Skin(s): Minerva Neue
  • Project/Personal preferences: projects and individual people ought to be able to decide for themselves what implementation of mobile edit notices they see: A) the upstream implementation this ticket introduces, B) the EditNoticesOnMobile.js implementation, or C) other, yet-to-be-defined implementation(s)

User Experience (Logged in + out)

  • Whenever people tap a section- or page-level edit affordance on a page that has an edit notice set/defined:
    • People who are logged out ought to see the full-screen Warning: you are not logged in. Your IP address... modal followed by a second modal that contains the page's edit notices
    • People who are logged in ought to see the edit notice modal that contains the page's edit notices
  • Whenever people tap a section- or page-level edit affordance on a page that does NOT have an edit notice set/defined, they should not be impacted by any of the changes this ticket introduces
  • The edit notice modal ought to be a fixed height and width. If the contents of the edit notice requires more space than the fixed dimensions of the modal allow, people ought to be able to scroll the modal to reveal the content that cannot be shown within one "frame"
    • Note: the modal itself should remain in a fixed position regardless of whether people are scrolling the content within it.
  • The edit notice modal ought to contain a button that remains fixed to the bottom of it that reads OK
    • When people tap the OK button, the edit notice should disappear and people ought to see the editing interface ready for them to start making changes
  • If/when people tap a section- or page-level edit affordance on a page that has an edit notice set/defined within TBD days of last seeing said notice, they should be taken directly to the editing interface and not see the mobile edit notice modal
    • RE "TBD time window", see ===Open question #2 below.

QA

Because of the throttling of notices, you'll either need to find a new page with a notice to test each time you look at it, or you'll need to run localStorage.clear() in your browser console before loading the editor.

Open questions

  • 1. How – if at all – should we enable volunteers who create and maintain edit notices to decide whether an edit notice is: A) automatically shown to people upon entering an editing interface or B) only shown to people when they explicitly tap a button/link to reveal/show the edit notice?
    • We are going to waiting on introducing the ability for edit notice maintainers/authors to decide the above. Here is a ticket for that eventual work: T316416.
    • In the meantime, we'll seek to learn how/if people use this functionality within the EditNoticesOnMobile.js gadget.
    • This question stems from the idea @AlexisJazz raised in T312299#8076305. Also see T312999.
  • 2. For how long after seeing a mobile edit notice on a pager should people NOT see that same edit notice on that same page again?
    • @ppelberg to talk with @AlexisJazz and @Xaosflux about what they recommend for this "suppression window
    • Initially, people will see edit notices a maximum of one time per 24 hours. If/when we come to find projects would value this timing be adjusted, we'll do so.
  • 3. How – if at all – will people be able to cause the edit notice to reappear within an editing interface after already having dismissed it?
    • This initial implementation will NOT afford people to do the above. Instead, we'll consider implementing this functionality in a future iteration in T316417

Tech/News

Inspired by Wikipedia:EditNoticesOnMobile, edit notices are now available within MobileFrontend/Minerva. See more in T316178.

Done

  • ===Approaches are documented
  • ===Requirements are documented
  • @ppelberg shares the ===Approaches on en.wiki
  • Requirements are implemented
  • Announcement is made in Tech/News

Background

  1. Volunteers depend on edit notices to help people who are modifying or creating content avoid making mistakes and causing conflicts.
    • Note: at en.wiki, edit notices also deliver crucial information like discretionary sanctions information which indicate the policies applying to this page are different to other pages (e.g. you can be blocked for more minor conflicts.
  2. Edit notices are not visible to people editing on the mobile site
  3. "2." means there is a growing population of volunteers who miss out on important instructions and information

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Latest patch with {{TFA editnotice}}

image.png (872×420 px, 143 KB)

For reference, EditNoticesOnMobile is enabled on the following wikis (source: https://global-search.toolforge.org/?q=EditNoticesOnMobile&namespaces=2%2C4%2C8&title=%28Gadgets-definition%29 )

  • bn.wikipedia (not enabled by default)
  • ilo.wikipedia
  • pt.wikinews
  • shn.wikipedia
  • tum.wikipedia
  • en.wikipedia

Of these, only bn.wikipedia doesn't have it enabled by default.

For reference, EditNoticesOnMobile is enabled on the following wikis (source: https://global-search.toolforge.org/?q=EditNoticesOnMobile&namespaces=2%2C4%2C8&title=%28Gadgets-definition%29 )

  • bn.wikipedia (not enabled by default)
  • ilo.wikipedia
  • pt.wikinews
  • shn.wikipedia
  • tum.wikipedia
  • en.wikipedia

Of these, only bn.wikipedia doesn't have it enabled by default.

I wasn't even aware of most of these, cool. :-)

bnwiki started testing it about a month ago (https://en.wikipedia.org/wiki/User_talk:Alexis_Jazz#EditNoticeOnMobile), so they're probably still testing. (@Yahya probably knows more)

Edit: tumwiki recently cloned gadgets-definition from enwiki but didn't actually copy all of its gadgets: https://tum.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&action=history

Change 949545 had a related patch set uploaded (by Esanders; author: Esanders):

[operations/mediawiki-config@master] Disable upcoming wgMFShowEditNotices in production

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

Change 949545 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable upcoming wgMFShowEditNotices in production

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

Mentioned in SAL (#wikimedia-operations) [2023-08-16T20:04:36Z] <urbanecm@deploy1002> Started scap: Backport for [[gerrit:949592|Remove unusual VisualEditor config for Wikitech (T241961)]], [[gerrit:949545|Disable upcoming wgMFShowEditNotices in production (T312587)]], [[gerrit:943558|Explicitly set DiscussionToolsAutoTopicSubEditor to discussiontoolsapi]]

Mentioned in SAL (#wikimedia-operations) [2023-08-16T20:06:16Z] <urbanecm@deploy1002> esanders and urbanecm and matmarex: Backport for [[gerrit:949592|Remove unusual VisualEditor config for Wikitech (T241961)]], [[gerrit:949545|Disable upcoming wgMFShowEditNotices in production (T312587)]], [[gerrit:943558|Explicitly set DiscussionToolsAutoTopicSubEditor to discussiontoolsapi]] synced to the testservers mwdebug2001.codfw.wmnet, mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwde

Mentioned in SAL (#wikimedia-operations) [2023-08-16T20:14:04Z] <urbanecm@deploy1002> Finished scap: Backport for [[gerrit:949592|Remove unusual VisualEditor config for Wikitech (T241961)]], [[gerrit:949545|Disable upcoming wgMFShowEditNotices in production (T312587)]], [[gerrit:943558|Explicitly set DiscussionToolsAutoTopicSubEditor to discussiontoolsapi]] (duration: 09m 27s)

Change 812374 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Show edit notices

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

Current state: this is merged but disabled on all WMF wikis. If it was enabled, it would self-disable if the user has the gadget listed in the MFEditNoticesConflictingGadgetName config (EditNoticesOnMobile by default) enabled.

Demo: https://patchdemo.wmflabs.org/wikis/0250205d37/wiki/Douglas%20Adams?mobileaction=toggle_view_mobile#/editor/0

@Esanders: this is looking good. Two questions...

  1. Can we please make the "Desired adjustment" documented below?
  2. Currently, how long after seeing a mobile edit notice on a page would people see that same edit notice on that same page again? This question is related to "Open question 2." in the task description.

Current experience✅ Desired adjustmentNotes
People who are NOT logged in see the mobile edit notice atop the Warning: You are not logged in... viewPeople who are logged out ought to see the full-screen` Warning: you are not logged in. Your IP address...` modal followed by a second modal that contains the page's edit notices
IMG_8476.PNG (2×1 px, 537 KB)

Demo: https://patchdemo.wmflabs.org/wikis/0250205d37/wiki/Douglas%20Adams?mobileaction=toggle_view_mobile#/editor/0

@Esanders: this is looking good. Two questions...

  1. Can we please make the "Desired adjustment" documented below?
  2. Currently, how long after seeing a mobile edit notice on a page would people see that same edit notice on that same page again? This question is related to "Open question 2." in the task description.

I think the current behavior of ENOM is:

  1. If the user edits a page, a checksum is stored that expires after 2 weeks.
  2. If the user edits the page again (or at least, opens the edit window) >2 hours but <2 weeks after this date the expiry date resets. (within 2 hours the notice text is still cached and a whole chunk of code is skipped)
  3. If the edit notice changes (even a single letter), the stored checksum is void and the notice will be shown.
  4. The period of 1209600000ms (2 weeks) can be customized by setting window.enomCacheExpiry in one's common.js.

I don't know about the patchdemo and I'm not sure if you were referring to the patchdemo or ENOM.

The patchdemo has no way to view the notice again after dismissing it, is this correct?

@ppelberg https://phabricator.wikimedia.org/rMEXTd046bc1d44faf877e2e71cd7f46b20371ef04e32 : "Won't show an edit notice with the same key on the same page for 1 day after it has been seen." is that it?

The patchdemo has no way to view the notice again after dismissing it, is this correct?

@AlexisJazz you could run localStorage.clear() in the console.

You can see the choices made on how to display the edit notice here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/812374/18/src/mobile.editor.overlay/EditorOverlayBase.js#688

The patchdemo has no way to view the notice again after dismissing it, is this correct?

@AlexisJazz you could run localStorage.clear() in the console.

I don't think we can expect our users, especially on mobile devices, to open the browser console and enter a command to view the notice again. I wouldn't even know how to open the console on my phone.

You can see the choices made on how to display the edit notice here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/812374/18/src/mobile.editor.overlay/EditorOverlayBase.js#688

This link is unrelated to my question, correct?

I don't think we can expect our users, especially on mobile devices, to open the browser console and enter a command to view the notice again

Oh, sorry, I thought you were just asking for testing purposes on the patchdemo.

This link is unrelated to my question, correct?

I might need some clarification as to what your question was, in that case?

I don't think we can expect our users, especially on mobile devices, to open the browser console and enter a command to view the notice again

Oh, sorry, I thought you were just asking for testing purposes on the patchdemo.

This link is unrelated to my question, correct?

I might need some clarification as to what your question was, in that case?

Use case:

  1. User is presented an edit notice
  2. User dismisses edit notice
  3. User goes "wait WHAT did it say again?"
  4. User looks for button to see edit notice again to check

EditNoticesOnMobile and edit notices in VE on desktop provide this button, the current patchdemo implementation doesn't seem to. The link you provided only seems to speak about the what elements to strip from the notice itself like images and background colors.

EditNoticesOnMobile and edit notices in VE on desktop provide this button

For ENOM the button is only visible on tablet-width devices, so the vast majority of users don't see this button. I don't think this is a problem.

  1. Currently, how long after seeing a mobile edit notice on a page would people see that same edit notice on that same page again? This question is related to "Open question 2." in the task description.

It is currently set to 24 hours.

EditNoticesOnMobile and edit notices in VE on desktop provide this button

For ENOM the button is only visible on tablet-width devices, so the vast majority of users don't see this button. I don't think this is a problem.

This is partially true. When editing source (not visual), it is visible. (because there's enough room) And if you disable automatic popups it also becomes visible on narrow screens in visual mode, making the toolbar a bit crowded but whatcha gonna do.

Part of the idea was (but granted it's a bit easter egg-ish) that a user (who is in the know) could rotate their screen to reveal the button. So seeing the notice again would at least be possible, even if not terribly intuitive.

But the functionality is there. The only reason it's hidden by default on narrow screens is because of the crowding, and it would be unwise for a third party gadget to alter existing UI elements to resolve that. (ENOM adds, it avoids altering existing elements as this can cause major breakage when something changes in MediaWiki) But you don't have that problem. For example:

  1. You could add it to the source/visual switcher dropdown. And change the icon to include an exclamation mark when there's an edit notice. Or make it three dots or something, but this seems like the most logical place without overcrowding the toolbar on narrow screens.
  2. On the "Save your changes" screen, you could provide a link to review the edit notice.

As I think about this, the second method should be achievable for ENOM as well so if I can find the time I may implement that.

@ppelberg Re: Tech News (User-notice) - What wording would you suggest as the content, and when should it be included? Thanks!

Demo: https://patchdemo.wmflabs.org/wikis/0250205d37/wiki/Douglas%20Adams?mobileaction=toggle_view_mobile#/editor/0

@Esanders: this is looking good. Two questions...

  1. Can we please make the "Desired adjustment" documented below?
  2. Currently, how long after seeing a mobile edit notice on a page would people see that same edit notice on that same page again? This question is related to "Open question 2." in the task description.

I think the current behavior of ENOM is:

  1. If the user edits a page, a checksum is stored that expires after 2 weeks.
  2. If the user edits the page again (or at least, opens the edit window) >2 hours but <2 weeks after this date the expiry date resets. (within 2 hours the notice text is still cached and a whole chunk of code is skipped)
  3. If the edit notice changes (even a single letter), the stored checksum is void and the notice will be shown.
  4. The period of 1209600000ms (2 weeks) can be customized by setting window.enomCacheExpiry in one's common.js.

@AlexisJazz, thank you for sharing this context and for being patient with me in acknowledging it.

We're currently talking offline about what might be involved in making it possible for wikis to configure this threshold on a per-project basis.

@ppelberg Re: Tech News (User-notice) - What wording would you suggest as the content, and when should it be included? Thanks!

Oh, yes – thank you for the ping, @Quiddity. How do the below sound to start?

@ppelberg I think we might need to rework that a bit. Ideally a Tech News item would primarily link to a translatable documentation page (not to Enwiki), and with specifics (i.e. avoiding "soon"). I'm also confused by the last sentence as the link just points back to this task and I cannot easily see where the "timing and the wikis" is documented here (But I might be overlooking it! Long day!).
It would be good if an announcement could:

  • link to wherever this new feature is documented on mediawiki-wiki,[1] which would include details such as:
    • if editors at each wiki need to do any setup, then give them steps/checklists to go thru
    • if editors in each language need to translate any new interface strings, then provide links to translatewiki for those
    • or, if it will work with all existing Editnotices without any extra onwiki-edits, then we could just write "edit notices will be shown on mobile web". [Sidenote: I believe this is just about MobileFrontend/Minerva, and not the Mobile Apps?]
  • Provide a clear and simple timeline for when it will arrive at which wiki(s).

Timing-wise, if there's not any new onwiki setup/translation requirements, then it could be announced the same week it starts to go live.
Hope that helps!
[1] possibly it belongs at https://www.mediawiki.org/wiki/Manual:Interface/Edit_notice ?

@ppelberg I think we might need to rework that a bit. Ideally a Tech News item would primarily link to a translatable documentation page (not to Enwiki)

I just created https://meta.wikimedia.org/wiki/EditNoticesOnMobile which could be made translatable I think.

  • or, if it will work with all existing Editnotices without any extra onwiki-edits, then we could just write "edit notices will be shown on mobile web". [Sidenote: I believe this is just about MobileFrontend/Minerva, and not the Mobile Apps?]

Correct, see https://en.wikipedia.org/wiki/Wikipedia:THEYCANTHEARYOU.

@AlexisJazz, thank you for sharing this context and for being patient with me in acknowledging it.

We're currently talking offline about what might be involved in making it possible for wikis to configure this threshold on a per-project basis.

Reading again what I wrote, I think I could have been clearer about the why and the details, so here goes.

The full notice text is cached for 2 hours. This is done for two reasons: if a notice would have a different output every time it is parsed (probably a poorly designed notice) or there is a bug, the notice still won't show more than once every two hours. The second reason is simply performance, avoid unneeded traffic and parse requests when a user edits the same page multiple times within a short time period.

If the user edits the page again, "the expiry date resets". This means that if the user edits the same page every 13 days (and never resets/clears their localStorage) and the notice doesn't change, they will never see it again. The train of thought here: if the user edits the page again within 2 weeks, they are still familiar with whatever restrictions apply. If it has been more than 2 weeks, they might have forgotten. There's no need to bug a regular every day with the same notice. Also: if the same notice would be shown repeatedly this would encourage "next next next" behavior / notice fatigue / banner blindness.

If the notice has changed it is shown as new sanctions may have been introduced. When a new sanction is introduced it could take up to two hours for everyone to be able to see it (due to local caching), but this is generally not an issue as leeway is typically provided here as some editors have an edit window open for a long time before publishing. However, 24 hours may be too long for this in some instances. This is why ENOM doesn't use a simple fixed expiry.

@ppelberg I think we might need to rework that a bit. Ideally a Tech News item would primarily link to a translatable documentation page (not to Enwiki), and with specifics (i.e. avoiding "soon"). I'm also confused by the last sentence as the link just points back to this task and I cannot easily see where the "timing and the wikis" is documented here (But I might be overlooking it! Long day!).

Eek, great spots. You were not overlooking the "timing and the wikis"...I neglected to included them :o

Although, I've since updated T316178 to include both:

  • The wikis that will be impacted by this change
  • When people can expect this change to become available

It would be good if an announcement could:

  • link to wherever this new feature is documented on mediawiki-wiki,[1] which would include details such as:

On it! We're discussing what might be the most appropriate page to update. Once we've decided, we'll ensure the tech/news copy includes a link to it.

...[Sidenote: I believe this is just about MobileFrontend/Minerva, and not the Mobile Apps?]

This is accurate; this change only impacts MobileFrontend/Minerva.

  • Provide a clear and simple timeline for when it will arrive at which wiki(s).

Done in T316178's just-added Deployment Date section.

Timing-wise, if there's not any new onwiki setup/translation requirements, then it could be announced the same week it starts to go live.

Excellent.

Hope that helps!

It does! Thank you.

@ppelberg I think we might need to rework that a bit. Ideally a Tech News item would primarily link to a translatable documentation page (not to Enwiki)

I just created https://meta.wikimedia.org/wiki/EditNoticesOnMobile which could be made translatable I think.

  • or, if it will work with all existing Editnotices without any extra onwiki-edits, then we could just write "edit notices will be shown on mobile web". [Sidenote: I believe this is just about MobileFrontend/Minerva, and not the Mobile Apps?]

Correct, see https://en.wikipedia.org/wiki/Wikipedia:THEYCANTHEARYOU.

@AlexisJazz, thank you for sharing this context and for being patient with me in acknowledging it.

We're currently talking offline about what might be involved in making it possible for wikis to configure this threshold on a per-project basis.

Reading again what I wrote, I think I could have been clearer about the why and the details, so here goes.

The full notice text is cached for 2 hours. This is done for two reasons: if a notice would have a different output every time it is parsed (probably a poorly designed notice) or there is a bug, the notice still won't show more than once every two hours. The second reason is simply performance, avoid unneeded traffic and parse requests when a user edits the same page multiple times within a short time period.

If the user edits the page again, "the expiry date resets". This means that if the user edits the same page every 13 days (and never resets/clears their localStorage) and the notice doesn't change, they will never see it again. The train of thought here: if the user edits the page again within 2 weeks, they are still familiar with whatever restrictions apply. If it has been more than 2 weeks, they might have forgotten. There's no need to bug a regular every day with the same notice. Also: if the same notice would be shown repeatedly this would encourage "next next next" behavior / notice fatigue / banner blindness.

If the notice has changed it is shown as new sanctions may have been introduced. When a new sanction is introduced it could take up to two hours for everyone to be able to see it (due to local caching), but this is generally not an issue as leeway is typically provided here as some editors have an edit window open for a long time before publishing. However, 24 hours may be too long for this in some instances. This is why ENOM doesn't use a simple fixed expiry.

Thank you for sharing this additional clarity, @AlexisJazz.

In service of getting an initial version out, we're going to move forward with the 24-hour expiry that's currently implemented.

Although, as you noted above, this amount of time may be too long/short or un-nuanced for some projects. If/when we come to notice a pattern of this being true, it's likely we'll prioritize work on T347918.

QA testing note: because of the throttling of notices, you'll either need to find a new page with a notice to test each time you look at it, or you'll need to run localStorage.clear() in your browser console before loading the editor.

Ryasmeen changed the task status from Open to In Progress.Oct 3 2023, 9:45 PM

QA testing note: because of the throttling of notices, you'll either need to find a new page with a notice to test each time you look at it, or you'll need to run localStorage.clear() in your browser console before loading the editor.

Or use a private tab/window, or run:

arr=Object.keys(localStorage).filter(function(arg){return arg.match(/mf\-editnotice/)})
for(int=0;int<arr.length;int++){
		console.log('remove '+arr[int])
		mw.storage.remove(arr[int])
}

to remove only the editnotice-related localStorage entries.

Ryasmeen subscribed.

@Esanders : I checked this on patchdemo and Beta cluster, the modal looks good for pages that have edit notices on them. However, for every page that does not have any edit notice, the modal is still appearing with an empty alert.

Screenshot 2023-10-06 at 11.17.15 AM.png (1×2 px, 170 KB)

@Esanders : I checked this on patchdemo and Beta cluster, the modal looks good for pages that have edit notices on them. However, for every page that does not have any edit notice, the modal is still appearing with an empty alert.

Screenshot 2023-10-06 at 11.17.15 AM.png (1×2 px, 170 KB)

I noticed the modal is always narrow, even on wide screens with notices that span many lines, which looks rather odd and is not pleasant to read.

mf_editnotice_narrow_modal.png (1×1 px, 81 KB)

@Ryasmeen I don't see that on beta -- could you link me to a specific article that you're seeing it on?

@Ryasmeen I don't see that on beta -- could you link me to a specific article that you're seeing it on?

Sure. https://en.m.wikipedia.beta.wmflabs.org/wiki/Fire#/editor/0

Hm. Apparently something more specific is going on here, because I still don't see it happening. I've traced through, and I'm not getting any notices from the server, and the code is then correctly just not-doing-anything.

@DLynch try opening the link in a new private/incognito window, because I can reproduce that one too. Both in Firefox and Chrome.

<div class="oo-ui-windowManager oo-ui-windowManager-modal oo-ui-windowManager-floating oo-ui-windowManager-size-small"><div class="oo-ui-window oo-ui-dialog oo-ui-messageDialog oo-ui-window-active oo-ui-window-setup oo-ui-window-ready" role="dialog" aria-labelledby="ooui-1"><div class="oo-ui-window-frame" style="transition: all 0.25s ease 0s; width: 300px; height: 75.7167px;"><div class="oo-ui-window-focusTrap" tabindex="0"></div><div class="oo-ui-window-content oo-ui-dialog-content oo-ui-messageDialog-content oo-ui-window-content-setup oo-ui-window-content-ready" tabindex="-1"><div class="oo-ui-window-head"></div><div class="oo-ui-window-body" style="bottom: 45.7167px;"><div class="oo-ui-messageDialog-container oo-ui-layout oo-ui-panelLayout oo-ui-panelLayout-scrollable oo-ui-panelLayout-expanded" style=""><div class="oo-ui-messageDialog-text oo-ui-layout oo-ui-panelLayout oo-ui-panelLayout-padded"><label class="oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelWidget oo-ui-messageDialog-title" id="ooui-1"></label><label class="oo-ui-messageDialog-message oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelWidget oo-ui-labelElement"><div class="editor-overlay-editNotices"><div class="editor-overlay-editNotice"><div class="mw-editnotice-notext"><div class="editnotice-link editnotice-redlink sysop-show accountcreator-show templateeditor-show" style="clear: both; float: right; margin: 0px 0.8em; padding: 0; line-height: 1em; display: none;"> <small><a href="/w/index.php?title=Template:Editnotices/Page/Fire&amp;action=edit&amp;redlink=1" class="new" title="Template:Editnotices/Page/Fire (page does not exist)">Page notice</a></small> </div></div></div></div></label></div></div></div><div class="oo-ui-window-foot"><div class="oo-ui-messageDialog-actions oo-ui-messageDialog-actions-horizontal"><span class="oo-ui-widget oo-ui-widget-enabled oo-ui-buttonElement oo-ui-labelElement oo-ui-flaggedElement-primary oo-ui-buttonWidget oo-ui-actionWidget oo-ui-buttonElement-framed"><a class="oo-ui-buttonElement-button" role="button" tabindex="0" rel="nofollow"><span class="oo-ui-iconElement-icon oo-ui-iconElement-noIcon oo-ui-image-invert"></span><span class="oo-ui-labelElement-label">OK</span><span class="oo-ui-indicatorElement-indicator oo-ui-indicatorElement-noIndicator oo-ui-image-invert"></span></a></span></div></div></div><div class="oo-ui-window-focusTrap" tabindex="0"></div></div><div class="oo-ui-window-overlay"></div></div></div>

Wait, I also see it on https://en.m.wikipedia.beta.wmflabs.org/wiki/Wait_wut#/editor/0 which doesn't even exist!

Okay, it's because my beta-account is using mobile VE, and this only happens in wikitext mode.

This is because the path taken to create the edit notices is different between the modes -- EditorGateway's getContent method is only called in SourceEditorOverlay, and it filters the API response different from VE's methods. Specifically, the VE API filters out editnotice-notext (and editpage-head-copy-warn, but that's not relevant here), which is the message that's appearing here.

editnotice-notext is an edit notice that's set when no other edit notices are set for the page. It's empty by default, but a bunch of wikis have made it not-technically-empty but instead hidden by CSS. We should probably filter it out just like the VE API does, honestly.

Change 964146 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/MobileFrontend@master] Filter out editnotice-notext

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

(The alternative would be to load it, try to display it, and test whether it's actually taking up space before showing the dialog, I guess. This is much more fallible, but would let us show it when a wiki is actually using it for something.)

Change 964146 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Filter out editnotice-notext

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

Okay, it's because my beta-account is using mobile VE, and this only happens in wikitext mode.

This is because the path taken to create the edit notices is different between the modes -- EditorGateway's getContent method is only called in SourceEditorOverlay, and it filters the API response different from VE's methods. Specifically, the VE API filters out editnotice-notext (and editpage-head-copy-warn, but that's not relevant here), which is the message that's appearing here.

editnotice-notext is an edit notice that's set when no other edit notices are set for the page. It's empty by default, but a bunch of wikis have made it not-technically-empty but instead hidden by CSS. We should probably filter it out just like the VE API does, honestly.

You're using OO.ui.alert. Are you aware that OOUI is deprecated? T344680 https://www.mediawiki.org/wiki/OOUI

(The alternative would be to load it, try to display it, and test whether it's actually taking up space before showing the dialog, I guess. This is much more fallible, but would let us show it when a wiki is actually using it for something.)

ENOM checks for innerText.trim() to avoid showing notices with only empty tags/stylesheets/whitespace/etc. It also removes .nomobile,.editnotice-link,.editnotice-group before checking the innerText.

You're using OO.ui.alert. Are you aware that OOUI is deprecated? T344680 https://www.mediawiki.org/wiki/OOUI

Yup. The editor section of MobileFrontend is already heavily OOUI-based (even the non-VE source editor). I'd say it makes more sense to stick to the widget framework it's already using rather than mix something new in piecemeal. If it ever migrates away (questionable in any near timeframe, given VE's intense dependence on OOUI), we can sweep it all up at the same time.

(Also, I don't think there's a convenient helper like OO.ui.alert for Codex for a simple case this yet. One could assemble something from a Dialog, to be sure, but...)

ENOM checks for innerText.trim() to avoid showing notices with only empty tags/stylesheets/whitespace/etc. It also removes .nomobile,.editnotice-link,.editnotice-group before checking the innerText.

If we do add some emptiness-checking then we could look into it. My impression is that those classes come out of the whole cluster of editnotice/fmbox/etc templates rather than being part of mediawiki (so we can't count on them on all the projects), so I'd rather pick on something generic that'd trigger from the CSS applied to it if that proves viable.

@Quiddity, with the below done, can you think of anything else that needs to happen before mobile edit notice support being announced in next week's Tech/news?

  1. Mobile edit noticed were deployed today via T316178
  2. The on-wiki documentation is updated per T312587#9209218
  3. The Tech/News announcement is drafted (see task description)

ENOM checks for innerText.trim() to avoid showing notices with only empty tags/stylesheets/whitespace/etc. It also removes .nomobile,.editnotice-link,.editnotice-group before checking the innerText.

If we do add some emptiness-checking then we could look into it. My impression is that those classes come out of the whole cluster of editnotice/fmbox/etc templates rather than being part of mediawiki (so we can't count on them on all the projects), so I'd rather pick on something generic that'd trigger from the CSS applied to it if that proves viable.

Emptiness checking is done in core (https://github.com/wikimedia/mediawiki/blob/fae5d951bc7151331dfb01c5c5cd1fcef0f67f74/includes/title/Title.php#L3762). If fixes are needed it should be done there.

If fixes are needed it should be done there.

I do conceptually agree, but I think that approach also boils down to us telling the communities that they need to change how their editnotice templates work. (Because server-side sniffing for whether an HTML snippet is going to wind up being hidden by site CSS once it's displayed isn't going to work out reliably.)

I was asked to summarize the apparently-empty-notice issue:

  1. Edit notices are filtered out from the API return (at the Title level) if they output no text.
  2. Some communities use templates in their edit notices that always output some text, and then optionally hide it with CSS. (Sometimes for everyone, sometimes with classes like nomobile that only hide on MobileFrontend.)
  3. If every edit notice returned from the API is later hidden by CSS, this is going to appear as as empty popup. This would already also be the case in desktop VE's edit notice popup, though a bit less intrusively because it's not a modal.
  4. This was particularly noticeable on beta, because the editnotice-notext notice is guaranteed to be the only notice shown (because it exists for the "there are no other notices" case), and beta was hiding it with CSS rather than leaving it blank as is the default.
  5. We now filter out editnotice-notext entirely, so this requires even less common situations to occur.

Since we haven't (I believe) seen "desktop VE shows an empty edit notices popup" bug reports come in over the years that VE has been showing notices, this is presumably a pretty uncommon situation.

I was asked to summarize the apparently-empty-notice issue...

Thank you, @DLynch; I've linked this explanation on mediawiki.org.