Page MenuHomePhabricator

Enter in edit summary line should save on ja.wiki if I'm not using IME
Open, LowestPublic

Description

  1. Visit a random page on ja.wiki
  2. Reach action=edit
  3. Press tab or otherwise move the cursor in edit summary text area
  4. Press enter

I. Expected: the edit is saved.
II. Observed: nothing happens and I have to click the button.


Version: wmf-deployment
Severity: normal
URL: http://ja.wikipedia.org/wiki/Special:Random?action=edit
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72945

Details

Reference
bz72944

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:44 AM
bzimport set Reference to bz72944.
bzimport added a subscriber: Unknown Object (MLST).

If I recall it correctly, this is a behavior added by [[:ja:MediaWiki:Common.js]], not MediaWiki. It can be toggled with the variable summaryEnterRejectDisable.

I believe the reason behind this behavior was to prevent unintended saving, which happens rather frequently due to the use of IME.

Closing as INVALID as per comment 1

(In reply to Yusuke Matsubara from comment #1)

I believe the reason behind this behavior was to prevent unintended saving,
which happens rather frequently due to the use of IME.

What IME? Sounds like a bug. :)

(In reply to Nemo from comment #3)

(In reply to Yusuke Matsubara from comment #1)

I believe the reason behind this behavior was to prevent unintended saving,
which happens rather frequently due to the use of IME.

What IME? Sounds like a bug. :)

[[Input method]]. Inputting Japanese language typically involves frequent uses of the enter key in the midst of a sentence. This sometimes causes unintentinal saving without the JS hack to prevent it.

It might be possible for MediaWiki to observe the IME on/off and add some mechanism for IME-friendliness, but that might be another bug to report.

If anybody wants to turn this into an IME bug, please adjust the summary and component. I still consider the current summary INVALID as it's on-wiki code

(In reply to Yusuke Matsubara from comment #4)

[[Input method]]. Inputting Japanese language typically involves frequent
uses of the enter key in the midst of a sentence. This sometimes causes
unintentinal saving without the JS hack to prevent it.

Are such schemes (e.g. the use of enter) documented somewhere?

It might be possible for MediaWiki to observe the IME on/off and add some
mechanism for IME-friendliness, but that might be another bug to report.

This bug was filed from the perspective of a non-ja user, so it makes sense to just adapt the summary.

You can probably read all about IMEs on Wikipedia.

It has been explained that this is an on-wiki issue, and how to disable this behavior for yourself.

There's the hint of a bad code smell here... if wiki communities need to implement custom JavaScript hacks to achieve reasonable/expected behavior, something feels awry.

(In reply to Nemo from comment #6)

(In reply to Yusuke Matsubara from comment #4)

[[Input method]]. Inputting Japanese language typically involves frequent
uses of the enter key in the midst of a sentence. This sometimes causes
unintentinal saving without the JS hack to prevent it.

Are such schemes (e.g. the use of enter) documented somewhere?

I don't know of a document specifically explaining this nor what a more general and cleaner solution than the hack look like, but I'll try explaining the problem as I see it.

A typical IME window looks like a combo box [1] which appears after you enter some pre-conversion text and press the conversion key (which is typically the space bar). In the window, you will select a candidate by going up and down with the arrow keys and decide on by pushing Enter.

For example, in order to input 誤字を修正しました [2] you may type "gojiwoshuuseishimashita<space><enter>" (for simplicity, I assume the system always suggests the correct conversion result at the top candidate). You may alternatively type "goji<space><enter>wo<enter>shuusei<space><enter>shimashita<enter>". Some people prefer the latter, partly because longer fragments (as in the former) sometimes result in a screwed up conversion due to the greater ambiguity in word segmentation.

It's not rare for a user to hit Enter twice accidentally while trying to finalize a piece of conversion, and it results in an unintentional saving if you are on a text box.

A possible solution I can think of is to detect an IME on/off event [2] and add a confirmation prompt to ask "do you really want to save this?" upon an Enter event. (I'm not too about the feasibility.)

[1] https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#candidate-window
[2] Goji wo shusei shimashita / "I have fixed a typo"
[3] http://stackoverflow.com/questions/7297124/detect-if-using-ime-for-input-in-browser

For example, in order to input 誤字を修正しました [2] you may type "gojiwoshuuseishimashita<space><enter>

I don't see this happening so I assume this is about some OS IME, not ULS IME.

A possible solution I can think of is to detect an IME on/off event [2] and add a confirmation prompt to ask "do you really want to save this?" upon an Enter event.

A simpler solution would be to disable the JS hack if I'm not using Japanese interface language OR I disabled the ULS IME. Ideally, however, MediaWiki core would be able to identify when the user is using a non-MediaWiki IME and disable the submit on enter behaviour.

For example, in order to input 誤字を修正しました [2] you may type "gojiwoshuuseishimashita<space><enter>

I don't see this happening so I assume this is about some OS IME, not ULS IME.

Right. I was talking exclusively about OS IME. Sorry for not being explicit about it.

A possible solution I can think of is to detect an IME on/off event [2] and add a confirmation prompt to ask "do you really want to save this?" upon an Enter event.

A simpler solution would be to disable the JS hack if I'm not using Japanese interface language OR I disabled the ULS IME. Ideally, however, MediaWiki core would be able to identify when the user is using a non-MediaWiki IME and disable the submit on enter behaviour.

I'm not sure how the ULS IME is related to this bug except for possible interference between the two systems. Does the ULS IME has a mode with a candidate window, similar to what I wrote above? (I'm assuming no.)

I think environments can be classified into 1) No IME, 2) OS IME, 3) ULS IME. Correct me if I'm wrong, but I don't know a situation where one wants to use both.

I think it's more predictable for users if the edit-summary behavior is changed based on the OS IME status and whether it uses a candidate window or similar, which requires the user to select and hit Enter. As far as I know, it includes a large number of Japanese and Chinese input systems, and some spell-correcting input systems for other languages. If such precise detection is not possible, an acceptable approximation would be to make it dependent to the language in which the user is trying to input (Japanese and Chinese) and the status of being the OS IME turned on.

Regarding the idea to make it interface-language-dependent, note that the user's language preference on viewing (interface language) does not necessarily match the preference on inputting, especially when the content language is different from interface language. Some may prefer to see system messages in English (for reasons for consistency or some JS scripts they use) when contributing a wiki mostly written in Japanese.

Aklapper triaged this task as Lowest priority.Mar 23 2015, 5:19 PM
Aklapper subscribed.