The same on hewiki, just without reloading, but with watchlist fetching gadget.

This particular example is on Samsung Internet, same browser as of Amire80. I did not check this example on Firefox yet.

In T239035#5687733, @Aklapper wrote:

In that case please provide your screen width and browser zoom level. (And for future reference, please always include browser information.)

1280 pixels. How can I recognize the browser zoom level?

Also, going to https://he.wikipedia.org/w/index.php?title=סמולוויל&diff=26747890&oldid=26747811 in Firefox 70 I don't see a green background in those four paragraphs. Where does that come from?

A line in my personal common.css

.diff-deletedline, .diff-addedline {background: #EAFAEA;}

And the problem is that it sometimes disappears in safemode, and sometimes doesn't. My guess it depends on screen width in every single example.

I am on Samsung Browser now, but I saw it a lot on desktop Firefox.

In T239035#5687652, @Amire80 wrote:

Hmm, I can't reproduce. I tried in Firefox and in Chrome, logged in and logged out, and I don't see the problem.

In T236297#5603213, @Aklapper wrote:

Hi @IKhitron, please include only one problem per task and create separate tasks for each request, so each suggestion could be potentially assigned and the status for each suggestion can be properly tracked, by following https://www.mediawiki.org/wiki/How_to_report_a_bug - Thanks!

Pay attention that it works fine in preview: ruwiki, hewiki.

OK for me either.

Sometimes the page opens, but instead of contents you get

[XZXq4wpAADkAADTd@iwAAAUF] 2019-10-03 12:36:02: Fatal exception of type "WMFTimeoutException"

In T231698#5512527, @MaxSem wrote:

• Therefore, adding section names on the right side wouldn't cause performance problems (some processing is still needed to correlate lines with sections, but it's pretty insignificant).
• Left side, however, is different. Getting another parser output can result in cache misses and slow parse as a result. Memory consumption would also be higher.

Just a thought from non-developer. If we know that left side and right side are equal, otherwise the left side would already be a part of the diff, can't you just copy the right side string to the left, instead of computing it by brute force?

Something happened last night, the bug was there again and again.

In T218511#5399574, @Trizek-WMF wrote:

In T218511#5388647, @IKhitron wrote:

Confirming that.

Have you followed the steps described above? T218511#5360423

Confirming that.

It happened me yesterday. I'll try to remember safemode checking next time. My browser is always up to date.

Thank you for the quick work.

Of course. I am terribly sorry.

Hello, @Lea_Lacroix_WMDE. Is there something new with this task? See this diff from yesterday. Thank you.

Seriously? OK, but very weird.

In T227268#5306880, @Aklapper wrote:

About the link - any diff fits, as I already said.

"Any" is not a link. :) Please choose any link and post that any link. Always.

OK, if you think there is anyone here that does not know what is version diff.

About Firefox, you did not provide any version information. Please see what I wrote - thanks!

The version is in the "rest" part of my version. I answered about the browser, not about the version.
Thank you.

In T227268#5306854, @Aklapper wrote:

I opened https://cs.wikipedia.org/w/index.php?title=Alfons_Mucha&type=revision&diff=16784497&oldid=16715219 in Firefox 67 while being logged in and double-clicking on any word in any side of the diff, I cannot reproduce the problem.
If the word starts blinking then I am afraid is not MediaWiki doing that, hence closing this task.
You may want to follow https://www.mediawiki.org/wiki/Help:Locating_broken_scripts if you think that some gadget or user script is involved; you may want to ask in a support forum of your web browser if you think that your browser behavior has changed.
For future reference, please read and follow https://www.mediawiki.org/wiki/How_to_report_a_bug when creating tasks and also provide a full link to a webpage where the issue can be seen, if you see the same behavior when you are not logged in, name and version of your web browser, if this also happens with a different web browser, and name and version of the different web browser. Thanks!

Thanks. Hope it will never come back indeed.

Well, this time the lag is not twenty minutes any more. Eight Ten hours and counting.
And this time the problem is also in history pages and in API.

@scfc, you can try reading [[w:he:MediaWiki:Gadget-WLM.js]].

Once again, after I fulfilled your recommendation.

It was not reproducible from the beginning, just suddenly happening a couple of times every day. But no problem, I'll do this.

In T218511#5215295, @Izno wrote:

You should probably provide new instructions to reproduce. I've not had this issue all day today.

Pay attention. The wrong data in watchlist problem is resolved, but the original issue of this task, "After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)", isn't.

24 hours after group 1 deployment. I do not see any problems.

In T218511#5186070, @aaron wrote:

In T218511#5185892, @IKhitron wrote:

Group 1 deployed, the problem continues.

Unread things marked as read?

Group 1 deployed, the problem continues.

Well, group 1 deployed. It's much better now, but there are some problems from the last week.

Well, there is a new bug now, see above. Maybe it comes from this one.

Unfortunately, a lot of people in two wikipedias (at least) are complaining, with js, including myself.

And now I can see a page with no bold edits at all, but with edits I never read.

Now I can see that the original issue continues. Listen, the problem is at all in this task, or it's something else?

And I saw a first case of completely read page, marked as unread.

A pity that @Reedy believes it's not crucial. It was annoying until today, and now, for a week at least, the Watchlist can't be used at all any more - you can't know what edits are read and what are not. A week without watching pages in all wikis. A rollback of one version will solve the problem. Thank you.

Digged a little. For each page, that has at least one unread edit, most edits marked as unread, as far as they are on watchlist page, at least. I can see an example page, with 35 from 54 unread today, 36 from 53 yesterday, 12 from 24 the day before yesterday. For example, the last edit 3 minutes ago marked as read, when I did not opened it yet.

The unread edits API works well.

@aaron.

Red alert.
Group 1 deployed, and it's much worse now. A lot of edits from previous days suddenly returned to be unbold.

In T218511#5106768, @TheDJ wrote:

@isaacl mentions: "I'm still having the opposite issue that I mentioned before: diffs being marked as read even though they weren't, but on occasion I also see the issue that everyone else is complaining about regarding diffs that have been read"

It is not what I was tacking about, but it seems as another problem.

Hello, @Lea_WMDE. I can see that the wikidiff2 (T203069) has been already deployed, so the original diff looks much better, and "Michgrig" fits the aim of the tool. Nevertheless, please check "Фил Вечеровский", with comma on the left diff side.

Brilliant idea! Thanks a lot. Could you, please, add a Special:Interwiki "ww" wikilink prefix ([[ww:3]] -> https://w.wiki/3)?

I can see it once or twise every day since then.

Thanks a lot. Filed T219781.

In T181001#5051977, @Aklapper wrote:

As described by Hashar, this can be achieved already: See task-status(status) on https://www.mediawiki.org/wiki/Phabricator/Help/Managing_mail
Closing as upstream has no plans to dump more metadata into the email body.

In T176095#5039561, @TheDJ wrote:

@IKhitron do you know if this is still a problem ?

Indeed, Aklapper. Thanks.

Aklapper, I'm sure that those two are the same problem.

You did not understand me. It was Chrome in that report, but because of updating lack, I do not think that browser is the problem.

I do not think it's Chrome. A couple of people said thay did not update the browser a lot of time. Do you still want me to ask?

There is one complain from March 10.

In T218310#5024527, @Aklapper wrote:

@IKhitron: Any links to discussions? Any info which browsers and browser versions people use?