Thai above and below vowels display incorrectly in URL bar

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
11 years ago
11 years ago

People

(Reporter: markpeak, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 307686 [details]
Screenshot of Firefox 3

Screenshot of Firefox 3 URL Bar and autocomplete
(Reporter)

Comment 2

11 years ago
Created attachment 307688 [details]
Safari URL Bar (correctly display)

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

Comment 3

11 years ago
Created attachment 307689 [details]
Screenshot of Safari Autocomplete

Safari Autocomplete (correctly display)
(Reporter)

Comment 4

11 years ago
Created attachment 307690 [details]
Screenshot of Firefox 3 - correctly display with alphabet

When typing vowels after alphabet, Firefox displays them properly

Comment 5

11 years ago
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
Created attachment 308277 [details]
Minefield screenshot on Linux

For the record, it works fine on Linux.

Comment 7

11 years ago
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

11 years ago
confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

11 years ago
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 ?

Updated

11 years ago
Version: unspecified → Trunk

Updated

11 years ago
Blocks: 65896
Weird. Something to do with how the location bar splits up text for the highlighting, I guess.
(Reporter)

Comment 11

11 years ago
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

11 years ago
(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

11 years ago
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".
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.