933592 - The composition string is overlapped with the "I'm thinking of..." string in the search box of everything.me

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

Description

[Luke Chang [:lchang] (inactive)]

Attachment: Screenshot

gaia: 987e1035d32ded28c830ad5867e38d6ee15e107a
gecko: a4511eaf5fb2a6cabac9082485089a7a35eee03f

Please refer to the attachment for this bug.

You can try this issue by using pinyin IME since it is the only layout engine which uses new composition APIs so far. You may need using "GAIA_KEYBOARD_LAYOUTS=en,zh-Hans-Pinyin make reset-gaia" to enable pinyin IME after Bug 884752 is landed.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Evyatar, could you take a look?

Bruce, are we shipping any v1.2 build with both Pinyin IME and E.me enabled?
If not this bug is probably not koi+.

That said, I can say that bug is fairly trivial (maybe as simple change the event name from keypress to input), so if this is fixed we could a+ the patch.

Comment 2

[Ran Ben Aharon [:ranbena] EverythingMe]

The behind text comes from a standard placeholder attribute on the <input>. Not handling any events here.
Can you check if this can be reproduced on the browser as well?

Comment 3

[Luke Chang [:lchang] (inactive)]

Hi Ran, It can not be reproduced on the browser and the other apps with placeholder like "contacts" and "messages".

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Ran Ben Aharon (Everything.me) from comment #2)
> The behind text comes from a standard placeholder attribute on the <input>.
> Not handling any events here.
> Can you check if this can be reproduced on the browser as well?

Interesting .... if e.me is not at fault here we would have to kick this bug to the platform.

(In reply to Luke Chang [:lchang] from comment #3)
> Hi Ran, It can not be reproduced on the browser and the other apps with
> placeholder like "contacts" and "messages".

Would it be possible they are not using html5 placeholder?

Comment 5

[Luke Chang [:lchang] (inactive)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #4)
> Would it be possible they are not using html5 placeholder?

I created a test app which contains only pure html5 placeholder and it works.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hum, I see similar thing on when I working on my add-on in Firefox and I found that I did not send the composition with proper closure attribute.

Maybe we didn't do that properly in B2G either. If we didn't do anything fancy when we call inputContext.setComposition(), supposedly the closure attribute would be set here:

http://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/forms.js#l1115

Evidently the underline is being drawn. Need more investigation next week.

Another bug I found is that e.me did not start search as we type. I am confident this is a bug in e.me because you must have rely on some event to start searching :P We should file another bug after this one.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

:masayuki is the person to needinfo once we could confirm we didn't misuse the |clauses| parameter of the API method.

(it's "clauses" not "closures" O_o)

Comment 8

[Amir Nissim (:amirn)]

Attachment: redirect to PR 13398.html

Comment 9

[Evyatar 'Tron' Amitay (everything.me)]

Comment on attachment 827636 [details]
redirect to PR 13398.html

r+ for the PR, not sure if we need to ni? the l10n guys for this.

Comment 10

[Ran Ben Aharon [:ranbena] EverythingMe]

Amir, can you add the new l10n key to the other 3 languages as well?

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Evyatar 'Tron' Amitay (everything.me) from comment #9)
> Comment on attachment 827636 [details]
> redirect to PR 13398.html
> 
> r+ for the PR, not sure if we need to ni? the l10n guys for this.

So we indeed need to remove the <span> and use placeholder instead ...

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> Another bug I found is that e.me did not start search as we type. I am
> confident this is a bug in e.me because you must have rely on some event to
> start searching :P We should file another bug after this one.

Do you want to fix this behavior in the same bug or should I file another one?

Comment 12

[Ran Ben Aharon [:ranbena] EverythingMe]

Tim, yes we would prefer a separate bug for the other issue you mentioned.

Comment 13

[Ran Ben Aharon [:ranbena] EverythingMe]

Comment on attachment 827636 [details]
redirect to PR 13398.html

Ok so the other l10n files aren't necessary. You may proceed!

Comment 14

[Amir Nissim (:amirn)]

landed in master https://github.com/mozilla-b2g/gaia/commit/f4a2321cbd1ff2aaa9f66edccbbdbc5129a70b83

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Ran Ben Aharon (Everything.me) from comment #12)
> Tim, yes we would prefer a separate bug for the other issue you mentioned.

bug 935845 filed. Thanks!

Comment 16

[bhavana bajaj [:bajaj]]

Do we still need this resolved for 1.2 given pinyin was needed primarily for flatfish which is not a 1.2 target now ?

Comment 17

[Bruce Huang [:bhuang] (inactive)]

At the moment there's nothing that uses both simplified Chinese and e.me, so koi can probably live without it.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

-'ing based on comment above.

Comment 19

[Jason Smith [:jsmith]]

Clearing nom - this is already part of 1.3, so this doesn't need to be triaged.