Last modified: 2005-10-19 06:55:10 UTC
For example, if User:trollinator is blocked for 24 hours at 1005 Sunday and
clicks on a broken link at 0955 Monday, the IP address she is using is blocked
until 0955 Tuesday.
Possibly related to bug 1156, bug 1204
It should be noted that this bug was there from the very beginning. It is a
known design flaw (I believe bug 1204, at least, is new).
Is this a bug or intended behavior?
This is a bug. People are regularly blocked for longer than originally intended because of
this bug. I get emails about it all the time.
A better behaviour would be to autoblock the IP for a length of time that would expire at the
same time as the original block, but with a maximum (such as 24 hours).
*** Bug 1888 has been marked as a duplicate of this bug. ***
I would have raised this as critical prio. Smaller wikipedias don't have admins
online 24/7 and longer-than-required blocks may raise significant noise.
The effect of this bug is to reset a user's block from the start whenever they click "edit
this page". However, as I understand it, users do not find out *by software* that they are
blocked until they actually go to this edit page. As a result, their block does not always
technically start until they actually try to edit. And if they go back to an edit page to re-
read their block information (such as to get the name of the blocking administrator) the
block starts again on their current IP address. As far as I know, this is not the intended
effect of blocks.
I should add that this happens even when you're logged in under the username
that was originally blocked (logged in as User:trollinator). I'm not sure if
this should require a different report or not, but it would be helpful to
display a 'view source' that displays the source since they can't edit at the
time (same as when a page as protected). Yes, you can get an xml dump of the
page, from from a UI standpoint it makes more sense to have this option which
the users are used to.
I've encountered this behavior in the past but have only gotten a real grasp on
what is happening since I've examined the source code.
The problem is in User::spreadBlock() which is executed when
User::GetBlockedStatus() for a logged-in user determines that a user block is in
progress. The function User::spreadBlock() then looks to see if the IP address
is already blocked. If so, it calls Block::updateTimestamp(), which calls
Block::getAutoblockExpiry() to calculate the new expiry time. After checking
that the IP block was an autoblock, this simply adds the global constant
$wgAutoblockExpiry to the timestamp. The default value of this constant is
86400, which programmers will recognise as the number of seconds in a day.
By contrast, if the IP address was not already blocked, the autoblock expiry
time is only set to time+86400 if this is earlier than the user block expiry
time. This code should also be executed in Block::updateTimestamp(). I'm
fixing this in my test wiki now.
(email@example.com needs to be added to the CC list when changing
Created attachment 944 [details]
Fixed the bug. Check if the auto-block excedes the user-block
If auto-block excedes the user-block, then the auto-block would not be
prolonged for another 24 hours.
Created attachment 952 [details]
Patch for the fix