This seems to have been fixed with 3.4.13, apologies for being a month late. I am no longer getting NeedToken issues, or the logged out issues. If this was still not fixed, feel free to reopen this task. Courtesy ping @TheresNoTime .

This seems to have been fixed with 3.4.13, apologies for being a month late. I am no longer getting NeedToken issues, or the logged out issues. If this was still not fixed, feel free to reopen this task.

@Petrb After some further testing, 3.4.12 has not crashed like the way 3.4.13 and Qt6 has. If you don't mind, could I have a Qt5 build of 3.4.13 for testing? Thanks!

In T310766#10019615, @Petrb wrote:

wait, so it crashes no matter if you have to relogin, or only after you use the relogin form? I am trying to understand if they bug was introduced by fix of relogin form, or by shift to Qt6

In T310766#10016056, @Petrb wrote:

In T310766#10012829, @Yoshi24517 wrote:

In T310766#10004429, @Petrb wrote:

That bug still does trigger from time to time, even in this version, but the relogin form is working now, so while you are going to get a popup informing you about being logged out, you are going to get logged back in, with no need to restart whole huggle. This form normally works automatically, so it becomes just a minor issue.

I did some more testing, because it usually happens when doing the first action that requires editing the wiki in some way. It auto relogs me in, but at some points, Huggle just crashes without explaining why. The most recent crash which I caught, I attempted to revert an edit, Huggle said I was logged out for some reason, relogged me back in, and the app just closed. 3.4.12 never crashed. I checked Event Viewer, and it said Huggle crashed with exception code 0xc0000005.

so, the crash always happens after relogin form? during relogin, or randomly after being re-logged in?

@Petrb : I know its an unrelated issue, but it was brought to my attention in this thread: https://en.wikipedia.org/wiki/Wikipedia_talk:Huggle/Feedback#Automatically_added_to_list_of_users_%E2%80%93_an_unapproved_automated_edit , can we deprecate this? I don't think we need a constantly-updating list of everybody that uses Huggle. It has raised some concerns about it being an unapproved edit, that the user did not manually approve to be done. All semi-automated tools specify that we are responsible for every edit made, and me and Hey man Im josh feel this is no longer necessary. We may have to run an RFC to get consensus first. As of 3.4.13 it still readds you to the list after starting Huggle. Striking unrelated issue

In T310766#10004429, @Petrb wrote:

That bug still does trigger from time to time, even in this version, but the relogin form is working now, so while you are going to get a popup informing you about being logged out, you are going to get logged back in, with no need to restart whole huggle. This form normally works automatically, so it becomes just a minor issue.

Seems to be working fine, the Aborted NeedToken didn't trigger first, so I may need to keep reloading until it happens. No issues with Qt6 build whatsoever when installing.

Possible fix over at T310766, I’m going to test tomorrow but would like others to test as well.

In T310766#10000627, @Petrb wrote:

please note this is Qt6 build, regular huggle downloads are all Qt5 based, so let me know if there were any problems related to Qt6 or installation failed, I can try to recreate Qt5 build as well

In T310766#10000145, @Petrb wrote:

Yes, which operating system?

In T310766#9999483, @Petrb wrote:

Hello, I know it's been years, but this was finally partially fixed here https://github.com/huggle/huggle3-qt-lx/commit/887bb8f821ecb8db94235ad11967aaf1c0e1b1d1

the underlying problem with mediawiki API still remains, but at least now the relogin form is working properly for bot passwords as well as for regular passwords

Probably worth mentioning over at T288104 that a possible solution is there, still needs further testing.

Can this issue be fixed at some point? I'm at 5 relogs with the issue still occurring after each relog, and it is driving me up the wall.

This is happening to me on enwiki, but all that is showing, is "No access" for the country. All the other stuff I am able to see is there as normal. It does not say not able to be retrieved, just that I have no access to the country.

In T288104#8678481, @Hummerrocket wrote:

Actually, it doesn't say "Aborted, needed token", it only spams the "logged out of MediaWiki" error. I thought that these two errors are closely related, since the image in the bug description also has a dialog box for the "logged out of MediaWiki" error.
Nevertheless, exiting and logging back in did not fix the error :(

In T288104#8675075, @Hummerrocket wrote:

Unfortunately, I am still hitting this error. I ensured that I am on version 3.4.12, which I downloaded, and it says I am on 3.4.12 when I launch Huggle. However, when attempting to add any page to a watchlist (Alt + X), I get the same error repeatedly ("It looks like you were logged out of MediaWiki for whatever reason").

XMLRCS died again, redis empty for at least 10 seconds.

This I believe is fully fixed as of version 3.4.12. I'm editing without any issues whatsoever after continuing to test. Feel free to reopen if this issue pops up again.

Seems to actually be fixed, did a test edit on my talk page, and reverted using Huggle while logged in with a BotPassword and it went through, will continue testing, this is with version 3.4.12.

XMLRCS is back up now and running!

XMLRCS is down again, Huggle continues to switch feed to IRC.

Also just would just like to drop a note, using a BotPassword with or without 2FA triggers the Aborted NeedToken error as well.

Just got granted 2FA as well, and set it up, and am also getting that dialog box, changing the BotPassword did not help, neither did relogging into Huggle.

I didn't mean the code. I meant the eventLogging data. (Scratch that comment.)

Where can I find the eventLogging data? I would like to look at the cookieBlock extension.

In T149019#2797525, @Cameron11598 wrote:

In T149019#2797504, @Yoshi24517 wrote:

In T149019, @Urbanecm wrote:

2016-11-16 14:00 UTC exactly :).

What is the UTC time converted to PST (Pacific Standard Time)? I just wanna know because I mainly use that time zone and because I would like to know what time I will lose my patrolling privileges. Thanks!

Currently the conversion is UTC -8. So that would be 0600 hrs pacific.

In T149019, @Urbanecm wrote:

2016-11-16 14:00 UTC exactly :).

Once the first patch comes out (on what I hear to be Halloween at 23:00 UTC), how long will it be until the next patch gets deployed?