In T245298#5906081, @DannyS712 wrote:

{{done}}

Continuing working. Opened two windows on hewiki with GL on the same wiki, emptied all, waited to a new edit. Clicked Refresh on the first, get nothing. Clicked F5 on the second, get the result. After running a query on both consules, get the same output:

var api = new mw.ForeignApi( 'https://ru.wikipedia.org/w/api.php' );
api.get( {
    action: 'query',
    list: 'watchlist',
    wlshow: 'unread'
} ).done( function ( data ) {
    console.log( data );
} );
Object { abort: abort(), state: state(), always: always(), catch: catch(), pipe: pipe(), then: then(), promise: promise(), progress: add(), done: add(), fail: add()
 }

Well, working on this in meta:User:IKhitron/Global Watchlist.js. Now I'm certain that the problem is in script, in api usage, and not in api itself. This what I have now on a console, while there is no wikidata in the list:

Yes, you can. You can remove the Refresh button, because it can't work as promised. In any case, I'll try to find some time to investigate this. Seems quite impossible that api returns different answers in different tabs at the same time, depends on the screen layout, which this api even does not need to see. Maybe the api just gets wrong parameters from the script in this case - timestamp or something else and as a result of this return wrong answer. Especially when we can see the right answer on the console, and it must come from somewhere, it is new, so couldn't remain from before. @Masumrezarock100, can you help in this investigation, please?

Nevermind why. The result is that the button does not do what it supposed to do.

So it will remain there, but will not work?

Exactly what I said, you can't use the refresh button, because api does not return the right answer.

I do not understand. Do you mean that you're going to remove the refresh button entirely, because api does not support its functionality? And there us nothing you can do?

I understand now. Thanks, I'll think if I can do it.

Funny. Of course, but all I want is avoid doing this hundreds of times every day. Now I run attr in console every time. Unfortunately, I couldn't find a way to catch the moment when all the lists are shown, so javascript could do something.

Sorry. I meant @DannyS712.

One more observation. I did a lot of tests in the last couple of hours, and can focus the problem much better.

1. Open the GW.
2. Open in other tabs and read all the shown diffs for some wiki.
3. Click refresh.
4. See the list is gone to globalWatch-col.
5. Wait until there will be at least one new edit from that wiki.
6. Click refresh.
7. Expected: The list moves from globalWatch-col up and shows the new edits.
8. Got: The list remains in globalWatch-col without showing edits.

Thanks a lot.
P10428

OK, but once again, if the user can set the new value in global.js only, why do you need to do something with settings at all? If there is a new value in global.js, it will be used on each browser refresh, otherwise it will not. Why do you need to keep it in user settings if you'll never use this setting?

For example,

GlobalWatchlist@www.wikidata:getWikidataLabels wdlabels: index.php:195:11
{…}
​
Q17523682: Object { type: "item", id: "Q17523682", labels: {…} }
​
<prototype>: Object { … }
index.php:196:11

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

In T245312#5890833, @DannyS712 wrote:

There is no timeout field on the settings page, but you can still manually set one

In T245312#5890782, @DannyS712 wrote:

• If the user has manually set a timeout by previously editing the settings, the timeout should be kept when saving again

The user cannot set a timeout by editing the settings, because there is no timeout field in the settings.

@Danny, we're talking about different things here. Let me try to explain once again. I do not talk about pinning. I talk about the state when all edits lists will start un-collapsed and only the bottom list will start collapsed, because no one needs it, except for special occasions.

Do you mean to spend an hour to open all the objects again, or the new one you've added?

No apologies are needed. I'm the stupid one here.

I just quoted the last line. Not meant that my answer is to this line only.

In T245312#5889996, @Masumrezarock100 wrote:

The meaning of this part should be obvious.

In T245312#5888660, @DannyS712 wrote:

It'll be awhile before I'm motivated to do this, because I'm not planning to use it myself, but if anyone wants to submit a patch please do so:

• Can be submitted as either a git patch/diff, or a fork on enwiki or meta (so that I can use Special:ComparePages)
• The config setting should not be added to a user's preferences if you are using the default
• The config setting should be kept when saving new settings
• No new field should be added to the settings page

So, what do you say, @DannyS712?

Sure, but this is much simpiler that T245348.

Exactly. This was the purpose of this task. This

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');

In T245298#5887403, @Masumrezarock100 wrote:

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.

The screenshot of https://meta.wikimedia.org/w/index.php?diff=19810190&oldid=19808405&diffmode=source.

In T245298#5887096, @DannyS712 wrote:

Done in 8.2.0 - https://meta.wikimedia.org/w/index.php?title=User:DannyS712/Global_watchlist.js&diff=19809191&oldid=19806205

In T245326#5886777, @Masumrezarock100 wrote:

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

But Masumrezarock100's idea about a mnimum is very good. If somebody will set it to 5 milliseconds it will blow up the script.

Fair enough.

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.

