Page MenuHomePhabricator

Step 1: anonymous edit warning (impact: high)
Closed, ResolvedPublic5 Estimated Story Points


As an editor I want to know if I'm in danger of unintentionally editing under an IP in order to not leak my IP.

We need to warn people if they are editing under an IP.



Warning_IP_Edit (1).png (976×1 px, 47 KB)


Error_generic_Mobile_instructions_2bs.png (1×750 px, 65 KB)

Please find design specs in this Figma artboard

GIVEN a user that is not logged in
WHEN opening the Bridge
THEN a warning screen is shown to inform them and give the option to log in instead of the usual Bridge content

GIVEN an anonymous edit warning
WHEN clicking log-in
THEN the editor is redirected to the login page
AND redirected back to the article they were editing

GIVEN an anonymous edit warning
WHEN clicking continue without logging in
THEN the editor proceeds to the usual Bridge content

Acceptance criteria:

  • Bridge detects if an editor opens it while not being logged in
  • Bridge shows warning to non-logged in editors
  • Editor is redirected back to the article they were working on after logging in
  • If editor decides they don't want to login, Bridge proceeds with a normal editing workflow

logging in
*the option "Edit without logging in" is presented as a primary action. This was decided in order to follow the current (and potentially familiar to users) order of the buttons presented by the Visual editor.

  • log in screen opens in the same tab
  • after logging in, user is redirected to article
  • they need to re-click the edit button
  • X closes the Bridge completely
  • Desktop to mobile button transition behaviour - Button width is always 100%. 24px horizontal margins are applied to the buttons div on desktop (above 499px break point) and removed on mobile (from 499px on). Vertical spacing between buttons increased from 8 to 16 px on mobile.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

notes from story writing:

  • existing patterns:
    • wikitext editor: warning banner over text input field
    • VisualEditor: popup coming out of the toolbar in the top right corner
    • Wikibase default: bubble in top right corner - mw.notify
    • Termbox: banner coming in from the top
    • Structured Data on Commons: same as Wikibase default
  • technically it is probably possible to do something similar in the same place as Wikibase does it but probably not the right thing for Bridge
Lydia_Pintscher renamed this task from Step 1: anonymous edit warning to Step 1: anonymous edit warning (impact: high).Mar 18 2020, 2:29 PM
Charlie_WMDE updated the task description. (Show Details)
Charlie_WMDE added a subscriber: Charlie_WMDE.

I assume the warning should take precedence over the loading screen, but the loading should still happen in the background. What happens, then, if there is an error (e. g. page protected on repo) while loading, before the user has dismissed the warning? What’s more important, the warning or the error? Do we leave the warning on the screen until the user has dismissed it, or replace it with an error as soon as the error happens?

hey @Lucas_Werkmeister_WMDE those are all very good questions.

warning should take precedence over the loading screen = yes
loading still happens in the background = yes
what's more important, the warning or the error = the error

which brings me to the last question

what happens when there's an error? ideally the error would be shown before anything else. that should be possible for repo protection etc, no? for server problems maybe not? but in that case it's fine to show the warning, then i guess the loading in the background would have failed anyway, and then we'd see the server error. once the warning screen (or any screen except for the loading screen) is shown in general, we should leave it until the moment the user interacts with it. so if they see an error, then until they fix it or dismiss it, the warning isn't shown. same goes the other way round. if we show the warning, we don't "interrupt" the screen by showing the error when it's ready.

hope this is helpful

ideally the error would be shown before anything else. that should be possible for repo protection etc, no?

No, unfortunately. We only know if the page is protected on the repo after making an API request, which takes a while. On the other hand, we know if this warning should be shown or not as soon as the bridge is opened, without further delay. There might be some error that can also happen immediately (I can’t think of one at the moment), but in general, the warning is going to happen before an error, unless we delay the warning (but you already said the warning should take precedence over the loading screen).

okay, that is indeed unfortunate. I would still keep this order then

  1. warning
  2. error
  3. bridge

loading screen where necessary but none of the screens above should be "interrupted" by any other screen (including the loading screen)

Okay, then I think that’s what my current changes already do. Thanks!

Charlie_WMDE added a subscriber: Michael.

when using vektor (not minerva) there seem to be additional margins that shouldn't be there. after discussing with @Michael it might be due to the icon height placement.

Screenshot_20200512_113423.png (157×250 px, 6 KB)

Screenshot_20200512_113410.png (217×468 px, 18 KB)

Change 595902 had a related patch set uploaded (by Michael Große; owner: Michael Große):
[mediawiki/extensions/Wikibase@master] bridge: Remove erroneous margin from anon warning message

Change 595902 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: Remove erroneous margin from anon warning message

Charlie_WMDE claimed this task.
Charlie_WMDE moved this task from Verification to Done on the Wikidata-Bridge-Sprint-19 board.