Page MenuHomePhabricator

Watchlist css classes are messed up
Closed, ResolvedPublic

Assigned To
None
Authored By
IKhitron
Sep 20 2017, 9:29 PM
Referenced Files
F9709506: image.png
Sep 21 2017, 10:54 PM
F9709389: image.png
Sep 21 2017, 10:54 PM
F9709508: image.png
Sep 21 2017, 10:54 PM
F9709375: image.png
Sep 21 2017, 10:54 PM

Description

Hi. Bug or feature?
After today's group 1 deployment the css classes in html structure of special:watchlist were messed up. I'm on tablet and can't tell you specific names, but a gadget I wrote stopped working well - when clicking on a button that unhides early hidden seen revision groups, it suddenly unhides also all the groups content - seen as unseen. That means, that there is a change at least in grouping mode - css classes of group contents - the revisions of specific pages of the same day that should be hidden and opened when clicking on arrow button near this page name - were changed this evening. Again, I do not know if it's a bug or done by purpose.
I'm not sure I could explain well the problem this time. I can't open a console or make a screenshot in the next couple of days. Sorry about that. If I didn't, I'll try to explain more. Here is the code that stopped working well. It looks wierd because I removed all the conditional for simplicity:

$('.mw-changeslist-line-watched').show();
$('.mw-changeslist-line-unwatched').show();

Looks like these classes are applyed not just to group dom elements as before, but also to their children, recursively. But without the consule it's just a guess.
Thank you.

Event Timeline

Clear steps to reproduce the problem are welcome, including links, the skin used, and the settings for "grouping" (?).

Very well. The only link used is Special:Watchlist, the skin is default vector, otherwise I would mention it explicitly, of course, and grouping mode setting is "Group changes by page in recent changes and watchlist". Reproducing steps are: Open the watchlist, run the code mentioned above. Thank you.

Does this happen only with the "New filters for edit review" beta feature enabled, or also with it disabled?

Does this happen only with the "New filters for edit review" beta feature enabled, or also with it disabled?

I didn't enable it yet. There are inconsistencies between beta and the gadget, so I can't check it before I'll fix the gadget. So, it's without the filters.

Notes:
One of these two gadgets, appear to be the gadgets that IKhitron is asking about:

(found via searching the mediawiki: namespace for the class name)

Those two are listed in the preferences as:

  • הוספה או הסרה של דפים לרשימת המעקב מדף השינויים האחרונים, או הסרת דפים מרשימת המעקב מהרשימה עצמה.
  • מנהל רשימת המעקב (מתנגש עם הסתרת רוב העריכות בהעדפות)

To test, I think you need to enable both "Group changes by page in recent changes and watchlist" and "Expand watchlist to show all changes, not just the most recent", and then watchlist a bunch of recently-active pages (especially pages with multiple recent edits).

Beyond that, I don't understand what the gadget(s) are intended to do.

  • @IKhitron Where is the "button" located? (you wrote: "''when clicking on a button that unhides early hidden seen revision groups''") I cannot see any new buttons or links in the interface.
  • I see .mw-changeslist-line-watched appears logically within the Special:Watchlist HTML source.
  • I cannot see .mw-changeslist-line-unwatched anywhere in the HTML source for the watchlist or for Special:RecentChanges. I tried checking a non-WMF wiki, running MediaWiki 1.27, and I cannot see it there, either, so I don't think this is a recent change?

Thank you very much you're helping with this.

Notes:
One of these two gadgets, appear to be the gadgets that IKhitron is asking about:

(found via searching the mediawiki: namespace for the class name)

I didn't give you the gadget name because it has a thousand of lines, and I thought it's irrelevant to the question. I still don't know why do you need the gadget at all. But if you need it - of course. It's the second one.

Beyond that, I don't understand what the gadget(s) are intended to do.

