733482 - utf-8 characters not shown after a native app install

Status: RESOLVED DUPLICATE of bug 750515

(Firefox Graveyard :: Web Apps, defect, P2)

Description

[[e-mail] [:onecyrenus]]

If you run node run.js on the latest github repo 

http://127.0.0.1:60172/tests/appstore.html and do a native install of the 3rd app with japanese characters. The japanese characters do not show on the native app install.

Comment 1

[[e-mail] [:onecyrenus]]

To be more explicit, once you go to %APPDIR%, the applications name has been truncated to just include the western characters.

Comment 2

[Jason Smith [:jsmith]]

Definitely moz-central worthy.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

this bug was filed in the previous add-on implementation and then moved over to verify. can anyone check if this still happens in the native implementation that is in moz-central?

Comment 4

[Jason Smith [:jsmith]]

Sure. In the future, flag the bug with qawanted to indicate that a QA needs to do more testing for a particular bug.

Comment 5

[Jason Smith [:jsmith]]

Still happens on mozilla central with Win 7 64-bit. This manifest fails to include japanese characters when you install the application:

{
	"developer":
	{
		"url": "http://quality.mozilla.org",
		"name": "Mozilla QA"
	},
	"launch_path": "/testcases/fancybox.html",
	"installs_allowed_from": ["*"],
	"icons":
	{
		"126": "/appinstall/qalogo.png"
	},
	"name": "テスト Test App テスト",
	"description": "An app for running runtime test cases with native applications"
}

Comment 6

[Ed Lee :Mardak]

stripStringForFilename uses ^\W* to strip the beginning characters. This could probably be scoped down to certain invalid starting characters instead of all non alphanumeric.

Comment 7

[Ed Lee :Mardak]

Attachment: v1

Remove spaces and certain special characters from the front of the filename.

Comment 8

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

This is another sanitization bug like bug 747412.  It's fine to put a bandaid on this issue for now, but I think we should rework our sanitization code entirely.  For example, on Windows we need to do something if the filename santizes down to "com1" or another device name.  I've filed bug 750515 to rework our filename sanitization on Windows, and I think we should file an equivalent bug on Mac.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Tim Abraldes from comment #8)
> This is another sanitization bug like bug 747412.  It's fine to put a
> bandaid on this issue for now, but I think we should rework our sanitization
> code entirely.  For example, on Windows we need to do something if the
> filename santizes down to "com1" or another device name.  I've filed bug
> 750515 to rework our filename sanitization on Windows, and I think we should
> file an equivalent bug on Mac.

+1. Agreed. I'll file a tracker bug for Mac now.

Comment 10

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 619688 [details] [diff] [review]
v1

Mardak, do you mind if we do not take this patch, and go straight for bug 750515? The sanitization code was overly strict but it's probably better to get it right in one swoop rather than opening on a case-by-case. If there's a good reason for taking this patch meanwhile, please renominate.
(I'm working on bug 750515 at the moment)

Comment 11

[Jason Smith [:jsmith]]

Marking for re-triage - in the android webrt triage, even though it was noted that the desktop equivalent of this UTF-8 bug was a P2, the drivers in the room actually came to an agreement that the android version was a P1. Knowing that there's a difference in priorities makes me think that we might want to re-triage this to see if this is a P1. If not, provide an explanation why the android version has a higher priority over the desktop version.

Android equivalent - bug 766604

Comment 12

[Jason Smith [:jsmith]]

(In reply to Felipe Gomes (:felipe) from comment #10)
> Comment on attachment 619688 [details] [diff] [review]
> v1
> 
> Mardak, do you mind if we do not take this patch, and go straight for bug
> 750515? The sanitization code was overly strict but it's probably better to
> get it right in one swoop rather than opening on a case-by-case. If there's
> a good reason for taking this patch meanwhile, please renominate.
> (I'm working on bug 750515 at the moment)

Felipe - What should we do here? I know a while back there was going to be work to improve the sanitization code in the bug you've specified, but it's been two months now since other bugs got higher priority. Should we review and see if we should land this? Or still hold off until the other bug gets fixed that you've specified?

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Jason: can you provide more details about the reasoning behind the Android drivers' decision?  Desktop runtime drivers are willing to reconsider the priority of this bug, but not merely because Android drivers made a different decision on a related bug for their feature.  We need to know why they made that decision to know if their rationale also applies in this case.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> Jason: can you provide more details about the reasoning behind the Android
> drivers' decision?  Desktop runtime drivers are willing to reconsider the
> priority of this bug, but not merely because Android drivers made a
> different decision on a related bug for their feature.  We need to know why
> they made that decision to know if their rationale also applies in this case.

Ragavan - Can you provide more context here for a rationale for making the UTF-8 bug on Android WebRT a P1?

Comment 15

[Marco Castelluccio [:marco]]

This would be fixed if we fixed 750515.