Page MenuHomePhabricator

Double-click in text field can cause page reload and data loss
Closed, ResolvedPublicBUG REPORT


On my local MediaWiki installation, the "Edit pages on double click" preference causes a really bad behavior. This is not seen in production, so it could just be me or could be interaction with another feature. I'll try to figure that part out and will report back here.

Steps to reproduce:

  • Enable "Edit pages on double click"
  • Double-click anywhere on an article page, from any view including the history list or conflict workflow.

Result: You're navigated to a full-page editing interface.

Event Timeline

awight created this task.Apr 23 2020, 10:28 AM
Restricted Application added a project: archived--TCB-Team. · View Herald TranscriptApr 23 2020, 10:28 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
awight triaged this task as High priority.Apr 23 2020, 10:28 AM
awight changed the subtype of this task from "Task" to "Bug Report".
awight renamed this task from Major bug: double-click in text field can cause page reload and data loss to Double-click in text field can cause page reload and data loss.Apr 23 2020, 10:45 AM
awight raised the priority of this task from High to Needs Triage.
awight updated the task description. (Show Details)

I played around with this and can confirm that the double click feature is very poorly implemented:

Basically: Doing a double click anywhere inside a #mw-content-text container (which is the body of the page below the page title, excluding the page title) acts like the user clicked the "Edit" button in the top toolbar. Problem is: that #mw-content-text container is not conditionally set. It exists all the time, on all pages, special pages, your preferences, no matter what the action is, no matter what the state is. The only safeguard is a check if the "Edit" button even exists. It doesn't on special pages. But it does while resolving a conflict.

For some reason I'm not able to actually reproduce the issue locally (using Chrome). I still think we need to do something about this, just to be sure.

A possible fix is to catch dblclick events on our own .mw-twocolconflict-split-view container and "eat" them, so they don't reach the bad code in dblClickEdit.js.

Intriguing discoveries! I'd like to not introduce workaround code in TwoColConflict, I guess the next question is what protects production sites (and your local site!).

Wouldn't be more reasonable to check if mw.config.get('wgAction') == 'view'? I don't know what's the value of wgAction in case of edit conflict, but I'd guess it should be 'edit'.

daniel added a subscriber: daniel.

Tagging the Editing-team, untagging CPT. I don't see anything here for the core platform team to do.

DLynch closed this task as Resolved.Sep 2 2020, 3:13 PM
DLynch assigned this task to Krinkle.
DLynch added subscribers: Krinkle, DLynch.

Looks like @Krinkle independently made the view-only change in d6f0cd0643d3a66e66c38d35e64c311c6ef1e6e0 without knowing about this ticket.