In T246603#5933038, @Jdlrobson wrote:

Is this mobile or desktop? If mobile that's intentional as the mobile editor doesnt support these parameters, if desktop then likely an implementation bug. Adding editing team/VisualEditor project who are experts on all things editor related.

Yup, I noticed this bug too. The mobile JS editor loads and ignores certain parameters in the URL. (eg. oldid, and preload). CC @Jdlrobson

In T125582#5930209, @Aklapper wrote:

Whenever anyone volunteers or has capacity to work on it...

In T125582#3099442, @kaldari wrote:

No, just stalled.

In T246057#5929107, @Aklapper wrote:

Closing as declined as nobody can reproduce...

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.

In T245584#5895750, @Zoranzoki21 wrote:

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?

In T234743#5893848, @DougWeller wrote:

I have OS rights on en.wiki but couldn't revert using pending changes. Ok, I understand priorities, but still.

@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.

In T245428#5890847, @IKhitron wrote:

About the debugLog, where do you want me to paste it?

In T245312#5890782, @DannyS712 wrote:

In T245312#5890122, @Masumrezarock100 wrote:

My apologies for any misunderstanding I may have caused you. I will let Danny handle it.

I'm afraid I don't really understand what you're asking. Where is the confusion?

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.

In T245312#5890016, @IKhitron wrote:

In T245312#5889996, @Masumrezarock100 wrote:

The meaning of this part should be obvious.

Sorry, but it is not obvious. I believe you can see the architecture in your mind, but I can't see throw your mind, and this explanation just made it worse. For example, why to do something when saving the user settings, if this value is not a part of the user settings. What value should be validated at this point? And much more questions.

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.

In T245214#5887452, @AlexisJazz wrote:

In T245214#5887035, @Tgr wrote:

The next deploy window is Tuesday 12:00 UTC, can one of you be around to test it?

If Masumrezarock100 isn't around for some reason and if I forget, just ping me on-wiki.

The patch only affects patrollers. I've just been granted account creator (noratelimit) and I have no alternate accounts with patroller right. (I have an alternate account with autopatroller right..)

@Masumrezarock100, can you test it after deployment?

In T245362#5888152, @RhinosF1 wrote:

Not sure if consensus will be needed though.

(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.

In T245298#5887480, @IKhitron wrote:

Not at all. It can be good, but it is not a part of this task. All I'm saying that the script should have something like

$('.globalWatch-col').addClass('mw-collapsed');

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?

In T243489#5887115, @DannyS712 wrote:

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

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.

In T245214#5886683, @AlexisJazz wrote:

Easy reproduction steps:

• Load any category (or uploads from a user, or search, whatever) with VFC. Make sure enough (say, 100) files are loaded and select all.
• Select "custom replace"
• Replace "a" with "a{{subst:void}}" (without the quotation marks)
• Execute

This results in nothing but null edits and quickly hitting the ratelimit.

In T245312#5886496, @IKhitron wrote:

Again, I do not search a solution for global watchlist or for rcfilters. It happens with every heavy script. Just a way to configure the number. I already made a local version of global watchlist settings to avoid usage of global.js. I really do not want to have a local version of global watchlist itself just for this number.

@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.

In T245172#5886707, @Jdlrobson wrote:

Tracking is sufficient here. Readers Web are currently focused on desktop improvements so we're not going to get to this any time soon. VisualDiffs is currently only a beta feature so this particular issue impacts very few users which is why on a previous patchset I suggested the feature was hidden.

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.

In T245300#5886174, @IKhitron wrote:

A pity. I do not care about publicity. But the problems I've described are still there.

In T245312#5886501, @DannyS712 wrote:

I'm thinking something along the lines of Twinkle's hidden config settings - when not set, they are ignored and sane defaults are used; when set, they override the defaults; user only interacts with them by manually editing the settings

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.

In T245312#5886349, @IKhitron wrote:

Exactly. Not all the users have money for fast connection or for enough data usage limit. I have 4G on a good Galaxy, and clicking on Refresh makes the global watchlist disappear for 3 to 25 seconds. And I have only 10Gb montly, so I can't spent it for api calls every 7.5 seconds, when I do not need this data more than once in 10 minutes.

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.)

In T245312#5886321, @IKhitron wrote:

But one can't use live updates on mobile with this value, exactly from the same reason I can't use rcfilters.

@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.