closing as T86680 got fixed. Change has been deployed. I haven't seen that issue afterwards for me.

After no obvious is striking in the code, I could imagine that has to do with the user id a user has.

this must be caused by a recent (<2 weeks?) change in FF, Adblock and/or MediaWiki (Popups, ..).

In T86523#970601, @Aklapper wrote:

(Redrawing by disabling certain elements in Firefox' CSS editor sometimes makes those items appear. Right-clicking on such a tag also makes them appear and mouse over shows/hides those items.)

Right-clicking/mouse over doesn't do that for me. I played a little bit with the built-in inspector/debugger: If I disable

body {
    font: 13px/1.231 "Helvetica Neue",Helvetica,Arial,sans-serif;
}

then it displays icons for the right column (new tasks), but not for all others (Assigned+Subscribed on left column), switching the bug.

This task isn't about notifying users about new/updated/soon to be released beta features, or? (like proposed in https://www.mediawiki.org/wiki/Beta_Features/New_Feature_Popup_Guider)

can't reproduce at the moment either

fyi: unmerged: this task is about the rule list, whereas the other about the logs.

see last comments: this task is about also doing log filtering on a remote wiki: filtering for hits for local filters and local hits of global filters, doing so on central wiki has been done
T 78495 is about filtering displaying filters/rules itself on their list

@Glaisher: so one part is done. The description is a bit unclear for me for the second part. Do you mean you want a option to filter on a remote wiki hits for local filters and local hits for global filters?

reopening: what's invalid here? (tasktitle had been changed to reflect incompatibility)

any update on this?
We had a patchset that was working. But from hearsay this would have caused parser failure and thus was reverted.

Jforrester at gerrit:149091
Edits made to pages with <ref>s in them (so, you know, a few) would sometimes (but not dependably) be corrupted on parse, replacing <ref>Foo</ref> with UNIQ-xxxxxxxxxxxx-QINU (parser failure tag) on render or save.

I know it's the parser but has someone a clue why this should not working? Onlything added is:

$parser->addTrackingCategory( 'cite_error_refs_without_references_category' );

There are already various pages updated at https://www.mediawiki.org/wiki/Manual:Huggle

so current viewpoint is wontfix/decline this bug? Anyway MW 1.19 (LTS) is only official supported until May 2015.

closing:

In T85318#944034, yuvipanda wrote:

Neither icinga nor ganglia will be used in labs anymore.
[...]

happening for both plaintext and html output.

stalled since more than a year: waiting for information from ops if this is still happening in the logs.

another report: https://www.mediawiki.org/wiki/Topic:S4opda1x12kcc54w

I think at first this task should be limited to migrate content on JS pages (the scope of the blocked task).

maybe add a small html message instead or setup redirects?
especially as the server are answering requests to that adress and the domain is not dead itself. Or remove the domains.
But please don't leave in such a broken state.

In T85323#944027, @gerritbot wrote:

Change 181795 had a related patch set uploaded (by Se4598):

In T85323#943987, @Glaisher wrote:

Also while we're at it, can we have the filtering by local & global filters option available on centralwiki's Special:AbuseFilter? It's available just not exposed to the interface. I don't see any reason why it should be hidden.

IIRC from a recently discussion the wiki-field in the log-table is NULL for local hits (on the central wiki), thus inserting any value for the central wiki doesn't work.

same or related: T20670: Create ability to add / remove tags from edits / actions

This is only applicable for some items, for others extracts returned are empty. Should be fixed in TextExtracts?

Do you mean on Special:AbuseFilter or Special:AbuseLog? (or both?) Link in description points to former, but text is latter. Sounds you mean it for Special:AbuseFilter, the filter list.

looks like it's skin=monobook (and I reproduced it /w on dewiki-beta, Vector look ok). Apparently there is one CSS-rule overwriting the padding (left) offset by AbuseFilter.

FYI: Maybe T76955 is related or even blocks this task.

In T76422#801218, @Petrb wrote:

Like replacing 1 query with 80+ queries is a bad idea for me

Currently our config is stored on a CSS-page, but isn't CSS. This task is a request to move the user configuration into (hidden) user options (stored by mediawiki) with keys prefixed with "userjs-". You can e.g. easily get and set the options via javascript on a wiki page.

I don't see the advantage or equality of that way (from the huggle dev and user view)
This would mean a overhead in transferred html/js-code that is never used when using a wiki (preferences are transferred and set in the html-head).
Also HG-Prefs would not be seeable by others (most important version info but also other settings)
In addition there is currently no other way of disabling huggle access on per user basis, also for only a limited time amount ("enable:false"/ page delete + page protection)

In T76104#789703, @Qgil wrote:

They look indeed like better suited for tags.

Is it intentional that this are "normal" projects and not of (visual) type "Tag" as per https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Guidelines?

added VE Project as it's mentioned here and for all edits in merged T76063