The gadget expands the features of the watchlist page. If you're interested, these are the things it can do:

  1. Hide by default all seen edits.
  2. Add to every unseen edit a button "mark as seen without opening".
  3. Add to every seen edit a button "mark as unseen".
  4. Add to every unseen edit a button "open a diff for this page for all revisions you did not see yet, alltogether", so all the buttons for different revisions of the same page do the same thing.
  5. Hide every edit that you just saw one click later.
  6. Show all edits that are not shown at this moment, if asked.
  7. Hide all seen edits that are shown at this moment, if asked.
  8. Dynamic button changes - for example, the button "mark as seen" disappears on clicking and button "mark as unseen" appears.
  9. A button "what's new" that shows simplifyed version of watchlist for all the pages that are changed from the last refresh, so you do need to refresh all the time.
  10. Hide any edit to see it later.
  11. Different behaviour for different edit kinds - regular edit, page creation, categorization, Echo, wikidata.
  12. Full configuration of every element and every action.

The purpose is emptying the list for real. It took me 4 monts to write this gadget.

  • @IKhitron Where is the "button" located? (you wrote: "''when clicking on a button that unhides early hidden seen revision groups''") I cannot see any new buttons or links in the interface.

To see the problem, add to your watchlist a couple of pages that were edited today more than once, such that you did not see the edits yet, so they will as unseen groups, open the special:watchlist, click "show all hidden" and then "hide all read". The regular behaviour was that the view will be the same as on opening, because you did not change nothing. But now, a lot of edits remain on the page - the content of unseen groups. The buttons are at the page top, just above the edits.

  • I see .mw-changeslist-line-watched appears logically within the Special:Watchlist HTML source.
  • I cannot see .mw-changeslist-line-unwatched anywhere in the HTML source for the watchlist or for Special:RecentChanges. I tried checking a non-WMF wiki, running MediaWiki 1.27, and I cannot see it there, either, so I don't think this is a recent change?

I do not talk about special:recent changes at all.

Thank you very much.

Oh! I had located the second gadget, but forgot to enable it. Ok, now I see the buttons.

I didn't give you the gadget name because it has a thousand of lines, and I thought it's irrelevant to the question. I still don't know why do you need the gadget at all.

Links and/or examples ALWAYS help. Context is everything! :-)
In this case, they help anyone understand which gadget you're asking about, so that they can then test it out and see how it works for themselves.
They can also help determine when there is an error in the task description, e.g. I think you meant to write mw-changeslist-line-not-watched instead of mw-changeslist-line-unwatched?

Screenshot of Firefox and Chromium:

image.png (576×1 px, 285 KB)

Webconsole:

image.png (979×1 px, 307 KB)

I think it is now clearer that you're asking about: whether there was a recent change in the default (non-Beta) Watchlist CSS classes that are applied to seen-diffs. I.e. Some combination of the 4 pre-existing classes has changed: mw-changeslist-line-watched, mw-changeslist-line-not-watched, mw-changeslist-watchedseen, and mw-changeslist-watchedunseen.

Ah, I think I just understood the problem (?):
When you initially click the Expand/Collapse arrow for a section, you now get all the revisions, whereas before you would only get the "unseen" revisions. Is that it?

image.png (664×1 px, 154 KB)

image.png (664×1 px, 209 KB)

(Sidenote: I'm using a trick in my global.js - documented at T109103 - to autoexpand all the sections on page-load. It doesn't always work (because of page-load order), but I love it when it does! It autoexpands just the unseen revisions, when I use it with your gadget.)

Note I am not a developer, so cannot help any further.

Thank you for your answer.

Links and/or examples ALWAYS help. Context is everything! :-)
In this case, they help anyone understand which gadget you're asking about, so that they can then test it out and see how it works for themselves.

Wierd, but OK, I'll try to remember this.

They can also help determine when there is an error in the task description, e.g. I think you meant to write mw-changeslist-line-not-watched instead of mw-changeslist-line-unwatched?

I believe you're right, I just confused the names in my memory.

I think it is now clearer that you're asking about: whether there was a recent change in the default (non-Beta) Watchlist CSS classes that are applied to seen-diffs. I.e. Some combination of the 4 pre-existing classes has changed: mw-changeslist-line-watched, mw-changeslist-line-not-watched, mw-changeslist-watchedseen, and mw-changeslist-watchedunseen.

Indeed.

Ah, I think I just understood the problem (?):
When you initially click the Expand/Collapse arrow for a section, you now get all the revisions, whereas before you would only get the "unseen" revisions. Is that it?

Not at all. I did not talk about expand/collapse at all. I'm talking about some of these classes are added to children of elements that already have these classes.

