Hey there! Nice to meet you. I go by Masum Reza IRL. I am not a Mediawiki developer but I have developed some userscripts for Wikimedia sites. I mainly track some tasks related to mobile here and report bugs. I am also an administrator of Mediawiki.org. So feel free to ask me if you need admin help there.
Yup, I noticed this bug too. The mobile JS editor loads and ignores certain parameters in the URL. (eg. oldid, and preload). CC @Jdlrobson
My bad, I was still editing the task when you closed this task. So we ended up having a edit conflict. I will close this duplicate.
@Jdlrobson @ovasileva Wikimedia sites do get a fair amount of traffic on the mobile site. Imagine a blocked new editor using VPN looking at the block notice when they open their editor, only to find an unhelpful message. On big wikis, such as English Wikipedia and Commons, this type of thing is highly unhelpful, because we use templates to provide users more information on why they have been blocked. I think this should be high priority.
Looks like a caching issue. Have you tried to purge the page's cache using action=purge?
@matmarex nice work. I am sure there will be many cases where this tool will be helpful. I already successfully tested one patch with it!
@DannyS712 thanks for working on this! I tested the patch using http://patchdemo.wmflabs.org. <!-- see T76245#5788579 for more info about this webservice --> I successfully added a comment in block logs of a user. It was working flawlessly! Comment: I only checked the special page (Special:AnnotateBlockLog), not sure what is the status of other functions though. Feel free to test it out there.
Nice. Metawiki or Mediawiki either one is fine to me. But my concerns in T243489#5825762 are valid. May I ask when you are planning to start a discussion there, and request for interface adminship?
Hi, and welcome to Phabricator. Unfortunately your task lacks necessary information for developers to work on it. Please follow the instructions at https://www.mediawiki.org/wiki/How_to_report_a_bug and clearly explain how to reproduce this issue. Thanks!
It's not stalled on anymore. Just waiting for a +2.
Reproducible on WMF production wikis (tested on mediawiki.org) and on the beta cluster (tested on beta Commons) as well. This is about MediaWiki-extensions-Nuke not MediaWiki-extensions-BlockAndNuke.
Ok, I can make patch, no problem. This looks easy.
Just to note: I found this also when I want to delete/undelete some revision (With blue colour, I hid the part of summary and title because it contains the phone number)..
But looks like it needs to be converted to the OOUI firstly.
To clarify, I am talking about these two buttons. They look like plain text on the mobile site.
 |  |
