Description: When language is set to Arabic, an empty body text box in messages app can be scrolled up and down although the placeholder text is only one vertical line. If user taps on empty body text box in a new or existing message thread then dismisses the keyboard, they can scroll up and down in empty text box. Repro Steps: 1) Update a Flame to 20150213010213 2) Set language to Arabic 3) Launch Messages app 4) Create a new message thread 5) Tap message body text box 6) Dismiss keyboard 7) Scroll text box up and down Actual: User can scroll empty message body text box vertically. Expected: User cannot scroll empty message body text box. Environmental Variables: Device: Flame 3.0 Master Build ID: 20150213010213 Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e Gecko: 2f5c5ec1a24b Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Repro frequency: 3/3, 100% See attached: Youtube video clip: http://youtu.be/2KE1Y9lQJvI

Issue DOES occur on Flame 2.2 User can scroll empty message body text box vertically. Device: Flame 2.2 Build ID: 20150112010228 Gaia: f5e481d4caf9ffa561720a6fc9cf521a28bd8439 Gecko: bb8d6034f5f2 Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76 Version: 37.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Seems minor so not nominating to block on this.

This does not seem to happen on Firefox Desktop.

Not too bad to make it a p1,p2.

I cannot reproduce it on flame 3.0 (20150218010226) nor on flame 2.2 (20150217162505).

Btw I have V188 as a base image. As I cannot reproduce on v2.2 AND v3 with 2 different gecko, that might be related to the base image.

This issue does reproduce on latest Flame 2.2 and 3.0 with latest firmware (v18D-1). Should we be checking RTL issues in the old v188 base image? In new or existing sms message user is able to scroll vertically on the empty body text box when language is set to Arabic. Device: Flame 2.2 BuildID: 20150218002515 Gaia: da509caa7395d3d090ce973e8de082b4680a590d Gecko: 96da179a7d3a Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Device: Flame 3.0 Build ID: 20150218010226 Gaia: 82f286f10a41aab84a0796c89fbefe67b179994b Gecko: 9696d1c4b3ba Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Augustin, do you use the latest arabic translations too?

Julien, yes I do. (following https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Localizing_Firefox_OS#Mobile_l10n_testing) I'm pretty sure this is due to diff between v188 an v18D-1. It could seem odd, but I have 4 other bugs that are quite similar, and each time, the only diff I can see is the base image.

I DO reproduce with latest base image V18D-1 (same gaia same gecko as my test on V188) So according to my test : V188 OK V18D-1 NOK That's fun actually :-)

This is likely a font difference. Maybe you can check if the arabic font changed between base builds. This could be a bug we'll want to fix in the font metrics :/

Julien, jlorenzo told me that the font didn't change between these 2 images :-/ I'll try to check if I have a bit of time in the next few days :-) Thanks for the idea !

Hey Augustin, any chance that you have some time to look into this one (taking up from comment 12 :P) thanks!

Hey Delphine! In total honesty, I guess not :-/ I'm already strugglings to finish the few bugs I'm assigned on. Moreover, this is really outside my knowledge, so if I do it, it'll take me time. It is better if someone else take it I think :-)

Okay it seems I know what is the problem here: * I can't reproduce this bug if I flash base v188 or v18D image and then shallow flash gecko + gaia; * I can reproduce if I flash full image via pvt tool; These two images have quite different font set (/system/fonts): for v188/v18D we have 121 fonts, for the image we got from pvt we have only 68 fonts. Issue described in comment 0 is caused by absence of "DroidNaskhUI-Regular.ttf" font in pvt image, if you push only this font to /system/fonts the issue will be fixed. So I'm closing this issue as invalid, since it's very likely that wrong image was used, for other Arabic font improvements please see bug 1150394 and bug 1150449. Brogan, could you please make sure that you use correct flame image and you have full font set (eg. adb pull /system/fonts)? Also feel free to reopen this issue if I'm wrong.

Naoki, can you help with the pvtbuilds full image issue as described in previous comment ?

That sounds more or less like we need to update the system fonts... looking...

So the difference is : 3 fonts missing on 18D, and 56 fonts missing on the MC Nightly: https://docs.google.com/spreadsheets/d/1V8hQEFtpgqzAyUH1kXtStIOpUx2nLEnXJ7k7giH4gWM/edit?usp=sharing Need to investigate whether the variant=USERDEBUG limits the fonts and/or if the blob that releng is using to build Flame builds have the fonts.

I think the blob is missing the fonts... that's why it's missing in the builds. I looked in my own backup-flame build.

Probably better to look at the blob that was given to releng from bug 1117859; Looking at the blob the fonts contained are the same as 18D. Verified that the blob is the same: http://hg.mozilla.org/mozilla-central/file/078128c2600a/b2g/config/flame-kk/releng-flame-kk.tt Need to figure out where we pull push the fonts in the build process....

Hrm. Meanwhile, I think I can just pull the different fonts and make a font package. It might take me a bit, unless I get help from someone that knows the fonts/build structure...

Oh duh. search in bugzilla: https://hg.mozilla.org/mozilla-central/rev/a39986967fbd It's in <project>/external/moztt

ya the fonts are missing. I'm not sure about the font licensing for the missing fonts. If we have the licenses to use those fonts, I think we just need to have a PR and push the fonts there. Do you want me to file a new bug in regards to the fonts in the repo? Or should we just work in this bug and reopen it?

Here's a package of the fonts that are missing.

So it means moztt does not have the fonts shipped with v18D ? I think it makes sense to file a separate bug, and raise the issue on the (old) thread about the v18D package. Can you take care of this?

If you are busy just tell it :) Oleg or I can follow this up.

It means that new fonts sets is made in our builds, and our builds don't have the fonts needed. It is a problem with the repo, not the 18D build. I will follow up with a new bug.

follow up bug 1152420

Issue appears fixed on Flame 3.0 with new fonts pushed. On Flame 3.0 full flash without fonts package, this issue still reproduces. After pushing fonts in zip from attachment 8589400 [details], the issue described in comment 0 no longer reproduces. User is unable to scroll the empty text box with language set to Arabic. Device: Flame 3.0 Build ID: 20150410010202 Gaia: e768af6558957ddb0f6a9ce579ea41c3e3d0b203 Gecko: fec90cbfbaad Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 40.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Per comment 29 and and my own verification, user cannot scroll empty message body text box in Flame v2.2/master and N5 v2.2/master. So mark as VERIFIED DUPLICATE. See attachment:Verify1_v2.2.3GP. Reproducing rate:0/10 Device information: Flame v2.2 Build ID: 20150721162504 Flame master Build ID: 20150721160205 N5 v2.2 Build ID: 20150721002506 N5 master Build ID: 20150721160205