Addons-server: “Edit Product Page” isn’t highlighted for an add-on with kanji characters in Developer Hub

[madalincm]

Prerequisites:

User should have an account in order to log in and should have an add-on with kanji characters submitted.

STR:

1. Access Developer Hub homepage: https://addons.allizom.org/en-US/developers/.
2. Click “My Add-ons” from the top menu bar, once the user is logged in.
3. Click the “Edit Product Page” link, located at the bottom of the kanji characters add-on.
4. Observe the page loaded.

Expected result:

“Edit Product Page”, located on the left side, in the light blue square, should be highlighted.

Actual result:

“Edit Product Page” is not highlighted.

Notes:

Reproduced in amo-dev, amo-stage and amo-prod with Fx68, Win10x64.
Reproduced also for the “Manage Authors & License” and “Manage Status & Versions” links.
This issue is only reproduced when the "Add-on URL" has kanji characters.

[willdurand]

@diox could you please transfer this issue to addons-server?

[eviljeff]

I think it's just https://github.com/mozilla/addons-server/blob/master/src/olympia/devhub/templates/devhub/includes/addons_edit_nav.html#L30 needs changing. I'd guess request.path is encoded somehow so non-ascii slugs don't match.

[harshsingla]

hi @madalincm ,will i can try to solve this issue as this is my first bug and want to solve this bug as quickly as possible

[eviljeff]

@harshsingla once you get a local instance of addons-server up and running let us know - you'll need it to test it works.

[harshsingla]

https://user-images.githubusercontent.com/44085127/63486819-a4dc9900-c4c6-11e9-9466-1f8fca7d5548.png

hi, @eviljeff as shown the edit product page is highlighted in the website as shown in the image ,you can check tell me what to do next .
thanks

[eviljeff]

@harshsingla the addon slug must contain non-ascii letters to replicate - the issue title references kanji (i.e. Japanese) but I suspect other characters may break it too (I replicated with some Korean)

[harshsingla]

@eviljeff sorry but i didn't get what you want to say ,are you talking about this.
https://user-images.githubusercontent.com/44085127/63571759-cad56c80-c59e-11e9-96e9-0aecd11e98f0.png

[eviljeff]

No, Addon.slug in the model, which is exposed on the developer hub page as "Add-on URL". And, as I said, you need addons-server running locally to test the patch. This is not a good first bug if you don't know django already.

[harshsingla]

okay,but sorry i have window 10 home so i can't use docker that's why i didn't run it locally and can't do more.
thank you.

[junngo]

@eviljeff Could I ask you about running locally?
I finished install using docker. I ran docker. And I try to enter addons-server ("http://olympia.test" or "127.0.0.1" or "127.0.0.1:80" and so on). I can't run addons-server.
I wonder that Only me, I can't run addons-server locally.

Note.
I can run addons-frontend (http://olympia.test:3000). And I can see addons-frontend page on the browser.

[eviljeff]

check the nginx container is running (restart it if not); look in the /logs/ for other errors if ngnix is running.

[junngo]

@eviljeff Thank you for your info. I checked status and log.
Nginx container is terminated only like under status(docker-compose ps).

So, I can't run addons server.

I checked log about nginx log(docker-compose logs).
This problems relate to this Issue[0]?
If not it is, I gonna think more about my problem.

[0] https://github.com/mozilla/addons-server/issues/10856

[diox]

You can just restart nginx when that happens (docker-compose up -d again should do it for you).

PS: Evelf and eviljeff are different users, please be careful when highlighting others in issues.

[junngo]

Thank you!!
Thanks to your info, I solved my problem.
Sorry, I gonna be careful about tagging user.

[junngo]

I'm checking this problem now.
I made this case and saw the problem on product page. And I try to make this bug on test(local) site.

When I made this bug on local page, I can't make this bug locally. Because I met 500 error:)

I wanna reproduce on local app. Could you give me tips to make 'my New Add-on' locally?

[diox]

It should work. You might have more information in the logs (found in the logs/ directory).

[Vishal19111999]

Hey I am interested in solving this issue. Please guide me.

[diox]

Please read @eviljeff comments earlier in the issue for more information about how to fix this.

[junngo]

I checked 500 error on my app locally. And I solved. The reason is that not enough permission where directory is. The directory place is /code/storage/files/temp. (This is add-on storage locally)

I reviewed about this Issue. As @eviljeff said, this problem not same request.path and url (i.e addon.get_dev_url() value)[0].

e.g)
request.path (IRI) form:
url (URI) form: developers/addon/%E8%99%8E-%E3%83%A9%E3%82%A4%E3%82%AA%E3%83%B3-test/edit

I have 2 methods to solve this problem.

1. This is url value change. I go to the get_dev_url() place and change format(uri -> iri) using uri_to_iri function.
   (e.g uri_to_iri(django_reverse(viewname, urlconf, args, kwargs, current_app)) [1] )
   But this method have a wide influence.

2. This is request.path value change. I use the template variable(made iri_to_uri() function) instead of request.path by adding variable to views.py [2].
   I think that this method is appropriate.

If My thought is right, Could I work on it? or If I wrong, Could you give me tips better than this?

[0] https://github.com/mozilla/addons-server/blob/8cd51164e8b22e2f3dd175e10504c9d5188ddc3e/src/olympia/devhub/templates/devhub/includes/addons_edit_nav.html#L30

[1] https://github.com/mozilla/addons-server/blob/8cd51164e8b22e2f3dd175e10504c9d5188ddc3e/src/olympia/amo/urlresolvers.py#L55

[2] https://github.com/mozilla/addons-server/blob/master/src/olympia/devhub/views.py

[eviljeff]

I think you're on the right path @junngo - changing get_dev_url() would affect too many places so we don't want to do that.

Adding a template variable is a better option (2) though it would need to be added to every view that shows includes the addon_edit_nav template (almost all of the single-addon views). Running uri_to_iri on request.path directly in the template would avoid that though I don't know of an existing jinja template filter to do that - it'd need to be the opposite of iriencode I guess. Do you know of one @diox?

[diox]

it'd need to be the opposite of iriencode I guess. Do you know of one @diox?

Actually... @junngo mentions above that calling iri_to_uri() on request.path should fix it, so I think modifying the template to do <li {% if url in request.path|iriencode %}class="selected"{% endif %}> should work ?

[junngo]

I was looking for it.
That is urlencode template filter.
If I use urlencode tag, I can simply fix it on addon_edit_nav template.

[alexandra-martin]

The issue was verified in Amo dev with ff69 on Win10x64.