Some buttons seem to have an off-by-one problem in Vector. Reported by User:Wikid77 at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Show_changes_clicks_Editing_help_on_Android
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
This seems to be related to the so-called "Big Blue Button" rollout, so perhaps @matmarex would be interested in taking a look.
Comment Actions
I am confused by this bug report.
On Google Android phone (Google Chrome) browser, the new oversize "Show changes" (button 3) clicks into "Editing help" (cheatsheet link) which is very bizarre because no "Cheat" buttons onscreen, and "Show changes" really should show changes on mobile phone edits (which are hard enough already).
It happens on any page (wikitext editor) in Vector skin (Monobook skin ok) while suppressing License blurb, but when logged out then "Show changes" clicks Show preview, on Android phone LG Escape2, version 5.1.1.
So does clicking "Show changes" give the same effect as clicking "Editing help", or as clicking "Show preview"? (Also, do the other buttons work correctly?)
I'm not sure how "Editing help" could be getting clicked at all, given that it is completely hidden when the toolbar loads. Unless the user has JavaScript disabled and therefore no toolbar.
"Show preview" getting clicked could potentially be some obscure browser bug we're triggering with our styles, although I've never seen such a thing before.
Or maybe they just fat-fingered the buttons, heh.
It would be helpful to see a screenshot of the screen they see.
Comment Actions
From his talk page:
"The Android display (in Desktop mode) changes depending on which button has been clicked, where the size of the "Save changes" or "Show preview" will expand, to cause the phone screen to wrap at "Show changes" on next line. The problem does not happen on Swedish WP (svwiki), although the SAVE button still shows blue, as: " Publicera ändringar ". On German WP (dewiki), the problem is even worse because show-preview "Vorschau zeigen" triggers a page-SAVE " Seite speichern " of whichever experimental text I have entered. To avoid the problem on preview, I append "&useskin=monobook" because Monobook works ok with the new buttons and activates the proper button as clicked."
Comment Actions
The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.
(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks... → Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)