Bug 120125

Summary: [Windows] Correct Tooltip Text on Windows
Product: WebKit Reporter: Brent Fulgham <bfulgham>
Component: WebKit Misc.Assignee: Brent Fulgham <bfulgham>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Attachments:
Description Flags
Patch andersca: review+

Description Brent Fulgham 2013-08-21 11:33:08 PDT
Several Windows API calls that involve building temporary structs to hold arguments needed to be corrected after a (relatively) recent change to WTF::String.  The change optimized String memory use by generating UChar string data on-the-fly from internal 8-bit representation (rather than holding an 8-bit and UChar version of the string).

Unfortunately, the idiom of grabbing a pointer to that data and assigning it to a structure element, such as:

        info.lpszText = const_cast<UChar*>(m_toolTip.charactersWithNullTermination().data());
        ::SendMessage(m_toolTipHwnd, TTM_UPDATETIPTEXT, 0, reinterpret_cast<LPARAM>(&info));

... causes dwTypeData to be set to the address of temporary storage that may be cleaned up after this line is executed. This is visible to the user as garbled (or missing) tooltip text.

The fix is to hold onto the UChar data long enough for the struct to be passed to the Windows API, after which point it can be cleaned up.

        const Vector<UChar>& toolTipCharacters = m_toolTip.charactersWithNullTermination(); // Retain buffer long enough to make the SendMessage call
        info.lpszText = const_cast<UChar*>(toolTipCharacters.data());
        ::SendMessage(m_toolTipHwnd, TTM_UPDATETIPTEXT, 0, reinterpret_cast<LPARAM>(&info));

This patch corrects this improper access pattern, as well as one or two other places I found searching for similar problems.
Comment 1 Radar WebKit Bug Importer 2013-08-21 11:34:10 PDT
<rdar://problem/14798128>
Comment 2 Brent Fulgham 2013-08-21 11:36:07 PDT
Created attachment 209289 [details]
Patch
Comment 3 Anders Carlsson 2013-08-21 15:12:13 PDT
Comment on attachment 209289 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=209289&action=review

> Source/WebKit/win/WebView.cpp:2814
> +        const Vector<UChar>& toolTipCharacters = m_toolTip.charactersWithNullTermination(); // Retain buffer long enough to make the SendMessage call

No need to make this a const reference, can just be a straight up Vector.

> Source/WebKit/win/WebCoreSupport/WebChromeClient.cpp:680
> +    const Vector<UChar>& dialogTitleCharacters = dialogTitle.charactersWithNullTermination(); // Retain buffer long enough to make the GetOpenFileName call

Ditto.
Comment 4 Brent Fulgham 2013-08-21 15:15:03 PDT
(In reply to comment #3)
> (From update of attachment 209289 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=209289&action=review
> 
> > Source/WebKit/win/WebView.cpp:2814
> > +        const Vector<UChar>& toolTipCharacters = m_toolTip.charactersWithNullTermination(); // Retain buffer long enough to make the SendMessage call
> 
> No need to make this a const reference, can just be a straight up Vector.
> 
> > Source/WebKit/win/WebCoreSupport/WebChromeClient.cpp:680
> > +    const Vector<UChar>& dialogTitleCharacters = dialogTitle.charactersWithNullTermination(); // Retain buffer long enough to make the GetOpenFileName call
> 
> Ditto.

Is this because return-value optimization will avoid a copy?
Comment 5 Brent Fulgham 2013-08-21 15:17:16 PDT
Committed r154421: <http://trac.webkit.org/changeset/154421>