Last modified: 2013-07-24 02:53:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T53490, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 51490 - In RTL (hewiki and arwiki) wikis, can't remove categories
In RTL (hewiki and arwiki) wikis, can't remove categories
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
Editing Tools (Other open bugs)
unspecified
All All
: Highest blocker
: VE-deploy-2013-07-25
Assigned To: Moriel Schottlender
:
Depends on:
Blocks: ve-rtl
  Show dependency treegraph
 
Reported: 2013-07-16 23:25 UTC by kipod
Modified: 2013-07-24 02:53 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description kipod 2013-07-16 23:25:36 UTC
Pressing the Category button (under "page Settings") in RTL wikis do not open the "single category form" (like it does on enwiki), so one can't remove the category (one can still add new categories through "page settings", though).

the problem is not specific to hewiki or arwiki, but rather to "uselang=he" or "uselang=ar".


REPRODUCTION INSTRUCTIONS
1) open [[en:Ido Pariente]]
2) press "edit"
3) add "&uselang=he" to the address line and press <Enter> (should get you here: https://en.wikipedia.org/w/index.php?title=Ido_Pariente&veaction=edit&uselang=he )
4) click the cog next to "הגדרות עמוד" (this is "page settings" in hebrew)
5) click on one of the category buttons

WHAT YOU EXPECT
the category form should open. the form contains the little trashcan that lets you remove the category.
(try it without "&uselang=he" to see the form)

WHAT ACTUALLY HAPPENS
nothing.

TESTED WITH BROWSERS
chrome and ff.


peace.
Comment 1 kipod 2013-07-16 23:33:15 UTC
(not sure whether this warrants a different bug):

while in "&uselang=he" state, try to add new category: though it is possible, notice that the autocomplete feature is missing

REPRODUCTION:
0-4) steps 0-4 same as comment 0
5) begin typing a category name. notice therre is no autocomplete.

peace.
Comment 2 kipod 2013-07-16 23:47:27 UTC
(In reply to comment #0)
...
> category (one can still add new categories through "page settings", though).
> 
> peace.

my bad: the "add category" input line exists on the form, but does not work: when you add a new category and press "החלת שינויים" (i.e., "Appy chnages"), the category is not actually added to the page.

peace.
Comment 3 kipod 2013-07-16 23:57:22 UTC
(In reply to comment #2)
> (In reply to comment #0)
> ...
> > category (one can still add new categories through "page settings", though).
> > 
> > peace.
> 
> my bad: the "add category" input line exists on the form, but does not work:
> when you add a new category and press "החלת שינויים" (i.e., "Appy chnages"),
> the category is not actually added to the page.
> 
> peace.

my bad second time: my confusion was because of the autocomplete problem, but one *can* add new category: you just have to press <Enter> explicitly. (with autocomplete, you normally click on the new cat name with the mouse - without autocomplete, you don't have this option).

peace.
Comment 4 John Mark Vandenberg 2013-07-17 04:51:52 UTC
Can confirm that Categories dialog is busted in RTL.  No autocomplete, and clicking on existing categories does not allow category removal.
Comment 5 Gerrit Notification Bot 2013-07-20 11:06:50 UTC
Change 74835 had a related patch set uploaded by Mooeypoo:
RTL Fix for Category Popup

https://gerrit.wikimedia.org/r/74835
Comment 6 Moriel Schottlender 2013-07-20 19:17:43 UTC
Okay, I know (more or less) how to solve it, but there are a couple of issues I must raise with the VE team so I can figure out a proper solution. 

The problem is that the menu element has its left position calculated dynamicallym and when we have an RTL widget, the positions are all flipped. 

I can fix it by making a quickfix for RTL using this.$.parent as the wrapper to flip against (basically, "flip the coordinates of anything inside that parent").

However, if I do that, the link widget (which uses the same menu widget class) gets all messy and out of position. 

The issue as far as I understand it is that the frame parents change between the link (parent being the editable surface) and the category menu (parent being the page settings widget). I need to find a general-enough "parent" call, or find a way to call the 'position' method on the category-menu only, leaving the link alone.

This will have to wait until after the weekend, when the VE team are available for some help on this.
Comment 7 Amir E. Aharoni 2013-07-20 21:28:44 UTC
This is a blocker for wider deployment on right-to-left wikis.
Comment 8 Moriel Schottlender 2013-07-22 04:33:54 UTC
Problem appeared to be solved in the newest Patchset. Awaiting review and confirmation.
Comment 9 Amir E. Aharoni 2013-07-22 07:25:13 UTC
I confirm that the latest patch set solves the problem functionally. Thanks, Moriel.
Comment 10 James Forrester 2013-07-24 02:53:43 UTC
Done and will be deployed tomorrow. Thank you, Moriel! :-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links