MFCEmbed - Find can't find text encoded in UTF-8.

RESOLVED EXPIRED

Status

()

Core
Embedding: APIs
RESOLVED EXPIRED
17 years ago
13 years ago

People

(Reporter: amutch, Assigned: Chak Nanga)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: pending, URL)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:0.9.8+) Gecko/20020225
BuildID: MFCEmbed Feb. 25, 2002 Build

The Find dialog in MFCEmbed fails to find text encoded in UTF-8 on a web page.

Reproducible: Always
Steps to Reproduce:
1. Choose one of the test cases from the directory URL provided
2. Use the Find dialog to complete the test cases listed on the pages
3. MFCEmbed fails to find text encoded in UTF-8 in web pages.

Expected Results:  MFCEmbed should find text encoded in UTF-8 in web pages.

This is very important for provided Find support for non-English speaking users
of embedded apps.  

I think this is the relevant chunk of code from: 

http://lxr.mozilla.org/seamonkey/source/embedding/tests/mfcembed/BrowserView.cpp#961

961 nsString searchString;
962 searchString.AssignWithConversion(dlg->GetFindString().GetBuffer(0));
963 finder->SetSearchString(searchString.get());

This is over my head but I'm guessing that the Find dialog is passing plain
ASCII text and needs to convert that to UTF before it does the search.

Comment 1

17 years ago
-> Chak
Assignee: adamlock → chak

Comment 2

16 years ago
amutch@tln.lib.mi.us, is this still a problem with a current build?
Whiteboard: pending
(Reporter)

Comment 3

16 years ago
Asa,

I believe so. We've been doing a little testing and it still is not working.
Here's a good test page:

http://www.columbia.edu/kermit/utf8.html

(Reporter)

Comment 4

16 years ago
Asa,

I believe so. We've been doing a little testing and it still is not working.
Here's a good test page:

http://www.columbia.edu/kermit/utf8.html
(Assignee)

Comment 5

16 years ago
Cc:ing Conrad for his comments...
(Reporter)

Comment 6

16 years ago
Chak:

This bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=181559

implemented a "fix" for this. However, the behavior is not consistent. On the 
test page I noted, it works for some characters and not others. I'm not sure 
if this bug is completely fixed. 
(Assignee)

Comment 7

16 years ago
Cc:ing Roy for his comments...thanks

Comment 8

16 years ago
As per 181559, we no longer use 
962 searchString.AssignWithConversion(dlg->GetFindString().GetBuffer(0));
Instead, we call T2W(..) to convert to Wide char.
http://lxr.mozilla.org/seamonkey/source/embedding/tests/mfcembed/BrowserView.cpp#953

amutch: Would you specify which chars doesn't work?
teruko: Could you verify with the trunk mozilla build 
        and with the mfcembed to see if
        there are any differences?
(Reporter)

Comment 9

16 years ago
Roy,

Doing a quick check against this test page:

http://www.columbia.edu/kermit/utf8.html

I started by trying to Find characters in the Poetry section on text marked as 
Greek and Russian. Also, I searched in the "I Can Eat Glass" section for text 
labeled as Greek, Russian, Urdu, Hebrew and Thai. None of these could be found 
by the Find function. I copied and pasted the characters from the page into the 
Find dialog to ensure an accurate search. I also double-checked by copying and 
pasting from IE 6, which did find all of the characters, just to make sure that 
nothing was getting messed up in the process of copying and pasting. 

I also saw that if you search on those characters and then close and reopen the 
Find dialog, the characters which pasted properly are converted into question 
marks and other characters. 

One other strange behavior I saw was where I searched on a character and the 
Find function matched it to any occurrence of a "question mark". When you 
closed and reopened the Find dialog, the character had been converted to a 
question mark. 
(Reporter)

Comment 10

16 years ago
Roy,

I ran the same tests in Mozilla 1.3 beta and it was able to find all of the text
and characters that MFCEmbed failed to find.

Comment 11

16 years ago
amutch: thank for your quick reply. :)
Your test led me to believe that it is due to the fact
that discrepancies between Mozilla 1.3 and MfcEmbed were
caused by OS support on none-Unicode application.

As you may or may not know, Mozilla is now a true Unicode
application (with use of RegisterClassW(), DefWndProcW(), etc)
Thus all the keyboard inputs, Cuts/Pastes will contain Unicode
code points _from the Operating System_.
eg.  Windows sends unicode code points to WM_CHAR message.

On the other hand, none-Unicode application (MFCEmbed, for example)
receives WM_CHAR msg with ACP code points.  _Windows_ doesn't
send Unicode code points to none-unicode application
despite the fact that the user can enter/cut/paste those text.
It, in fact, sends '?' to OnChar() message. :-(

Chak: do we have a plan to make MFCEmbed an Unicode app?
      (ie. adding -DUNICODE compiler flag)

Teruko: can you verify if we can Find none-ACP text using the old MFCEmbed?
        Use the one with mozilla 1.0 milestone?
(Reporter)

Comment 12

16 years ago
Roy,

"Teruko: can you verify if we can Find none-ACP text using the old MFCEmbed?
        Use the one with mozilla 1.0 milestone?"

If you are referencing the old code, I'm going to guess that the answer is no. 
We still have the old code in K-Meleon (we missed your fix in the other bug) 
and it has the same or similar problems. 

Comment 13

16 years ago
amutch: 
Thanks.  I wanted to know if my change 181559 caused this regression.

I chat with Chak just few minutes ago and he would look into adding
the UNICODE flag to MFCEmbed.
Here is MSDN link for Unicode conversion
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_unicode_programming_summary.asp

(Reporter)

Comment 14

16 years ago
Roy,

Would making MFCEmbed a Unicode application address this bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=92601

Comment 15

16 years ago
>Would making MFCEmbed a Unicode application address this bug.
It's hard to tell w/o looking at the source code; but
if MFCEmbed is using MessageBox() for alert/comfirm then
the Unicode enabling would fix the problem provided that
MFCEmbed sends the correct Unicode alert/comfirm string
to MessageBox().

I see Netscape 7 (non-Unicode app) displays the alert/comfirm fine.
I believe it's using the XUL window for display the dlgbox (?)
(Reporter)

Comment 16

16 years ago
"I see Netscape 7 (non-Unicode app) displays the alert/comfirm fine.
I believe it's using the XUL window for display the dlgbox (?)"

Yes, as far as I know, Netscape is using XUL for those dialogs.
(Reporter)

Updated

16 years ago
Depends on: 154426

Comment 17

14 years ago
amutch, is this still a problem? 

Comment 18

14 years ago
Hello

I have one short question to all partitants, who can reproduce the error or not.
Do the following: 

a) Select a string (utf-8) 
b) Copy to the clipboard 
c) Call the Find-Command or go to the open Find-Window
d) Place the string and click on "find". 

If this searched string is the only one in the selection an below. The Message
appers that the string could not be found. And now do the following: 

a) Select a string (utf-8) 
b) Copy to the clipboard
c) Select a string before the selected string 
d) Call the Find-Command or go to the open Find-Window
e) Place the string and click on "find". 

Is it possible that this is the error?

Best Regards
Wolfgang Uhr
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.