| On the mobile site | On desktop site |
Screenshots taken from https://www.mediawiki.org/wiki/Special:Log.
@Zoranzoki21 wanna give a patch?
@soratako Hi, when closing a task, please don't remove relevant project tags, subscribers, and please don't blank the description. I assume you did that because you think that the bug has been fixed?
I have tested the patch per reproduction steps in T245214#5886683. My rate limit indeed got increased. The API response from https://commons.wikimedia.org/w/api.php?action=query&format=json&meta=userinfo&formatversion=2&uiprop=ratelimits is as follows.
{ "batchcomplete": true, "query": { "userinfo": { "id": 7299736, "name": "Masumrezarock100", "ratelimits": { "move": { "user": { "hits": 8, "seconds": 60 }, "patroller": { "hits": 32, "seconds": 60 } }, "edit": { "user": { "hits": 900, "seconds": 180 }, "patroller": { "hits": 10500, "seconds": 180 } }, "upload": { "user": { "hits": 380, "seconds": 4320 }, "patroller": { "hits": 999, "seconds": 1 } }, "linkpurge": { "user": { "hits": 30, "seconds": 60 }, "patroller": { "hits": 3000, "seconds": 180 } }, "badcaptcha": { "user": { "hits": 30, "seconds": 60 } }, "emailuser": { "user": { "hits": 20, "seconds": 86400 } }, "changeemail": { "user": { "hits": 4, "seconds": 86400 } }, "rollback": { "user": { "hits": 100, "seconds": 60 } }, "purge": { "user": { "hits": 30, "seconds": 60 } }, "renderfile": { "user": { "hits": 700, "seconds": 30 } }, "renderfile-nonstandard": { "user": { "hits": 70, "seconds": 30 } }, "cxsave": { "user": { "hits": 10, "seconds": 30 } }, "urlshortcode": { "user": { "hits": 50, "seconds": 120 } }, "thanks-notification": { "user": { "hits": 10, "seconds": 60 } }, "badoath": { "user": { "hits": 10, "seconds": 60 } } } } } }
I don't see why we are not doing this for all diff links. Opening a link in the same tab just wastes time, because it would take some time to load the watchlist once you click the back button and if you have a big watchlist with many unseen changes.
Thoughts of more people on this would be helpful.
You could just right click on it and open it in a new tab.
I was asking you to explain it to @IKhitron, which you are doing now. I had failed to explain it clearly to him. I think real time chat (on IRC or Discord) is a better suited place for explaining to someone who is having trouble understanding the process.
My apologies for any misunderstanding I may have caused you. I will let Danny handle it.
No, this is not the same problem. I am seeing a 504 gateway timeout error if I visit https://tools.wmflabs.org/copyvios/ while T243736 describes the error message as
An error occurred while using the search engine (Google Error: HTTP Error 403: Forbidden). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.
I remember I used it yesterday and it was working but it is down at the moment.
Meh, it seems he is not available currently on Discord. It would be faster if he was.
I will ping Erwig on Discord.
Imagine the variable is LiveUpdatesTimeout (or something like that, my imagination is lacking. I could not find a better name).
- The config setting should not be added to a user's preferences if you are using the default
If you are using the default value (which is 7500 milliseconds at the moment) of LiveUpdatesTimeout, no new config should be added to the global.js.
- The config setting should be kept when saving new settings
When saving settings using Special:BlankPage/GlobalWatchlistConfig, the script regularly checks for any error and replaces the old config with the new one. You need to make sure that GW doesn't consider LiveUpdatesTimeout as an invalid variable and doesn't remove it during the saving process of GW settings (from the settings page)
- No new field should be added to the settings page
The meaning of this part should be obvious.
(Not sure if it's the correct tag. Feel free to remove it if it is not!)
I have fewer sites to watch. So I don't mind it expanded. Other users might also like it expanded or collpased (depends on the user). If T245348 gets implemented, I believe this problem of yours will be solved.
If I understand correctly, you are saying a collpased list should stay collpased (not auto-expand) even after a refresh? I'd support such change. Maybe cookies can be used to remember the user's preference?
Unlike RTRC, GlobalWatchlist has truly global functionalities. I see no need to define GW on other wikis. Just in a central wiki is enough. Since new users may get confused because of different install methods.
That's not an unexpected behavior since GW doesn't track whether people have collapsed the list or not. I'd call this task resolved since the criteria for sign-off has been met. Feel free to open a new task if you'd like a pinning function. I think cookies can be used to track whether a user have collapsed the list. See an example, RevisionSlider extension.
The styling of the collapse link could be made similar to it.
@IKhitron Danny haven't had enough time to work on it. So feel free to claim this task if you want to work on it. 😀 There indeed seems to be a need for deprecating the current way of saving GW preferences.
I agree with you. If the product owner of this feature agrees, it should be hidden on mobile. I am not sure if there is much demand for this feature on mobile (I haven't heard anyone asking for this, nor I found any prior phab tasks to enable it on mobile). Simply put, there are too many problems here, so I don't believe this is ready for production yet. The biggest one is the layout issue. The VisualDiff style currently doesn't match the unified diff style on mobile.
Same thing is happening with the Statistics table in the stewards election page.
The table color and styles are hidden on timeless. https://meta.wikimedia.org/wiki/Stewards/Elections_2020/Statistics?useskin=timeless https://meta.wikimedia.org/wiki/Stewards/Elections_2020/Statistics?useskin=vector
Hmm, so I am assuming something like this happens.
GW live updates feature timesout because of slow connection. GW gets stuck because of it. Then either automatic refresh happens or you click the "Refresh" button. (which one?. I need answer) It consumes too much data because of too many API calls.
I suggest Web-Team-Backlog to look into it since this appears to be a MF bug.
(I really hope Special:MobileDiff page will be removed and MF will use the core diff url. Current special:mobilediff creates a lot of problems for users.)
@IKhitron are you having any problems with the current setTimeout value? I am curious to know why you need to jump to 600000ms.
I am not sure if there is really a need for it. It would not likely be used by normal users in normal circumstances except by advanced users (during testing). This may cause performance issues in browser when there are too many sites. Either way I really don't really see the need for an inputbox in the preferences page to customize the timeout. New users may get confused and unknowingly break the GW. If a there is really a need for this, a hidden config should be implemented and it would need to be manually added to the global.js.
