421275 - Thai above and below vowels display incorrectly in URL bar

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Isriya Paireepairit]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008030504 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008030504 Minefield/3.0b5pre

Mac OS X build 2008030504

When typing any of Thai character
- Above level vowels (U+0E34-0E37)
- Below level vowels (U+0E38-0E3A)
- Tone marks (U+0E47-0E4E)
without Thai alphabet in URL bar, search box and content forms as the first character, it displays incorrectly. The visible glyph seems randomly displays. The vowels in autocomplete drop down also incorrectly displays (sometimes missing). Please see the attached screenshots.

This typing order is unusual in Thai spelling. If typing in normal way (letter + vowels), Firefox displays them properly.

Copy and paste got the same result.

I think this is regression. Don't see this in last week builds.

Reproducible: Always

Steps to Reproduce:
1. Type any characters defined above (or try copy this " ี " and Paste) into blank URL bar or form
2. 
3. 
Actual Results:  
The character displays incorrectly

Expected Results:  
Should display the same glyph reflect in the Unicode table.

Comment 1

[Isriya Paireepairit]

Attachment: Screenshot of Firefox 3

Screenshot of Firefox 3 URL Bar and autocomplete

Comment 2

[Isriya Paireepairit]

Attachment: Safari URL Bar (correctly display)

Screenshot of Safari URL Bar (display correctly) - The expected result

Comment 3

[Isriya Paireepairit]

Attachment: Screenshot of Safari Autocomplete

Safari Autocomplete (correctly display)

Comment 4

[Isriya Paireepairit]

Attachment: Screenshot of Firefox 3 - correctly display with alphabet

When typing vowels after alphabet, Firefox displays them properly

Comment 5

[Keng Susumpow]

Confirmed.

The visible glyph is randomly display, sometimes korean character, sometimes chinese character and sometime invisible.

Tested on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008030804 Minefield/3.0b5pre

Comment 6

[Theppitak Karoonboonyanan]

Attachment: Minefield screenshot on Linux

For the record, it works fine on Linux.

Comment 7

[Pittaya Sroilong]

Confirmed.

Tested on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008030804 Minefield/3.0b5pre

Comment 8

[Arthit Suriyawongkul]

confirmed.

Comment 9

[Arthit Suriyawongkul]

on related issue, should really Firefox accept that kind of input at the first place ?

in principle, Thai above vowel, below vowel, and tone mark character needs a base character to be "attached/combined" with.
it can't stand alone by itself. 

but in the case it happens to be (e.g. typo), it should be displayed as in the location bar shown in attachment 308277 [details] .

anyway, it is very very rare (if ever) to search url/word by using above/below vowel or tone mark
-- as to search anything, at least in Thai language, we typical typing word or PRONOUNCEABLE part of word (~syllable), and these are never start with those above/below vowel/tone mark characters.


So the questions are:

1) should we allow (auto-complete) searching starting with those characters happens ?

2) if we allow it, how it should be rendered ?
  Please look at url list in attachment 308277 [details], we can see that
  because Firefox like to _underline_ the word currently being search for,
  it will separated an above/below vowel/tone mark character in question
  from its 'partner', to make it underline-able. something like:
   โรงเรียน --> โรงเร_ียน
   ขอนแก่นเตรียม --> ขอนแก่นเตร_ียม
   does this a preferred thing ?
   or should underline property being applied in a character-cluster level only ?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Weird. Something to do with how the location bar splits up text for the highlighting, I guess.

Comment 11

[Isriya Paireepairit]

On 2008031304, the result was changed. Now the bad characters are gone. When typing above/below vowels as first character, it's simply not just shown up.

Comment 12

[Pittaya Sroilong]

(In reply to comment #11)
> On 2008031304, the result was changed. Now the bad characters are gone. When
> typing above/below vowels as first character, it's simply not just shown up.
> 

I'm on 2008031204 and those bad characters are gone.

Comment 13

[Arthit Suriyawongkul]

BugAThon Bangkok

We (7-8 native Thais) discussed about this and all agreed
that while searching substring is expected behavior,
searching substring starting with non-base Thai character is a non-expected behavior.


As a result, we should not allow user to type non-base Thai character at the start of string (e.g. search word, url) at the first place.
i.e. we should do character sequence checking in find and address bar

If we can strict that input, anomalies in Bug 157534 and Bug 421275 will no longer appear. So both will be closed.


New Bug 425900 open "Should not allow non-base Thai character as first character in textfield/textarea".