Wikipedia talk:EditNoticesOnMobile

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

It didn't work out[edit]

Hi @Alexis Jazz, I installed it today and tried looking for editnotices on several pages but it didn't show any edit notices at all. I used a Redmi Dual 8A on both Chrome and Edge. Can you please look into it? Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 17:44, 14 May 2022 (UTC)[reply]

CX Zoom, you used script-installer. Script-installer uses the importScript() function which isn't available on mobile. That being said, something appears to have changed and notices are only half visible right now. I will look into that, but to make any script load at all on mobile you have to install it without script-installer by adding the mw.loader.load line yourself. If you're interested, I have another script that can display edit notices when commenting/editing: Bawl. It's not the same as EditNoticesOnMobile. Bawl can be used to place comments and to edit pages/sections. Edit notices can be displayed when editing/commenting with Bawl. The existing full page editor is not affected by Bawl. EditNoticesOnMobile on the other hand prepends the notice to the existing full page editor. It doesn't work when commenting (in mobile advanced mode), if you want edit notices when commenting I think Bawl is the only solution out there that can do that right now. — Alexis Jazz (talk or ping me) 19:41, 14 May 2022 (UTC)[reply]
CX Zoom, I think a class of the header changed since I wrote this script to have a fixed position.. no matter, EditNoticesOnMobile works again. With the mw.loader.load line, that is, for script-installer issues you have to bug User:Enterprisey. — Alexis Jazz (talk or ping me) 21:19, 14 May 2022 (UTC)[reply]
I had no idea that importScript, like most other features, doesn't work on mobiles. I changed it to mw.loader.load and it works nicely now. As a side request, is it possible to keep all the editnotices in a single box OR a faint grey background, something like   #f6f6f6 to separate the notices from editing area? As of now, there doesn't appear to be any separation between them. Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 05:44, 15 May 2022 (UTC)[reply]
@Alexis Jazz:: ping. —CX Zoom[he/him] (let's talk • {C•X}) 05:48, 15 May 2022 (UTC)[reply]
CX Zoom, good idea, done! — Alexis Jazz (talk or ping me) 10:39, 15 May 2022 (UTC)[reply]
@Alexis Jazz: This time it works just as expected on WP:VPP, WP:VPT & User talk:Qwerfjkl, but doesn't show up when trying to edit Joe Biden & 117th United States Congress and shows up some (css?) codes when editing WP:HD. Can you check them once? —CX Zoom[he/him] (let's talk • {C•X}) 11:13, 15 May 2022 (UTC)[reply]
CX Zoom, how odd. It's MediaWiki being weird. Nothing I can't work around though, so it should work now. — Alexis Jazz (talk or ping me) 15:37, 15 May 2022 (UTC)[reply]
@Alexis Jazz: Should've informed you earlier. The pages throwing up errors in May appear to be working as intended now, although the phab ticket remains open. Did something happen that I missed? Anyway, it looks like it works as intended on every other page too. If you don't mind, I'll be glad to open a RFC to add it to site .js because at the end of the day experienced editors who know about the tool would almost certainly know about page notice thing. It's the new ones who need it the most. —CX Zoom[he/him] (let's talk • {C•X}) 08:21, 2 July 2022 (UTC)[reply]
CX Zoom, the script works around the issue described in the phab ticket. An RFC would be very cool, I'm looking forward to it. :-) — Alexis Jazz (talk or ping me) 12:26, 2 July 2022 (UTC)[reply]
@Alexis Jazz: One (rather minor) bug I found at User:CX Zoom/TestEN. Both Group notice and Page notice is on. The Group notice comes first and the [X] alongside it does nothing. Page notice comes next and the [X] alongside it closes both the Group and Page notices at once. I think this is an unexpected behaviour. Can you look? Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 16:01, 2 July 2022 (UTC)[reply]
┌─────────────────────┘
CX Zoom, should work better now. — Alexis Jazz (talk or ping me) 04:50, 3 July 2022 (UTC)[reply]
Thanks! It does. —CX Zoom[he/him] (let's talk • {C•X}) 09:47, 3 July 2022 (UTC)[reply]

RfC initiated[edit]

Hi @Alexis Jazz, I've initiated the said RfC at Wikipedia:Village pump (proposals)#rfc_EA578B7. Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 15:14, 4 July 2022 (UTC)[reply]

Testing stuff[edit]

Follow up from VPR. @Alexis Jazz: think we can try a non-default gadget in the Testing and development section. Do you have a page ready to import to Mediawiki:Gadget-EditNoticesOnMobile.js (possibly also [[ Mediawiki:Gadget-EditNoticesOnMobile.css ?) and the loader config for MediaWiki:Gadgets-definition? — xaosflux Talk 20:42, 7 July 2022 (UTC)[reply]

Confirming before just going with what is in User:Alexis_Jazz/EditNoticesOnMobile#As_a_gadget. — xaosflux Talk 20:43, 7 July 2022 (UTC)[reply]
(I won't maintain the complaint about WMF in the comments but will certainly reference that it is workaround for that task). — xaosflux Talk 20:45, 7 July 2022 (UTC)[reply]
Xaosflux, already did that for you. Just go ahead with User:Alexis Jazz/EditNoticesOnMobile#As a gadget but leave out the "default" option. I never have a separate CSS: CSS can rarely be shared across unrelated gadgets, having CSS in another file makes development slightly harder, makes on-wiki updating more confusing/complex and creates additional network overhead. — Alexis Jazz (talk or ping me) 21:46, 7 July 2022 (UTC)[reply]
@Alexis Jazz - see multiple feedbacks below. — xaosflux Talk 00:16, 8 July 2022 (UTC)[reply]
Xaosflux, what has to be done before the script can be tested as a gadget? — Alexis Jazz (talk or ping me) 02:16, 11 July 2022 (UTC)[reply]
@Alexis Jazz looking at it now, there seem to be some confusing licensing items to look at? It appears you want to publish this as ("WTFPL Version 2" and "CC BY-SA 3.0" and "GFDL") which is OK on its own, however it appears to contains portions that are dragging along the the "MIT license" :: such that the entire code can't be made public domain? Is it just line 22 (enom.LZString=function() ...) that is being included under the other license? — xaosflux Talk 17:47, 11 July 2022 (UTC)[reply]
FWIW we do have other gadgets that incorporate MIT code (e.g. PrintOptions, libSensitiveIPs) - just trying to make sure all the licensing stuff is coordinated. — xaosflux Talk 17:51, 11 July 2022 (UTC)[reply]
Xaosflux, lz-string has two licenses. The other is WTFPL Version 2, same as EditNoticesOnMobile. I included both to be safe. Whether the MIT license is even enforcable in the US (note that Pieroxy is from France I think, WMF servers are in the US though) is unclear as WTFPL is often considered a public domain dedication. Can't have MIT if your copyright is void.. but that's an academic discussion.
CC BY-SA 3.0 and GFDL for my own work are pretty redundant to the WTFPL I provided. But yeah, sure. :-P
But you remember Wikipedia:Miscellany for deletion/MediaWiki:Gadget-afchelper.js/core.js / Wikipedia talk:Miscellany for deletion/User:Mohanad Kh/QuickEdit.js. That was about the Apache license though, MIT is (even) more permissive. — Alexis Jazz (talk or ping me) 23:50, 11 July 2022 (UTC)[reply]
Xaosflux, I clarified the situation in the code comments. Good to go? — Alexis Jazz (talk or ping me) 07:00, 12 July 2022 (UTC)[reply]
@Alexis Jazz added to testing section as non-default. — xaosflux Talk 16:52, 12 July 2022 (UTC)[reply]
  • @Alexis Jazz: I'm leaving it up since its in testing, but there seems to be something really not working - try this link to see. — xaosflux Talk 18:50, 12 July 2022 (UTC)[reply]
    • Xaosflux, thank you for adding! That link is for desktop Minerva, I'll investigate right away but as said nearly nobody uses desktop Minerva. Mobile Web is handled in a completely different manner. EditNoticesOnMobile is more or less two gadgets in one. The desktop Minerva code could be spun off into its own script easily. Actually, maybe that's not a bad idea at all. — Alexis Jazz (talk or ping me) 19:03, 12 July 2022 (UTC)[reply]
    • Xaosflux, fixed and spun off, see User:Alexis Jazz/EditNoticesOnMobile#Desktop Minerva. The desktop code is almost nothing anyway. Could be done entirely in CSS I suppose. There's no need to load the original script on desktop platforms anymore so gadgets-definition can be updated regarding that. Whether you actually install/register EditNoticesOnMobile-desktop as a gadget I don't feel too strongly about. Can't remember where to find the stats, but desktop Minerva is seriously unpopular. — Alexis Jazz (talk or ping me) 19:39, 12 July 2022 (UTC)[reply]
      @Alexis Jazz isn't it what mobile users that request desktop link get? — xaosflux Talk 20:12, 12 July 2022 (UTC)[reply]
      @Alexis Jazz synced up, see results on a page with an EN. — xaosflux Talk 20:20, 12 July 2022 (UTC)[reply]
      Xaosflux, thank you! And no, mobile editors who follow the "Desktop" link in the footer get the same skin as they would get using a desktop device. (Vector by default) It kinda just exists for testing. — Alexis Jazz (talk or ping me) 20:53, 12 July 2022 (UTC)[reply]
      Xaosflux, made some minor fixes, please sync. — Alexis Jazz (talk or ping me) 06:43, 13 July 2022 (UTC)[reply]
      @Alexis Jazz done - if you have others please just open an ER and we'll process it in queue. — xaosflux Talk 09:32, 13 July 2022 (UTC)[reply]

nomobile and useformat[edit]

The recent changes around T308401 made me think. Why does this script need to use weird hacks to disable the normal behavior of nomobile on mobile? Surely, if these edit notices are marked with that class, then they are not supposed to appear on mobile? (And would not appear anyway if the editor showed them?) Or, if they are supposed to appear on mobile, then why do they have this class? It seems to me like the problem here lies not in the bad API (bad as it is), but in the wiki content being wrong. Matma Rex talk 15:30, 7 July 2022 (UTC)[reply]

I was also wondering about this. Jdlrobson (talk) 21:46, 7 July 2022 (UTC)[reply]
Matma Rex, Jdlrobson, see Joe Biden. It uses MediaWiki:Editnotice-0 which refers to Template:Editnotice load which refers to Template:Editnotice load/content which refers to Template:Editnotices/Page/Joe Biden which refers to Template:American politics AE/Edit notice which.. oh fuck it, I have no idea. This is the problem: <div id="editnotice-area" class="nomobile editnotice-area mw-parser-output" style="clear: both; width: 100%;">. Found it, Template:Editnotice load is the culprit. No idea why that says "nomobile", I'll take a look at the history.
Edit: damnit Jdlrobson! You made me do this! You!! (I'm smiling as I type this, don't take this for an attack, but you got to see the irony here) — Alexis Jazz (talk or ping me) 01:23, 8 July 2022 (UTC)[reply]
Ummmm -- can we just take that out and fix things now? — xaosflux Talk 10:16, 8 July 2022 (UTC)[reply]
lets find out what breaks. — xaosflux Talk 13:24, 8 July 2022 (UTC)[reply]
That seems to have fixed this overall problem for full "minerva" - still got the mobilefrontend showing nothing of course. — xaosflux Talk 13:27, 8 July 2022 (UTC)[reply]
@Alexis Jazz ^--- fyi. — xaosflux Talk 13:34, 8 July 2022 (UTC)[reply]
With that seemingly resolved, hackarounds should only be if the client is using MFE, not just if they are using Minerva. — xaosflux Talk 13:39, 8 July 2022 (UTC)[reply]
Xaosflux, what's the problem exactly? Most of the nomobile/parser hacks were already removed as I discovered there's a way to get the notices in a structured fashion from the API without nomobile elements getting stripped. As you've undone Jdlrobson's nomobile addition to {{Editnotice load}} I can probably just remove the last "nomobile" reference from EditNoticesOnMobile now. — Alexis Jazz (talk or ping me) 17:05, 8 July 2022 (UTC)[reply]
Not a problem, just a note. Also, for your general directions for other projects, wouldn't Mediawiki:Mobile.js be better than Minerva.js? (Though gadget is still prob best) and this shouldn't need to run for anyone using desktop minerva? Similarly, "targets=desktop,mobile" should be able to drop the desktop part now, no? — xaosflux Talk 18:06, 8 July 2022 (UTC)[reply]
Xaosflux, I didn't know about Mobile.js! Thanks. And yes, gadget still best.
But actually no, desktop Minerva still needs it. See editing Talk:Goofy on desktop Minerva for example. This is due to skins.minerva.base.styles disabling all .tmbox and .fmbox elements, EditNoticesOnMobile fixes that too.
Market share of Minerva desktop is extremely tiny but I like to be comprehensive. — Alexis Jazz (talk or ping me) 21:54, 8 July 2022 (UTC)[reply]
Of course it does, I'm getting quite tired of MFE ..... — xaosflux Talk 22:11, 8 July 2022 (UTC)[reply]
Thank you both for tracking it down. Matma Rex talk 19:56, 9 July 2022 (UTC)[reply]
Tracked in Phabricator
Task T257394
┌───────────────────────────┘
Xaosflux, desktop Minerva actually doesn't use mw:Extension:MobileFrontend AFAIK. Disabling .tmbox and .fmbox is part of mw:Skin:Minerva Neue. But those projects are interwoven in many ways, it's often hard to tell which part is responsible for what. — Alexis Jazz (talk or ping me) 22:37, 8 July 2022 (UTC)[reply]
So much headache ... phab:T257394. — xaosflux Talk 22:48, 8 July 2022 (UTC)[reply]
Tracked in Phabricator
Task T215271
Or more likely phab:T215271 for .fmbox. — xaosflux Talk 22:54, 8 July 2022 (UTC)[reply]

Cache invalidation[edit]

This script seems to populate localStorage without any invalidation after a certain time. I suggest that these items get removed or you use session storage instead. Left unchecked, for regular editors using a single mobile device, this could very easily lead to a slowdown on viewing the site and lots of data storage. Jdlrobson (talk) 21:48, 7 July 2022 (UTC)[reply]

Jdlrobson, anything older than 12 hours does get removed when a notice is displayed. — Alexis Jazz (talk or ping me) 00:52, 8 July 2022 (UTC)[reply]

Great! I see now you have a single localStorage item and a timestamp for each entry that you iterate through. You may want to consider rewriting that code e.g. factoring out a named function called purgeCacheEntries so that it's more obvious to other gadget maintainers about what that code is doing.

Jdlrobson (talk) 00:59, 8 July 2022 (UTC)[reply]

Jdlrobson, you missed the (commented out so ResourceLoader clears it, mostly for size really, but helpful to reactivate when debugging) console.log that says "enom: removed '+Object.keys(enom.cachedNotices)[enom.cachedInt]+' from locally cached notices"? (which, together with the "entry >12 hours (43200000ms) old" comment in the line above it, should be pretty clear)
A debug function that can be toggled is nicer than commenting out console.log lines but I tried to keep this script reasonably small. Some of my other scripts have that, though. — Alexis Jazz (talk or ping me) 01:51, 8 July 2022 (UTC)[reply]
Jdlrobson, in addition to the timed invalidation I've added a hard 1M cap. It's unlikely a user would ever reach that in real life, but just in case. — Alexis Jazz (talk or ping me) 09:26, 8 July 2022 (UTC)[reply]
Jdlrobson, FYI, I made another change to the caching strategy.
  • If the editnotice for the page has never been shown on the device (or more than 48 hours ago) an API call is made and a popup gets rendered. (unless it's the first page you edit since the 48 hours expired and the notice is unchanged)
  • If the same page is edited within 2 hours of the editnotice having been downloaded/shown the notice is retrieved from localStorage without any API call. A button is shown to see it but the popup doesn't trigger automatically.
  • If the same page is edited more than 2 hours but less than 48 hours of the editnotice having been downloaded/shown, (or if it's the first page you edit since the 48 hours expired) an API call is made to retrieve the notice again, just in case it changed. If unchanged, a button is shown but no automatic popup. If the notice did change the popup also triggers.
And still the hard 1M cap of course. — Alexis Jazz (talk or ping me) 00:09, 10 July 2022 (UTC)[reply]
And now it's also compressed. — Alexis Jazz (talk or ping me) 02:14, 11 July 2022 (UTC)[reply]

Issue on PC.[edit]

@Alexis Jazz:, I'm on PC. With the script loaded, everytime I click edit on a page that has an editnotice, it briefly shows me a pop-up before continuing to the actual edit screen. It makes my editing experience on PC feel clanky and is distracting. Can you fix this? I'll include a screenshot in a moment. — PerfectSoundWhatever (t; c) 14:03, 13 July 2022 (UTC)[reply]

@Alexis Jazz - I think we should prob change targets=desktop,mobile to just mobile on the gadget - see any reason why not? — xaosflux Talk 14:18, 13 July 2022 (UTC)[reply]
PerfectSoundWhatever, presumably you're talking about desktop Minerva? Xaosflux, as I said above, "There's no need to load the original script on desktop platforms anymore so gadgets-definition can be updated regarding that". — Alexis Jazz (talk or ping me) 15:40, 13 July 2022 (UTC)[reply]
@Alexis Jazz I'm on Vector Classic — PerfectSoundWhatever (t; c) 15:44, 13 July 2022 (UTC)[reply]
PerfectSoundWhatever, you can't be, MediaWiki:Gadgets-definition says "skins=minerva".
I put the mobile+Minerva check back in the script just in case someone would try loading the script on other platforms, but as a gadget that should be prevented by MediaWiki:Gadgets-definition anyway. — Alexis Jazz (talk or ping me) 15:46, 13 July 2022 (UTC)[reply]
@Alexis Jazz I don't know what to tell you. I use vector. I'm not on my PC at the moment but I can give more information later. — PerfectSoundWhatever (t; c) 16:23, 13 July 2022 (UTC)[reply]
PerfectSoundWhatever, how did you load/enable the script? Through Special:Preferences? Because if you did that sounds like a MediaWiki bug. — Alexis Jazz (talk or ping me) 17:11, 13 July 2022 (UTC)[reply]
@Alexis Jazz I did it through the instructions on the script's doc page. Global .js file or something? Again, not on PC right now. — PerfectSoundWhatever (t; c) 17:18, 13 July 2022 (UTC)[reply]
PerfectSoundWhatever, of course. Flaw in the instructions. There is no global mobile/minerva js so there has to be a check at some point. Sorry! I added a check to both the installation instructions and the script itself. — Alexis Jazz (talk or ping me) 17:30, 13 July 2022 (UTC)[reply]
Awesome, thank you! It's fixed. — PerfectSoundWhatever (t; c) 23:35, 13 July 2022 (UTC)[reply]
PerfectSoundWhatever, btw, you said "everytime I click edit". Really? Because while you're not supposed to run the script on desktop (desktop already offers edit notices natively and the button to revisit a notice couldn't be added), it still shouldn't popup for the same notice of the same page within 48 hours. — Alexis Jazz (talk or ping me) 16:00, 13 July 2022 (UTC)[reply]
Changed to mobile-only in gadgets def. — xaosflux Talk 16:13, 13 July 2022 (UTC)[reply]

Disable option?[edit]

@Alexis Jazz: So the disable option doesn't really disable the gadget that is otherwise opt-out able, why not? Instead of trying to handle all that with more local storage, why aren't we just getting the gadget turned off here? — xaosflux Talk 22:46, 17 July 2022 (UTC)[reply]

Xaosflux, what's the problem? If you want to disable it altogether you disable it in Special:Preferences. If you want the button to review edit notices but don't want them popping up automatically you disable automatic popups within the gadget. — Alexis Jazz (talk or ping me) 22:58, 17 July 2022 (UTC)[reply]
Ah OK, forgot that the gadget is also needed to make the show-on-click button (cursed mobile front end!) — xaosflux Talk 23:34, 17 July 2022 (UTC)[reply]
Xaosflux, indeed. Btw, that automatic popup preference could be stored as an account preference, but I can imagine users wanting to disable automatic popups on their phone (especially if they only make minor edits on their phone) but not on their tablet. In addition, account preferences are not available to anons. — Alexis Jazz (talk or ping me) 17:05, 18 July 2022 (UTC)[reply]

Getting ready for launch[edit]

The RFC at Wikipedia:Village_pump_(proposals)#RfC:_Showing_Editnotices_to_mobile_editors has been closed, so it's time to get ready for launch. Since this will be a default gadget it will instantly get a very wide launch. Please add anything to this checklist that should be done in advance:

  •  Done Determine timeline to complete beta testing
  •  Done Gather any other feedback from phab:T312299
  •  Done Determine/complete any other beta testing components
  •  Done Verify there are no open bugs.
  •  Done Determine production launch strategy (number of waves, who to put in them)
  •  Done Notify phab:T312587 watchers that enwiki is moving forward with a javascript implementation
  •  Done Move documentation / support to a community page (e.g. Wikipedia:EditNoticesOnMobile?)
  •  Done Pick a launch day (Not a WP:ITSTHURSDAY)
  •  In progress Line up QA testers for launch.
  •  Done Notify int-admins (WP:IANB) and tech followers (WP:VPT) of launch
  •  Later Launch:
  •  Later Complete launch QA

Thank you! Ping to @Alexis Jazz:. — xaosflux Talk 18:57, 15 July 2022 (UTC)[reply]

Ping to User:CX Zoom. — xaosflux Talk 19:09, 15 July 2022 (UTC)[reply]
See also [SPIKE] Review EditNoticesOnMobile.js gadget and Edit notice popup suppression in Android app. (a request to the Android app developers to either implement suppression functionality from EditNoticesOnMobile or suggest something better)
The current version in userspace has an additional feature: when revisiting a notice the automatic popups can be disabled. (after confirming two warnings) This was done to alleviate concerns of experienced editors getting frustrated with frequent popups. They can be re-enabled the same way, except no confirmation is asked when re-enabling. When automatic popups are disabled the button to view a notice is no longer hidden in VE on narrow screens.
I didn't file an edit request yet because I didn't want to bother the interface admins too much and I'm still waiting for an answer from the WMF devs on another concern they had: that the notice becomes fullscreen on narrow displays. This is what mw:OOUI/Windows/Simple messages (OO.ui.confirm) does. I found no option on [1] to change that behavior. And if it's perceived as a problem it probably means the default behavior of OO.ui.confirm/alert/prompt should be adjusted. See also phab:T313140.
Another concern from the Editing Team was that the edit notice pops up over the anoneditwarning. Personally I think this is desirable (tell the user we don't care for their flat earth conspiracy theory before they bother signing up or logging in), but there is some code that can be uncommented to get the behavior the Editing Team thinks is better. (edit: Note that this outcommented code isn't thoroughly tested. In particular, because I don't want to make anon edits, I don't know if the anoneditwarning still shows if you've confirmed it once. If it only shows once adjustments would be needed.)
Besides QA testers, I'd suggest enabling for a subset of users first to see what (if any) response on WP:HD follows. Maybe admins, rollbackers or even extendedconfirmed. We can't possibly test every single browser/device out there with QA testers. Also consider Wikipedia:Village pump (technical)#Considerations for edit notices on mobile. — Alexis Jazz (talk or ping me) 19:35, 15 July 2022 (UTC)[reply]
Added "Determine production launch strategy (number of waves, who to put in them)" - good idea, we can even do "users" before we do unregistered - let's determine how many waves there should be, and what the size of them will be. We can't really do A/B testing, but can do it roughly based on groups - the big "all logged out users" one is going to be a large batch at the end. — xaosflux Talk 19:46, 15 July 2022 (UTC)[reply]
I'm thinking (but no strong feelings) to have 4 groups: admins (probably more vocal than average in reporting problems?), extendedconfirmed, users and finally unregistered with 3-7 days between each group depending on what response we see on WP:HD and similar pages. — Alexis Jazz (talk or ping me) 20:16, 15 July 2022 (UTC)[reply]
How do we line up QA testers? Request on WP:VPT maybe, or did you have something in mind? — Alexis Jazz (talk or ping me) 21:29, 15 July 2022 (UTC)[reply]
@Alexis Jazz yea, just ask from some volunteers that will notice if something is breaking. No hard-and-fast rule, just someone that isn't the implementer really. They will need a test plan (what to do - do they need actual mobile devices, just MFE browser sizes, etc??) — xaosflux Talk 23:42, 15 July 2022 (UTC)[reply]
Wikipedia:VPT#Testers wanted for EditNoticesOnMobile — Alexis Jazz (talk or ping me) 00:04, 16 July 2022 (UTC)[reply]
Users who already had (before the above request) EditNoticesOnMobile in their common.js: CX Zoom, PPelberg (WMF)/Stussll (old version), TheDJ, NightWolf1223, Samwalton9 (WMF). In global.js: Plutonical, PerfectSoundWhatever, NGC 54. No way to track who enabled the gadget, but the number can be seen on Special:GadgetUsage. Currently 3. (last updated 22:44, 13 July 2022) — Alexis Jazz (talk or ping me) 06:55, 16 July 2022 (UTC)[reply]
Xaosflux, I made the request just before midnight and 21 hours later there are.. still only 3 according to Special:GadgetUsage. Should've expected as much, ask a group and nobody feels responsible.
After the current edit request has been answered (not a massive issue but wouldn't want bug reports for a known minor issue that was already solved) I say we just activate the gadget for a first wave. If really terrible things happen (doubt it), just revert. Edit filter managers (abusefilter-modify) consists of 150 users. Seems like an okay starting number. Not so low as to risk everyone not being a mobile user/being on vacation/retired/not bothering to report severe problems while not so high that it could possibly cause severe disruption to the project even if somehow none of those 150 could use the mobile site anymore. — Alexis Jazz (talk or ping me) 18:51, 17 July 2022 (UTC)[reply]
@Alexis Jazz: thank you for drawing our attention to this discussion and for sharing the concerns we've been talking about in phab:T312299 here.
Next week, we (the Editing Team) will have two things to share with you:
1. An answer about how the size of the OO.ui.alert can be constrained so that it doesn't show up full-screen for people editing using a smartphone in portrait mode
2. When we think the implementation we're working on in phab:T312587 will be ready to be deployed
As usual, if questions/concerns surface in this discussion that you would like to ensure we are aware of, please ping me or @Whatamidoing (WMF). PPelberg (WMF) (talk) 22:16, 15 July 2022 (UTC)[reply]
PPelberg, according to matmarex the short answer to 1. is "no". The long answer is When you use OO.ui.alert(), the default size is 300px, you're currently overriding it to be wider by using size:'larger'. At 300px this wouldn't usually be a problem. But there's currently no way to make it wider than that without it becoming fullscreen when it would exceed the width of the screen.
300px ain't gonna cut it for edit notices, displays that are wider than that should be able to have a wider window. So this should be adjusted in OO.ui: phab:T313140. Also, it's not restricted to EditNoticesOnMobile. EditNoticesOnMobile will potentially increase the real-world impact of this OO.ui behavior, but really, it's not my fault. I contained the edit notice within an OO.ui dialog to address usability concerns that were voiced by Esanders. This is a usability concern with OO.ui. Well, the last and second-to-last wave won't happen tomorrow so if the WMF thinks this is important they can escalate phab:T313140 to "unbreak now".
Meanwhile, I drastically reduced localStorage use while increasing retention of recognition of unchanged notices from 2 days to 2 weeks. CRC32! And it only added ~0.3K to the min+gzip size of the script which now sits at ~4.3K. — Alexis Jazz (talk or ping me) 19:31, 16 July 2022 (UTC)[reply]
@Alexis Jazz + @Xaosflux: in short, with AlexisJazz making it so the edit notices do not cover the entirety of the editing interface for people editing with a phone in portrait mode, the Editing Team does not see any outstanding issues that we think ought to block you all from deploying the EditNoticesOnMobile gadget.
There are some additional questions and actions this deployment brings to mind for us (more on these below). Before that: we appreciate how intentional you are being about the phased rollout. This seems like an effective way of ensuring the implementation does not have undesirable consequences on people and the good faith edits they are attempting to make.
Follow up questions for you
1. Where would you value us sharing any bugs/oddities we might notice with the implementation? @Alexis Jazz: above, you mentioned monitoring WP:HD for feedback, tho maybe you'd prefer we raise any issues we notice on this talk page instead?
2. Is Wikipedia talk:EditNoticesOnMobile the page we should be watching to learn when each of the deployment "waves" happens? I ask this so that we can incorporate the deployment timing into the analysis we are planning in T313279.
3. What do you think about adding a link within the edit notice dialog to this talk page so that people who have questions/feedback know how and where to share it? We implemented a link like this in the Reply Tool and have found it to be effective way of learning about way to improve the tool.
Editing Team Next Steps
  • Decide when we will prioritize implementing an approach to introducing edit notices on mobile that can be scaled across projects. See: T313278.
  • Decide when and how we will analyze the impact that deploying the EditNoticesOnMobile gadget has had on peoples' editing behavior. See: T313279. PPelberg (WMF) (talk) 01:21, 19 July 2022 (UTC)[reply]
    • PPelberg, thank you! 1. Definitely raise issues here. I plan to monitor WP:HD and similar pages once the first wave is activated because I don't expect anyone having issues who didn't activate the gadget themselves to find this talk page. 2. Yes. 3. Your link appears to be broken but you are referring to mw:File:DiscussionTools Reply visual 2021.png. I'm not strictly against it, but it would have to be clear that it's not part of the notice itself. I really wouldn't like it if people came here to comment on notices themselves, like reporting typos in notices. The interface of EditNoticesOnMobile is very minimalistic, note how I didn't even implement a settings window. Not because I couldn't. (that nightmare is a bit less nightmarish now btw, old screenshot) DT has more room to play with. I'm open to suggestions on that front, but I'm a bit of a minimalist when it comes to this.
      that can be scaled across projects There actually isn't much enwiki-specific code in EditNoticesOnMobile. Other than translation, it should theoretically work on any project. (restyling may need some adjustments depending on templates used) — Alexis Jazz (talk or ping me) 01:52, 19 July 2022 (UTC)[reply]
      1. Definitely raise issues here. I plan to monitor WP:HD and similar pages once the first wave is activated because I don't expect anyone having issues who didn't activate the gadget themselves to find this talk page.
      Sounds good and will do.
      you are referring to mw:File:DiscussionTools Reply visual 2021.png.
      Ah yes, that's what I meant to link to. Thank you.
      I'm open to suggestions on that front, but I'm a bit of a minimalist when it comes to this.
      Understood!
      There actually isn't much enwiki-specific code in EditNoticesOnMobile. Other than translation, it should theoretically work on any project. (restyling may need some adjustments depending on templates used)
      This is helpful to know as we consider when we will prioritize work on T312587. PPelberg (WMF) (talk) 01:48, 22 July 2022 (UTC)[reply]
matmarex seemingly expressed interest in avoiding the issue instead of fixing it.
But no worries, waiting for five years without a solution isn't what I plan to do. — Alexis Jazz (talk or ping me) 21:55, 16 July 2022 (UTC)[reply]
Done. 0.2K (after min+gzip) extra for a stupid ugly hack to fix something that should have been fixed in OO.ui. — Alexis Jazz (talk or ping me) 22:58, 16 July 2022 (UTC)[reply]
What sort of timeline is appropriate to complete the 'beta testing' - there are still fixes and features being added multiple times a day right now, is there a good list of what is needed to get this to a production state yet, or is that pending the T312299 feedback? — xaosflux Talk 10:26, 17 July 2022 (UTC)[reply]
Xaosflux, there are no open issues left. I'll make a change to the outcommented code that can change the behavior for anons, but since it's currently outcommented it won't have any effect anyway. That change will be for the case of an anon pressing "edit" but not not pressing "Edit without logging in" to stop the notice from becoming cached. PPelberg agreed the community should decide on the anoneditwarning behavior,
The CRC32 checksum thing bugged me for a few days. Notices older than 2 hours were never displayed, only used for comparison. In earlier versions the notice was cached for 12 hours and served from cache for 12 hours. There was no "unchanged" check. Once I introduced that check it was kinda silly to keep holding on to the original notice text for more than 2 hours. But it's all just improvements, no showstoppers. Anyway, that's done.
I didn't expect the OO.ui window hack to be needed. I assumed that it would either be fixed by some change to the OO.ui.confirm parameters which would have a negligible ability to introduce issues or with a fix to OO.ui itself. The former is apparently impossible and unexpectedly (I am naive) matmarex expressed interest in avoiding the issue, essentially claiming that 300px ought to be enough for anybody. Thus forcing me to fix it myself.
But with that, I believe all the concerns raised in phab:T312299 are dealt with. Only the general concern of users maybe not liking edit notices remains, but I don't think there's anything more we can do about that, besides, it didn't stop the Android app developers or VE.
I have no plans for further substantial improvements. I may improve the restyling if I find something particular in a notice that would be better filtered out, but that wouldn't constitute a big change in code. EditNoticesOnMobile does a significantly better job there than VE on desktop anyway. VE is still in beta (how is VE still in beta?), but still. — Alexis Jazz (talk or ping me) 13:52, 17 July 2022 (UTC)[reply]
I sent notes to the phab tasks that we are getting ready to launch. I don't see any specific problems with it being before or after anoneditwarning - so long as anoneditwarning is displayed prior to anons editing its purpose is still achieved. — xaosflux Talk 13:38, 18 July 2022 (UTC)[reply]
Here's my idea for deployment waves: (admins, extendedconfirmed, autoconfirmed, everyone). Too many? Too few? Bad sizes? — xaosflux Talk 13:42, 18 July 2022 (UTC)[reply]
Xaosflux, that's nearly the same as my suggestion above except you swapped "users" for "autoconfirmed" which works for me. — Alexis Jazz (talk or ping me) 15:55, 18 July 2022 (UTC)[reply]
OK, so we'll use that - rolling the ball forward one more step! — xaosflux Talk 09:27, 19 July 2022 (UTC)[reply]
@Alexis Jazz scheduling time - think we are ready for wave 1 (admins) as soon as maybe tonight (2022-07-20T0000)? May want to let them bake in till Sunday or so. Assuming well, how long do you suggest between waves? — xaosflux Talk 09:31, 19 July 2022 (UTC)[reply]
Xaosflux, for the first wave maybe 4-5 days? — Alexis Jazz (talk or ping me) 12:44, 19 July 2022 (UTC)[reply]
@Alexis Jazz wave 1 (sysops) have been activated. — xaosflux Talk 23:14, 19 July 2022 (UTC)[reply]
@Alexis Jazz so are we at a block right now for more deployment, or ready to move again? — xaosflux Talk 20:03, 1 August 2022 (UTC)[reply]
Xaosflux, I just made an edit/sync request but only for two minor improvements. I'm unaware of any complaints from admins as a result of the first wave, so I think we're ready for another wave. — Alexis Jazz (talk or ping me) 23:36, 1 August 2022 (UTC)[reply]
@Alexis Jazz wave 2 (extended confirmed) has been activated. — xaosflux Talk 18:01, 2 August 2022 (UTC)[reply]
@Alexis Jazz - any thoughts on moving to wave 3 (all logged in users)? — xaosflux Talk 22:43, 16 August 2022 (UTC)[reply]
Xaosflux, I've largely been busy with another project and it's been quiet here. I've just searched for reports in WP:TEA and WP:HD and came up dry.
Seems we can move on to the next wave. — Alexis Jazz (talk or ping me) 15:17, 17 August 2022 (UTC)[reply]
@Alexis Jazz thanks, it's about to be WP:THURSDAY so will need to wait a few days - Monday 22AUG is prob a good launch day. — xaosflux Talk 15:42, 17 August 2022 (UTC)[reply]

Skip popups of certain edit notices?[edit]

There is some discussion open at Template_talk:Editnotices/Namespace/File if there are certain edit notices that should not trigger ENOM, like the one linked there. Does anyone have any issues with that? — xaosflux Talk 16:36, 21 July 2022 (UTC)[reply]

I'd like to ask that if you identify an edit notice of questionable value, then maybe just delete it for everyone. Matma Rex talk 22:17, 21 July 2022 (UTC)[reply]
@Matma Rex the examples here are namespace-wide edit notices on the File: and Category: spaces. — xaosflux Talk 23:00, 21 July 2022 (UTC)[reply]
As there have been no other comments, I'm going to add the no-popup class two the two namespace wide ones for File: and Category: for now. If we are getting a lot of bad edits from mobile users in these areas where the enot could be useful it can always be removed. — xaosflux Talk 14:41, 25 July 2022 (UTC)[reply]

Potential bug/oddity: loading experience[edit]

hi @Alexis Jazz – per the above, I'm sharing what might be a bug/oddity with the current EditNoticesOnMobile implementation...

  1. When I visit a page on a mobile device in portrait mode that contains edit notice(s). E.g. United States
  2. Tap an edit pencil
  3. The editor loads and the edit notice appears. Tho, the edit notice pop-up appears in a way that covers the editing interface. The notice then resizes itself such that the editing interface is visible behind it. Hopefully this screen recording will make the experience I'm describing easier for you to see https://www.youtube.com/shorts/m4jsjl_rrEg

Ideally, upon tapping an edit pencil, the editing interface loads and the edit notice appears in its fully-loaded form.

Please let me know if you think I can make the above more clear. PPelberg (WMF) (talk) 01:59, 22 July 2022 (UTC)[reply]

PPelberg, remember when I said Done. 0.2K (after min+gzip) extra for a stupid ugly hack to fix something that should have been fixed in OO.ui. and if you read the source SUPER STUPID SUPER UGLY HACK TO CONSTRAIN THE POPUP TO A WINDOW (see T313140)?
Well, you're looking at it. OO.ui adjusts the style attribute of the .oo-ui-window-frame div whenever a popup is created or the screen width changes. And because it's doing this using the style attribute it can't be overridden with CSS.
So whenever OO.ui changes the style attribute, a MutationObserver in ENOM detects this and changes it to a more sensible value. But I can't stop OO.ui from screwing it up in the first place. I even described the solution in phab:T313140.
It looks a bit odd on desktop, it looks somewhat more odd on your phone because your phone isn't doing the ease-in transitions. Apparently OO.ui screws up the size twice, so ENOM has to correct it twice. Without transitions that looks like flicker.
PLEASE fix OO.ui.
Edit: I tried a few other methods to hack it. Encapsulate .oo-ui-window-frame in a div with limited dimensions, limit the dimensions of the parentElement, mess with margin/padding/max-height/max-width, copy the CSS properties to another class and remove the .oo-ui-window-frame class in the vain hope of breaking OO.ui's style changes. None of it worked any better. Most of it was way worse. To reiterate: PLEASE fix OO.ui. — Alexis Jazz (talk or ping me) 08:23, 22 July 2022 (UTC)[reply]
PPelberg, this really, REALLY should be fixed in OO.ui, but of course, I shouldn't count on it..
So how does one fix a fugly hack? With more fugly hax.. Please try the current userspace version or try at beta. Taking your suggestion the editing interface loads and the edit notice appears in its fully-loaded form literally, this extra hack just hides .oo-ui-windowManager for one second before activating the popup when the screen width is <710px. Nope, 750ms wasn't enough! After one second OO.ui seems to be done with its screwery. Of course, if you change the window size or your phone orientation while the popup is being displayed, this hack has no effect, only the initial display is affected. Because this should be fixed in OO.ui.
But please test it anyway as I won't request a sync to MediaWiki namespace unless it can be confirmed to work as expected without adverse effects. I can imagine the delay being unpleasant as well, but how the hell am I supposed to prevent that? I used OO.ui to resolve accessibility concerns, now all I get is complaints about OO.ui being teh suck, I mean, what am I supposed to do here.. So how does one fix a fugly hack? With a prettier hack! (see below) — Alexis Jazz (talk or ping me) 10:56, 24 July 2022 (UTC)[reply]

If I wanted to make a OOUI dialog that doesn't go into fullscreen mode, I'd do it like this. The library is designed to be extensible by subclassing things. 

// Subclass of OO.ui.MessageDialog that never goes into fullscreen mode
function NoFullscreenMessageDialog( config ) {
	OO.ui.MessageDialog.call( this, config );
}
OO.inheritClass( NoFullscreenMessageDialog, OO.ui.MessageDialog );
// Override to never return 'full'
NoFullscreenMessageDialog.prototype.getSize = function () {
	return 'large';
};

OO.ui.getWindowManager().addWindows( { 'noFullscreenMessage': new NoFullscreenMessageDialog() } );

// Copy of OO.ui.confirm() using the customized dialog
// (you could also call openWindow() directly in your code if you find that clear enough)
function noFullscreenConfirm( text, options ) {
	return OO.ui.getWindowManager().openWindow( 'noFullscreenMessage', $.extend( {
		message: text
	}, options ) ).closed.then( function ( data ) {
		return !!( data && data.action === 'accept' );
	} );
};

noFullscreenConfirm( 'test' );

Hope that helps. There is really no reason to panic. Matma Rex talk 21:38, 24 July 2022 (UTC)[reply]

Matma Rex, that's much more helpful than "300px should cut it"! :-)
I have some concerns though. The result of your code on a narrow screen is a popup with 100% width and 1em margin from the top and bottom. Is that even enough? And I can barely follow this code. It's very confusing to me. It seems very complex for something so simple, or even: to enforce a change in behavior where the default behavior has been judged to be undesirable.
Also, it's a hack, and I think the odds of breakage with your hack are greater than with mine. If my hack breaks, it just doesn't work and the popup will be fullscreen. No biggie. Your hack enforces the "large" symbolic size. This means .oo-ui-window-frame will always have width: 700px in its style. The only reason this doesn't turn into a major disaster on narrow screens is the max-width: 100% this element also has. Of course, if a future version of OO.ui removes this max-width for optimization reasons and would start to rely solely on the width in the style, very bad things would happen.
But from that I derived a solution: the width in the style that OO.ui constantly changes can effectively be overridden with max-width. So that's how I enforce my 85% now.
So ultimately your code led me down a path that resulted in a flickerless hack. :-) — Alexis Jazz (talk or ping me) 06:07, 25 July 2022 (UTC)[reply]
Your hack is currently affecting every dialog in mobile VE, causing them to display in small windows as well (sorry, I haven't tested or read your code before). My "hack" would only affect the edit notices dialog. That is the purpose of subclassing and using the subclass, rather than overriding everything globally. Please make an effort to understand the complexity rather than just dismiss it as "confusing". Matma Rex talk 14:36, 25 July 2022 (UTC)[reply]
Matma Rex, hey, you're right, it does. I accidentally fixed the issue globally. That's pretty cool. But it causes them to display in small windows? Is 85% small? Better bump that to 90%..
So let's consider the options here.
  1. Your hack. (no quotes, you are changing OO.ui behavior in a way OO.ui doesn't expect) If you have to say one must "make an effort to understand the complexity", you're probably doing it wrong. That being said, it sorta works, but to really look like a window and ensure it can't horribly break in the future, my hack must be applied on top which kinda defeats the point.
  2. My hack, which I just improved to undo itself upon popup dismissal so VE or anything else shouldn't be affected.
  3. No hacks. Got a narrow screen? You get a fullscreen popup, just as god intended. Personally I never considered this a major issue.
  4. Set size to 'full' - wait that's the opposite of what you wanted. But I know from experience that users can get confused by non-fullscreen popups. Actually they can get confused by any popup, but not being fullscreen gives the user the illusion that the popup could somehow be ignored instead of dealt with.
  5. Abandon OO.ui. I'd really rather not, but this debacle did make me wonder if it was the right choice to begin with.
  6. Resolve phab:T313140. I ALMOST forgot to include this as an option because I think there's a very good chance many Phabricator tickets I opened will outlive me.
The best option is the one I almost forgot, but if that's not happening I think #2 is now the best option, followed by #3 or #4 with #1 and #5 sharing last place for me. — Alexis Jazz (talk or ping me) 20:18, 26 July 2022 (UTC)[reply]

Editing Team mobile edit notices implementation[edit]

hi @Alexis Jazz + @Xaosflux: on 4 August, I said that I'd be following up here about the plans the Editing Team has in mind for contributing to making edit notices available on mobile. This post is about those plans. I'm sorry it's taken me an extra week to get back to y'all.

Here's what we're thinking:

  1. In parallel to the plan you converged on to make mobile edit notice available at en.wiki, we'll offer the mobile edit notice implementation we worked on in T312587 at other wikis
  2. To ensure flexibility, as part of "1.", we'll make it so individual people and/or projects can decide what mobile edit notice experience they see: the EditNoticesOnMobile implementation, the implementation we've been working on, or an implementation that has yet to be introduced

By having two implementations available across a variety of projects, I'm thinking we'll be able to learn together what experience is most effective at making people aware of the information they ought to consider before publishing changes.

Please let me know if anything about the above brings questions/concerns to mind.

As for timing, I'm thinking that we'd start on the work to make "2." happen the week of 30 August (the week after next). Although, please let me know if that does not give you enough time to consider the above...it's important to me that we have the chance to talk before we move forward. PPelberg (WMF) (talk) 23:14, 19 August 2022 (UTC)[reply]

@PPelberg (WMF) thanks for the note; we plan to expand to our "wave 3" on Monday (all logged in editors). Ideally, I would much rather see this supported upstream than via local javascripts - primarily so that changes with other things (like skins) get accounted for. — xaosflux Talk 00:04, 20 August 2022 (UTC)[reply]
...thanks for the note; we plan to expand to our "wave 3" on Monday (all logged in editors).
You bet and noted.
Ideally, I would much rather see this supported upstream than via local javascripts - primarily so that changes with other things (like skins) get accounted for.
Understood, okay. We'd be happy to offer the upstream implementation at en.wiki as well. How do you think this ought to impact the plan I proposed above?
One idea:
  • The Editing Team moves forward with offering the upstream implementation of mobile edit notice outside of en.wiki the week of 30 August.
  • In the meantime, y'all continue with the "wave 3" gadget deployment scheduled for this Monday.
  • And then when you and @Alexis Jazz have a moment, you review the upstream implementation, see if there is anything y'all have learned from the gadget deployment that we ought to consider incorporating into it, and then from there decide whether you think the upstream implementation is ready to be made available at en.wiki.
PPelberg (WMF) (talk) 00:36, 20 August 2022 (UTC)[reply]
...the week of 30 August.
Oops. I meant the week of 29 August (30 August is a Tuesday). PPelberg (WMF) (talk) 00:58, 20 August 2022 (UTC)[reply]
@PPelberg (WMF) I'm certainly fine with these continuing in parallel for the meantime, being able to see the differences may help development on both sides. Do you have a specific phab task for your first wave of deployments? — xaosflux Talk 15:39, 21 August 2022 (UTC)[reply]
I'm certainly fine with these continuing in parallel for the meantime, being able to see the differences may help development on both sides.
@Xaosflux, well put and I agree.
Do you have a specific phab task for your first wave of deployments?
As of a few minutes ago, yes. Here are the three tickets relevant to getting the upstream mobile edit notice implementation deployed:
1. We'll use T312587 to complete the actual implementation. Note: I still need to finalize the requirements. This will happen early next week, maybe before.
2. We'll use T316178 to deploy the config change necessary to make the upstream mobile edit notice implementation available at all Wikimedia wikis except for en.wiki.
3. We'll use T316177 to deploy the config change necessary to make the upstream mobile edit notice implementation available at en.wiki. Note: while T316177 will make the upstream mobile edit notice implementation technically available at en.wiki, it will be up to you, @Alexis Jazz, and other en.wiki volunteers to ultimately decide which mobile edit experience you think would be better for people to see.
...how does the above sound to you? Does it bring any questions/concerns/ideas to mind? PPelberg (WMF) (talk) 00:49, 25 August 2022 (UTC)[reply]
PPelberg, enom.msgs should be translated on non-English projects. I'm not sure what is the most suitable way to store and retrieve translations. — Alexis Jazz (talk or ping me) 13:38, 20 August 2022 (UTC)[reply]
@Alexis Jazz as far as the inteface text itself goes, if this is being done back-end, it should be with mediawiki messages and with translatewiki. — xaosflux Talk 15:40, 21 August 2022 (UTC)[reply]
Xaosflux, I think you're right. I don't know how to effectively retrieve those though. I think ENOM would have to be extension-ized for that? — Alexis Jazz (talk or ping me) 18:24, 21 August 2022 (UTC)[reply]
@Alexis Jazz, that would be more if it were going to be an extension or part of something else upstream. I suppose for the local version, you could put all the messages (e.g. enom.msgs = {) in a .json file, read the user language setting, and then load the messages dynamically from the json, which could have a key for each language. It would still require someone to actually translate everything, so its prob not worth dealing with right now. If someone copy-pastes this in to another project, they can localize those lines to the project default language already. — xaosflux Talk 20:43, 21 August 2022 (UTC)[reply]
Xaosflux, yeah, but where does the JSON go? Would every project duplicate it? It may be more practical (as it's only a few messages) if I allow overriding enom.msgs through MediaWiki:Mobile.js. Not strictly correct (interface language should be served, not project language) but probably the easiest to maintain without going the extension route. — Alexis Jazz (talk or ping me) 22:09, 25 August 2022 (UTC)[reply]
It should certianly not be dependant on mobile.js. If this becomes an extension, the messages will just each be a mediawiki page, with automatic language selection. — xaosflux Talk 22:56, 25 August 2022 (UTC)[reply]
Xaosflux, as an extension yes, but when it isn't an extension? And it wouldn't depend on it, the English default would still be included. Using Mobile.js would serve as an alternative to If someone copy-pastes this in to another project, they can localize those lines to the project default language already., allowing localized messages to be loaded without altering the original script. — Alexis Jazz (talk or ping me) 06:02, 26 August 2022 (UTC)[reply]
@Alexis Jazz A simple solution could be to tell them where to put an override messages file (e.g. MediaWiki:Gadget-EditNoticesOnMobile.js/i18n.js) and just import it in if it exists). Having to put message variables in a site-wide script like mobile.js isn't recommended. — xaosflux Talk 09:43, 26 August 2022 (UTC)[reply]

Final wave[edit]

Notice, final eave (all users) released today. Please report any issues. — xaosflux Talk 19:01, 14 September 2022 (UTC)[reply]

Error at module space[edit]

Hi @Alexis Jazz: While editing Module:Section sizes on mobile, I saw an editnotice pop up that showed me the documentation of the module, and below that, was the following:

Script error: Lua error at line 1: unexpected symbol near '<'.

1<div id="EditNoticeOnMobile">{{#ifexist:MediaWiki:Editnotice-{{NAMESPACENUMBER}}-Section sizes|{{MediaWiki:Editnotice-{{NAMESPACENUMBER}}-Section sizes}}|{{#ifexist:MediaWiki:Editnotice-{{NAMESPACENUMBER}}|{{MediaWiki:Editnotice-{{NAMESPACENUMBER}}}}}}}}</div><div id="enom_end"></div>

The message was syntax highlighted, and the entire second line was nowrapped. Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 07:34, 17 October 2022 (UTC)[reply]

CX Zoom, interesting. I specified the contentmodel for the parse request and requested MediaWiki talk:Gadget-EditNoticesOnMobile.js#Edit request 17 October 2022. This should resolve the issue. — Alexis Jazz (talk or ping me) 11:11, 17 October 2022 (UTC)[reply]
Thanks, will look at it when the request is completed. —CX Zoom[he/him] (let's talk • {C•X}) 11:18, 17 October 2022 (UTC)[reply]

Notice next to search[edit]

Hi @Alexis Jazz:. Step-by-step to reproduce the error:

  • Go to Kim Jong-un page (logged out);
  • Click to edit;
  • Click "OK" on the notice;
  • Click to search;
  • You should see an additional "X", which when clicked, displays the warning. Edu! (talk) 01:00, 3 November 2022 (UTC)[reply]
    • Edu!, your ping arrived but I overlooked it as I got many notifications in that period.
      The issue should be resolved soon. — Alexis Jazz (talk or ping me) 21:12, 5 December 2022 (UTC)[reply]

Production error [object Object] error occurring for Mobile Safari users[edit]

English Wikipedia had 302 errors of this form over the past 7 days. The stack trace is pretty useless, but every instance of this error occurs with this gadget installed and users using Mobile Safari on the English Wikipedia mobile domain.

All users were logged in - not sure if that's significant?

Sample user agent: Mozilla/5.0 (Linux; Android 11; SM-A305F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Mobile Safari/537.36

Pages this occurred on:


Let me know if I can help with any further information and thanks in advance for looking into this. Jdlrobson (talk) 20:10, 6 February 2023 (UTC)[reply]

Jdlrobson, this page probably isn't actively watched so pinging someone might be a good idea when reporting here. Due to personal issues I've reduced my activity on Wikimedia, but even if that wasn't the case I hardly ever check my watchlist anymore. Regarding the issue itself, as the script author, it appears that according to https://www.lifewire.com/activate-the-debug-console-in-safari-445798 I need an iPhone (I have a few old models) and a Mac. I know a family member who has a 2011 Macbook I think, but the last time I used it I almost went mad - I hate MacOS. I'd prefer for someone else to gather more information on this and provide reproduction steps to absolutely minimize the time I need to spend on MacOS. That is assuming the issue can be reproduced at all with older Apple hardware.
Another thought: the gadget is enabled by default for everyone, including anons, so are you absolutely sure this is the culprit? Can you reproduce the issue? Does the issue go away when you disable the gadget? It seems more likely the culprit would be a gadget that isn't loaded for anons but is loaded by default (or very popular) for users who are logged in.
Also, the user agent confuses me. Safari (web browser) does not run on Android 11 AFAIK. Not seeing it in the Google Play store. — Alexis Jazz (talk or ping me) 05:12, 30 March 2023 (UTC)[reply]
> the gadget is enabled by default for everyone, including anons, so are you absolutely sure this is the culprit? Can you reproduce the issue? Does the issue go away when you disable the gadget? It seems more likely the culprit would be a gadget that isn't loaded for anons but is loaded by default (or very popular) for users who are logged in.
I'm not 100% sure it's the culprit, no, but seems likely. The error only occurs on en.m.wikipedia.org. It doesn't occur on any of our other projects, so that tells me it's definitely a gadget or site script (if it was a browser extension I'd expect a few errors from anonymous users). It's happening for only logged in users and given we log the gadgets that are enabled for these users, it seems all the errors occur with one of the following gadgets enabled: "confirmationRollback-mobile,EditNoticesOnMobile,switcher". If it was pulling in a script via common.js/minerva.js that would tell us the file URL, so it's not that. So that narrows it down to those 4 gadgets and/or MediaWiki:Mobile.js. The latter is blank, so it must be one of those gadgets. Given EditNoticesOnMobile is the considerably more complex of those, and also has some obfuscation in the JS, I'm guessing it's the source.
> Also, the user agent confuses me. Safari (web browser) does not run on Android 11 AFAIK. Not seeing it in the Google Play store.
You are right. I misread the user agent. Looking now, this is most commonly occurring on Android 11 Chrome 104.
> Can you reproduce the issue?
I'm not familiar with how this gadget works, so wasn't able to exploratory test it and replicate it. I'm seeing 4 instances on Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 so that's probably ythe best place for you to replicate it, (if you have Linux).
> I'd prefer for someone else to gather more information on this and provide reproduction steps to absolutely minimize the time I need to spend on MacOS.
That's fine. It's just a curiosity at this point. I was just posting in case there was something obvious here. The error rate is not high enough for us to worry about this too much. If it was to go considerably higher, I'd invest more of my own time in trying to work out what's happening here. Jdlrobson (talk) 21:17, 4 April 2023 (UTC)[reply]
Jdlrobson, not seeing problems with Chromium 108 on Linux. No 111 in my distro yet, but as it happened on 104 on mobile I'm not sure it would matter. Maybe it only happens when users press a specific button or hover somewhere. Nothing to do until there are reproduction steps. — Alexis Jazz (talk or ping me) 19:43, 8 April 2023 (UTC)[reply]
Jdlrobson, I'm still curious though. The list of current UFC fighters doesn't even have an edit notice which would mean a significant part of the script would be skipped. And most of the script isn't executed at all unless the user attempts to edit the page. A few questions:
  • Despite being "pretty useless", can you share the stack trace?
  • Is it possible for mw.config or mw.loader.using to not be available when ENOM loads?
  • Do you know if this happens while the user is in the edit interface?
  • Does it happen directly after page load? (if it doesn't it's caused by a user interaction with the page)
  • Do you know which skin they were using? You'd think Minerva, but MF supports other skins as well with sometimes unexpected results. These users might be using User:Alexis Jazz/SkinEnforcer or another script with similar functionality. I could imagine users doing this on the mobile domain to permanently rid themselves of Minerva in favor of Vector-2022. (some users experience persistence issues with switching to the desktop site)
  • Given the limited number, consider the possibility these users are using a user agent switcher in which Chrome on Android is the default option.
  • Can you find a user this happened to and ask permission to put their name here? If they pasted some code directly in their common.js/mobile.js/minerva.js (as opposed to importing a script) I'm guessing you wouldn't see it, right? Or, assuming privacy policy etc. allows you to obtain a username at all, you could investigate their common/mobile/minerva JS yourself. There are various hacks going around related to the Vector-2022 rollout which might explain why this happens now.
  • If you can't obtain a username and you're feeling lucky you could look at User:Qwerfjkl/common.js for a nice Christmas tree.
  • There is a script on m:User:FactoTest1/global.js that allows loading the common+global JS from another user easily by appending ?masq=USERNAME to the URL so you could test various users without loads of copypasta. You can skip the window.FTTUserSettings bits and add bits to load mobile/minerva JS as well. Needless to say you should either use an alternative account for this or only load the scripts from users you trust.
I don't think ENOM discriminates at all between anons and users who are logged in, so I still doubt this is caused by ENOM. — Alexis Jazz (talk or ping me) 07:29, 10 April 2023 (UTC)[reply]

Icon error[edit]

Hi @Alexis Jazz: the icon at the top when the page is being edited has a bug. The icon appears multiplied and with a blue background. Edu! (talk) 19:05, 18 August 2023 (UTC)[reply]

Edu!, I see it, I guess MediaWiki changed something. I'll have a look. — Alexis Jazz (talk or ping me) 22:39, 18 August 2023 (UTC)[reply]
MediaWiki talk:Gadget-EditNoticesOnMobile.js#Edit request 19 August 2023 — Alexis Jazz (talk or ping me) 23:59, 18 August 2023 (UTC)[reply]
@Alexis Jazz Thank you! Edu! (talk) 13:06, 19 August 2023 (UTC)[reply]

needed still[edit]

With phab:T316178 completing, do we still need this? @Alexis Jazz:. — xaosflux Talk 13:33, 19 October 2023 (UTC)[reply]

Xaosflux, I think so, for now at least. See Wikipedia:EditNoticesOnMobile#Comparison which I just added.
If the MW implementation allows revisiting notices, becomes quicker to show users a changed notice (like the 2 hours for ENOM) and suppresses popups for unchanged notices for longer (say, a week or more), I think we could switch to the MW implementation without major issues. At this point in time, I'm afraid the implementation in MW could result in notice fatigue. — Alexis Jazz (talk or ping me) 20:41, 19 October 2023 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:EditNoticesOnMobile&oldid=1180944196"