No error. Just takes time and resources. I do not ask to fix the script. I understand it needs all this, because of many api calls. So all I ask is an opportunity to change the number.

And about the rc-filters - the mobile need reboot after a couple of minutes.

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.

In T245312#5886320, @Masumrezarock100 wrote:

@IKhitron are you having any problems with the current setTimout value? I am curious to know why you need to jump to 600000ms.

Do not care how. And there can be a hardcoded minimum of 7500. But one can't use live updates on mobile with this value, exactly from the same reason I can't use rcfilters.

In T245300#5886091, @Masumrezarock100 wrote:

Marking as declined in favor of T238299 per comments in T237082#5680479. I agree with making the settings not public. Setting up a global preference would be better.

Yes. For me, it will look much better. I have 17 sites like these at this moment, for example. And it should be very easy.

Much better, thanks!

I think I found. It should be white-space: nowrap; instead. Looks like it does resolve the problem.
So, the full answer is replacing

.globalWatch-site a {
	unicode-bidi: isolate;
	display: inline-block;
}

to

.globalWatch-site a {
	unicode-bidi: isolate;
	display: inline;
        white-space: nowrap;
}

if there is a need in display: inline; as explained above, or

.globalWatch-site a {
	unicode-bidi: isolate;
        white-space: nowrap;
}

otherwise.

Well, as a first step you can replace inline-block to be inline, or remove the rule entirely, if it was inline before the change. It will fix the strikethrough problem, but return a small rtl problem. I'll continue to seek a permanent solution.

In T245104#5879580, @DannyS712 wrote:

Suspect changes in CSS as part of T245042: 103: Make the script RTL-compatible may be the issue
@IKhitron any idea what may have caused this?

Very well thou.

Actually, maybe you'd like to check the timeless skin by yourself and decide if it's a good idea to use p-views there, even it's possible, because the link appears in very surprising spot.

In T243489#5878627, @Masumrezarock100 wrote:

I wonder what exact problem you were facing.

The console shows a message "unclosed parentheses". Tried several variants, the message is the same, the location of opening "(" is different, but accordand ")" is always very far in the code. So my first thought was that not all the lines are accepted.

As you wish.

Monobook and modern. Minerva has not the node either, but you already fixed it. Vector and timeless have the node.

It is, in both versions. Thanks a lot.

[[user:ערן]], [[user:ביקורת]], [[user:דוד שי]].

If you are talking about assigning, seems like the bot re-assignes it to you every time the task is edited.

No, I'm seeing it constantly.

Indeed. Thank you very much.

Great, thanks. What about the stable version?

Thanks, Done. Do not care if anyone will see my watchlists.

I do not care how it will be done. Danny asked to create this paste.

In T244638#5862667, @DannyS712 wrote:

I meant a phabricator paste (https://phabricator.wikimedia.org/paste/edit/form/14/)

Access Denied: Restricted Edit Configuration
You do not have permission to view this object.

I've added some more debug logic. Can you please:

• Open your global watchlist
• Open the console
• Run console.log( GlobalWatchlist.debugLog );
• And create a paste with the result?

It'll be a large output, and (as a warning) will include what pages are being shown (generally watchlists are private; if you want me to create a paste only visible to the two of us I can do that too)

In T244638#5862662, @DannyS712 wrote:

Can you create a paste?

https://pastebin.com/UEXq1Nyk

Sure, but just leave it as disabled for now

No problem

In T244638#5862643, @DannyS712 wrote:

In T244638#5862638, @IKhitron wrote:

Done the first part. What to you want me to take after the refresh? I can still see the log entries.

Can you expand the ...?

It is already expanded.

What wiki are you viewing the watchlist on?

Ruwiki.

Can you post the whole console (again, expanding the arrays and objects)?

Yes, but are syre? It's about a megabyte of text.

Also, https://meta.wikimedia.org/wiki/User:IKhitron/global.js still says to show them...

It's because I restore it each time, for your next question. See the history.

Done the first part. What to you want me to take after the refresh? I can still see the log entries.

Me either, three times last week.

Actually, tried to do this and failed. Did not investigate what's happening, but my wild guess is that the script is too large to be a gadget. Do not know.

I'm not sure it was not intended.

Found it, @TheDJ. See here:

Aklapper changed the task status from Open to Stalled.

Thanks. I thought to do it by myself, but was not sure.

It's a pity you're asking it only now. I do not remember where did I see it. I'll try.

In T236475#5808602, @TheDJ wrote:

So you want the stylesheet for 'print' to be different for the PDF version, so that you can still recognise the links (correct?)

In T237267#5780047, @DannyS712 wrote:

Once the patch is merged and deployed, and its easier to track usage, I'll file bot requests on the most affected wikis (and if there are less that eg 100 uses just replace manually) - can I state that it is now "official" that it will eventually be removed?

Is there a way to get a list of renamings for a particular wiki?