(Sidenote: I'm using a trick in my global.js - documented at T109103 - to autoexpand all the sections on page-load. It doesn't always work (because of page-load order), but I love it when it does! It autoexpands just the unseen revisions, when I use it with your gadget.)

It wasn't intended, and is not a part of the question.

After all you just said, I have a guess: Maybe the last deployment added watched / not watched classes to elements of groups. This could be done to see witch elements in group are seen and which aren't. As far as I remember, it wasn't like this before.
If it is what's happen indeed, it's a very good change. And it explains exactly the gadget misbehaviour. If so, I can fix the gadget. But I should know if it's indeed what happened, to be sure that my guess isn't just guess. Because I didn't see anything like this in the tech news. What do you say? Thank you.

@IKhitron I tried to find exactly where the change came from and failed to find an exact match, but I think I know what happened. As part of the RCFilters fix, we've been updating the way highlighting works and the way that the enhanced list displays itself. 99% of the changes were done only for the beta activated, but while we were working we found a few underlying bugs that were also fixed. (The interesting thing about a bug, is that when it's a 7-8 year old bug, it's usually considered a "feature" even though it's clearly not... ;)

After all you just said, I have a guess: Maybe the last deployment added watched / not watched classes to elements of groups. This could be done to see witch elements in group are seen and which aren't. As far as I remember, it wasn't like this before.
If it is what's happen indeed, it's a very good change. And it explains exactly the gadget misbehaviour. If so, I can fix the gadget. But I should know if it's indeed what happened, to be sure that my guess isn't just guess. Because I didn't see anything like this in the tech news. What do you say? Thank you.

I can't spot the exact change that was done, but your guess struck me as correct: we added these classes so that you can see watched/unwatched lines with a filled/empty circles -- and while that change is inside the beta, the fact that originally these classes and state of being were only partially applied to the list was seen as a bug (as it basically is, honestly)

I don't think we anticipated that it would hurt anything, so I apologize if it broke the gadget. I can try and help pinpoint the issue with the gadget and perhaps attempt to help you fix it.

Off the top of my head, though, if you need to only target the children of a page (the pages that are grouped), you should be able to go with td.mw-enhanced-rc-nested. If you use the RCFilters beta, I also added distinct classes to the structure: mw-rcfilters-ui-changesListWrapperWidget-enhanced-toplevel and mw-rcfilters-ui-changesListWrapperWidget-enhanced-nested --> but those are only added at the Javascript level (so the beta must be enabled, and the gadget should run after initialization of RCFilters, on the hook structuredChangeFilters.ui.initialized

Another quick suggestion -- from quickly scanning the images attached about the gadget, I think there's already a newly added core behavior for adding 'x' buttons near results (to set a result as unwatched and remove it from the list) -- you should be able to find it in English Wikipedia in the settings, and I think we might be able to enable it in Hebrew Wiki if you want; if that replaces/enhances your gadget's behavior it might be better, since that's supported fully as a feature in MW core. Let me know if you want us to look into that further.

I apologize for not announcing changes with these classes, I don't think we were aware that they could and would break the behavior for a gadget. If you need help with adjusting your gadget to the new behavior, let me know and I'll try to take a look.

Hello, @Mooeypoo. Thank you very much for your answer.
Well if the guess is right, I already fixed the gadget. The problem is that if we're not sure this is the only change, so the gadget should be fixed accordingly. And as I already said, the change itself is very good, the problem is the surprize.
About "x" - no, it's not the gadget functionality. It's already on Hewiki. Still I added a command to the gadget that moves this x to the end of tr element, because it's on very wrong position on enhanced lists now, if you use mobile - trying to expand or collapse the group can remove the page from the watchlist unintentionally, they are very close on the tounchscreen. And remove the page with x and then add with + does not undo the action - the data about unseen revisions is lost.
Thank you very much again for your kindness.

you should be able to find it in English Wikipedia in the settings, and I think we might be able to enable it in Hebrew Wiki if you want;

I thought that feature was available on all wikis? It's just opt-in, and was rolled out with little fanfare.

Well if the guess is right, I already fixed the gadget.

Then it looks like this can be resolved. Feel free to reopen if I misunderstood.