Open Bug 1440470 Opened 7 years ago Updated 3 months ago

Setting the window title with FSI/PDI characters results in unprintable characters being displayed

Categories

(Core :: Widget: Win32, enhancement)

enhancement

Tracking

()

People

(Reporter: zbraniecki, Unassigned)

Details

nsWindow::SetTitle [0] is the code we use to set the window title. Recently, we enabled new localization API in Firefox UI which uses Unicode Control Characters FSI and PDI to inform the layout engine about directionality isolation of the text in cases where an embedded fragment may have different directionality than surrounding part. To translate that to human - when you localize a phrase "You and Anna are friends" we will use a placeable for the brand name. So the real localization pattern will look like this: "You and { $userName } are friends". The full sentence will be localized into many languages, some left-to-right, others right-to-left. But the name of the user may also be LTR or RTL and may be opposite of what the surrounding sentence direction is. Unicode came up with FSI and PDI characters to inform layout about it, and we use it in Firefox now. So we'd build a sentence like this: "You and [FSI]Anna[PDI] are friends". Unfortunately, when we turned it on we got reports from Windows users about the FSI/PDI characters being displayed in windows titles (see screenshots): - https://bugzilla.mozilla.org/show_bug.cgi?id=1439018 - https://bugzilla.mozilla.org/show_bug.cgi?id=1439434 - https://bugzilla.mozilla.org/show_bug.cgi?id=1439389 In result we had to disable the feature for now. It can be re-enabled by setting "intl.l10n.enable-bidi-marks" to true. We also contacted Microsoft about it and they responded with: ``` Win32 USER is old and not where current investment is happening. XAML/WPF/Xamarin may be alternatives, though I don’t know if they would meet your requirements. But whichever platform API you use, I don’t know what the status of support for the bidi isolate control characters would be. For DirectWrite (our current-generation text-layout platform, part of the DirectX platform), we have had in our backlog for a while to support these in our bidi implementation, but so far we haven’t had any customer request for that, and so it has remained a low priority. ``` The main request then here is to strip FSI/PDI characters when setting the title to avoid exposing those characters to Windows until they fix it on their side. [0] https://searchfox.org/mozilla-central/rev/9a8d3f8191b15cdca89a7ce044c7bea2dd0462dc/widget/windows/nsWindow.cpp#3642
Jonathan - does the approach of stripping FSI/PDI here seem reasonable to you? Can you advice on what C++ API to use to strip them from a nsString?
Flags: needinfo?(jfkthame)
You should be able to do that with nsString::StripChars, I think. FSI/PDI are newer additions to Unicode (added in version 6.3). Does Windows recognize and handle the older directional controls such as LRE/RLE/PDF? If so, an option might be to examine the embedded fragment to see what direction FSI would resolve to, and then replace the FSI/PDI pair with LRE/PDF or RLE/PDF accordingly. The resulting behavior isn't quite identical, IIRC, but would work as desired in most common cases, I think; at least, it ought to handle mixed direction cases better than just stripping the controls altogether.
Flags: needinfo?(jfkthame)
> Does Windows recognize and handle the older directional controls such as LRE/RLE/PDF? I'm not sure but we raised the issue with our Microsoft partners and they're planning to fix the FSI/PDI. I think that since the scope is small (window titles) and limited to Windows only, it's ok to just strip those chars temporarily until Windows fixes it.
Flags: needinfo?(gandalf)
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(zibi)
You need to log in before you can comment on or make changes to this bug.