300770 - DDE request WWW_GetWindowInfo does not return multibyte (Unicode) characters correctly

Status: RESOLVED DUPLICATE of bug 281781

(Firefox :: General, defect)

Description

[Edward Leigh]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5

The DDE request WWW_GetWindowInfo submitted with clipboard format 
CF_UNICODETEXT does not return a result in Unicode UCS-2. Nor does a request 
with clipboard format CF_TEXT return a result UTF-8 encoded. Instead what is 
returned is the lower byte of each UCS-2 character. Until ISimpleDOMDocument 
offers an alternative to DDE, there is currently no simple way to extract page 
titles that use multibyte character sets.


Unicode characters

Reproducible: Always

Steps to Reproduce:
::SendMessageTimeout(HWND_BROADCAST, WM_DDE_INITIATE, (WPARAM)GetSafeHwnd(), 
MAKELPARAM(GlobalAddAtom(_T("firefox")), GlobalAddAtom(_T
("WWW_GetWindowInfo"))), SMTO_NORMAL | SMTO_ABORTIFHUNG, DDE_INIT_TIMEOUT, 
&msgResult);

::PostMessage(ddeWindow, WM_DDE_REQUEST, (WPARAM)GetSafeHwnd(), MAKELPARAM
(CF_UNICODETEXT, GlobalAddAtom(_T("-1"))));

Actual Results:  
WM_DDE_DATA message returns page title and URL as a single-byte string, with 
multibyte characters converted to garbage.

Expected Results:  
If requested for CF_UNICODETEXT, result should be returned in UCS-2. If 
requested for CF_TEXT, the result should be multibyte-encoded, preferably UTF-
8.

Comment 1

[William Bumgarner [:zsinj]]

Related to bug 281781?

Comment 2

[Edward Leigh]

It does indeed look like this bug is the same as #281781 (which I overlooked 
when I searched for 'WWW_GetWindowInfo'). However that bug is marked 
as 'RESOLVED' yet it is not in the Deer Park Alpha 2 build (though the DDE 
response is different from 1.0x in that multibyte characters are replaced by 
an underscore).

Looking at the source code it appears that it hard-codes a response of CF_TEXT 
rather than examining the requested clipboard format and responding 
accordingly.

Comment 3

[William Bumgarner [:zsinj]]

That's because it was fixed in the "Trunk" (1.0+ releases), but not in the
branches (like this bug, 1.0.x).

Since this was a bug in trunk, and apparantly, is now a bug in the branch
builds, I am confirming this.

Comment 4

[William Bumgarner [:zsinj]]

*** This bug has been marked as a duplicate of 281781 ***