Page MenuHomePhabricator

'Editing their own talk page' option has no effect when editing not selected
Open, Needs TriagePublicBug

Description

Steps to Reproduce:

  1. Go to Special:Block
  2. Block a user without editing disabled blocked and tick 'Editing their own talk page'
  3. log in as the blocked user
  4. You can edit your talk page

Actual Results:
User is able to edit talk page despite being blocked from it

Expected Result:
Either:
Grey 'Editing their own talk page' when editing blocks are disabled
Or:
Actually block the user from editing their talk page

Workaround:
Enable a partial block for User talk:usernamegoeshere

Event Timeline

RhinosF1 created this task.Jul 3 2019, 3:14 PM
Restricted Application added a subscriber: MGChecker. · View Herald TranscriptJul 3 2019, 3:14 PM
RhinosF1 updated the task description. (Show Details)Jul 3 2019, 3:14 PM

I think a better solution might be to rename "Editing their own talk page" to "Their own talk page" and move it under "Editing". That way it is clear that it needs to be enabled.

What do you think @Prtksxna?

I think a better solution might be to rename "Editing their own talk page" to "Their own talk page" and move it under "Editing". That way it is clear that it needs to be enabled.
What do you think @Prtksxna?

Sounds fine to me

I think a better solution might be to rename "Editing their own talk page" to "Their own talk page" and move it under "Editing". That way it is clear that it needs to be enabled.

Yep, that sounds like a good approach, I'd like to understand it a bit better — are you suggesting that we add it as a third radio option along with Sitewide and Partial?


Expected Result:
Either:
Grey 'Editing their own talk page' when editing blocks are disabled

That does seem to be the case for me. Could you please elaborate, maybe I am not understanding this fully.

dbarratt added a comment.EditedJul 8 2019, 3:27 PM

Yep, that sounds like a good approach, I'd like to understand it a bit better — are you suggesting that we add it as a third radio option along with Sitewide and Partial?

Uhh... it would be a a checkbox, aligned with the radio buttons (2nd level down) under the "Namespaces" field.

Something like this?


Does the checkbox only enable when Editing is checked and the Sitewide option is selected? If that is the case should it be indented under the Sitewide radio?

Something like this?

That looks great to me! what do you think @Niharika?

Do you think the text should drop the word "Editing"?

Does the checkbox only enable when Editing is checked and the Sitewide option is selected? If that is the case should it be indented under the Sitewide radio?

It is also enabled if you add a partial block for User_talk namespace.

dmaza added a subscriber: dmaza.Jul 10 2019, 1:11 PM

I'm a bit confused as to what is the issue here

Expected Result:
Either:
Grey 'Editing their own talk page' when editing blocks are disabled

Isn't this what's happening right now?

FWIW I think there is a spacing issue with T227199#5315877 between "Editing their [...]" and "Block account creation". But that might be just me.

dmaza added a comment.Jul 10 2019, 2:47 PM

If the issue is that after unchecking "Editing", "Editing their own [...]" remains checked (although disabled), that will/should be fixed on T221117: Special:Block checkboxes should remember checked state. I personally don't see a problem other than what's described on T221117

Without JavaScript it is possible for the form to be in a state where "Editing" is unchecked but "Editing their own talk page" is checked (and not disabled). In that case, we should probably throw an error instead of making the block.

@RhinosF1 Are you seeing the form in this state with JavaScript enabled? Like @Prtksxna and @dmaza I can't reproduce this, except by disabling JavaScript.

I agree that fixing T221117 will make this checkbox less confusing, and should negate the need to move the checkbox up.

Without JavaScript it is possible for the form to be in a state where "Editing" is unchecked but "Editing their own talk page" is checked (and not disabled). In that case, we should probably throw an error instead of making the block.
@RhinosF1 Are you seeing the form in this state with JavaScript enabled?

I honestly don't know. I'll test now on Chrome for iOS (All latest stable version)

Like @Prtksxna and @dmaza I can't reproduce this, except by disabling JavaScript.
I agree that fixing T221117 will make this checkbox less confusing, and should negate the need to move the checkbox up.

Tchanders added a comment.EditedJul 10 2019, 6:10 PM

@RhinosF1 Thanks for the screenshots. It looks like the site is using MediaWiki version 1.33.0 (https://publictestwiki.com/wiki/Special:Version) - we fixed the checkbox to become disabled since then in T224032.

I think we should keep this open, because it is still technically possible to make this type of block with JavaScript disabled.

@RhinosF1 Thanks for the screenshots. It looks like the site is using MediaWiki version 1.33.0 (https://publictestwiki.com/wiki/Special:Version) - we fixed the checkbox to become disabled since then in T224032.

Yes, they're all on latest stable

I think we should keep this open, because it is still technically possible to make this type of block with JavaScript disabled.

Niharika renamed this task from 'Editing their own talk page' option has no affect when editing not ticked to 'Editing their own talk page' option has no affect when editing not selected.Jul 10 2019, 9:05 PM

I created T227721 to move out the discussion about moving the checkbox which is not a solution to this task.

I think we should keep this open, because it is still technically possible to make this type of block with JavaScript disabled.

On second thoughts, we already have a task for that work (T224468), so I think we can close this.

Dinoguy1000 renamed this task from 'Editing their own talk page' option has no affect when editing not selected to 'Editing their own talk page' option has no effect when editing not selected.Jul 11 2019, 8:44 PM