Copy paste result contains hidden character

[Cerlancism]

Describe the bug

Copy paste result contains hidden tailing character U+202C which can cause syntax errors to programming languages or breaks in Excel.

Steps To Reproduce
Steps to reproduce the behavior:

1. Key in an integer.
2. Double click the number to select it.
3. CTRL+C.
4. CTRL+V else where, such as a code editor.

Expected behavior
A clean set of digits entered as valid syntax and works in Excel as a number.

Screenshots

Device and Application Information

• OS Build: 10.0.17134.0
• Architecture: X64
• Application Version: 10.1903.21.0
• Region: en-SG
• Dev Version Installed: False

Additional context

[grochocki]

Thanks for the detailed report! Unfortunately, I am not able to reproduce the issue (when I paste in values to Excel or Visual Studio, they recognize the values as valid). However, I do believe this is the same as the issue reported in #115 and is related to bi-directional text formatting.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[ZhaoMJ]

Even though I cannot reproduce it consistantly, I do believe I encountered this problem before. Oddly enough that it works fine most of the time, but I remember at least 3 times when I tried to copy/paste bits from Programmer mode, it gave me invalid values.

[darklightcode]

@grochocki @ZhaoMJ to reproduce this error, just copy the text using the mouse by holding and dragging from the left to the right (an uncontrolled right to make sure you just got the whole thing) then press Ctrl+C , and Paste it in an editor with IntelliSense. I have tried it in VSCode and IntelliJIdea. Just encountered it, and ended up here.

A more detailed view of the problem using some CSS (with Webpack):

• It seems the editor(IntelliJidea) recognize the invalid character
• The compiler recognized it too. As in my image, i'm using the percent % character afterwards
• I tried using the same on line-height , a property that accepts real numbers. The compiler didn't complain but it made the percent character change it's color to yellow ( whatever that means ) but the hidden space is now between the % and ; .
• The second line-height contains just the number, and the hidden space. I don't get an error here, perhaps the space gets trimmed by sass-loader.
• sass-loader throws on the width property with : width: 2‬ %; // Error when using Percent, as you can see in the image, there is a space between width and the percent sign.
  

Operating System: Microsoft Windows [Version 10.0.18362.175]
Calculator Version: 10.1904.31.0

PS: Excuse my advanced math skills.

[Daijobou]

I have this bug too and can reproduce it every time. This bug is new, not long ago this bug not exists.

One of previous versions I can click on calculator and "copy" the result. Now I must first click on "select all" and then "copy". Why so unnecessarily complicated to copy for a result? After copy I insert it in current microsoft vscode as PHP-Code and get in Browser

Use of undefined constant ‭86400‬ - assumed '‭86400‬' (this will throw an Error in a future version of PHP)

When I get this error with e-mail its look like

Use of undefined constant ‭86400‬ - assumed '‭86400‬' (this will throw an Error in a future version of PHP)

calculation was 3600 * 24

Operating System: Microsoft Windows [Version 10.0.18362.175]
Calculator Version: 10.1904.31.0

[Gwunhar]

I'm on Windows 10 17763.557 with Calculator 10.1904.42.0 and can reliably reproduce this bug this way:

Make some calculation in Calculator
Click into the result pane and CTRL+A or Right Click -> Select All
Copy
Paste and you'll have the leading and trailing character.

Hope that helps.

Also, just for chuckles...one of our PMs found this by pasting values back into Visual FoxPro from Calculator, and they rendered as ?s, which made them ask me what they were doing wrong.

[grochocki]

@joshkoon or @joseartrivera Can one of you confirm whether this is a result of the left-to-right mark for BiDi support?

[joshkoon]

Yes, it's the result of the LtR marks.

[grochocki]

Theoretically, could we only inject the LtR marks if we detect you are operating in an RtL language? Or would that possibly cause complications?

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment. Thank you for your contributions to Windows Calculator!

[grochocki]

Talked with @joshkoon offline and we think we can be smarter about when we include the extra hidden characters. Assigning to @joseartrivera to either fix this or, if we cannot remove the characters, close out bug as by design.

[phuclv90]

There's not only a trailing U+202C but also a heading U+202D

The behavior is also observed when right clicking on the hex/dec/oct/bin numbers in the programmer mode > copy and then paste

To work around that right click outside the textbox and select copy. That way only the number is copied

This was reported last year in How to stop Windows 10 Calculator from enclosing copied text in 202D and 202C Unicode characters?

[0ffffffffh]

This bug exists because the hex/dec/oct/bin value copy has it's own copy method. And that method copies whole content on it. Including left to right mark etc. For example, each value format control made by the RadixButton which is derived from a RadioButton. For example hex section.

Hex control binding property value named "HexDisplayValue". It binded to a radixbutton.

And it's copy command routine looked like this

When you click one of the hex/dec/oct/bin section's copy command, that routine invoked. It gets the target control and casts to the radixbutton. It gets whole content on it and copies to the clipboard. But HexDisplayValue property surrounded with left-to-right and pop directional flag mark bytes. And you are always injecting these values as far I see.

calculator/src/CalcViewModel/StandardCalculatorViewModel.cpp

Line 1604 in 00346cc

HexDisplayValue = Utils::LRO + ref new Platform::String(hexDisplayString.c_str()) + Utils::PDF;

these marks defined as

[grochocki]

Yes, we need to inject to ensure they are displayed properly around the world, but ideally, they are not included on copy. Are you suggesting this is a result of how we handle copy?

/cc @joseartrivera

[0ffffffffh]

yes I do. you are doing that because you want the values to be displayed correctly on the right to left scripting languages such as arabic or hebrew right? but my localization setting was not set for one of them. so I don't need the left to right override mark on the clipboard. everytime I paste the value from the calculator to a coding editor which is working on ASCII charset such as Visual studio, it could not recognize/parse the numerical value.

you can try to copy the value to the clipboard without these marks at least?

[grochocki]

you are doing that because you want the values to be displayed correctly on the right to left scripting languages such as arabic or hebrew right?

Yep, exactly. They need to be retained for display, but I agree that we should remove those marks on copy. I know this is currently assigned to @joseartrivera, but if you are you interested in making a change to address this, I imagine he would be open to that.

[0ffffffffh]

I don't know the design approaches you're considering when you solving/fixing a bug or implementing a feature but i want to share my thoughts for this issue.

First, I'm curious about why you were injecting the direction marks without checking the RTL status of the system's active language? I have seen that you had done such a thing before. For example

calculator/src/CalcViewModel/StandardCalculatorViewModel.cpp

Lines 137 to 151 in 00346cc

	String ^ StandardCalculatorViewModel::LocalizeDisplayValue(_In_ wstring const& displayValue, _In_ bool isError)
	{
	wstring result(displayValue);
	LocalizationSettings::GetInstance().LocalizeDisplayValue(&result);
	// WINBLUE: 440747 - In BiDi languages, error messages need to be wrapped in LRE/PDF
	if (isError && m_isRtlLanguage)
	{
	result.insert(result.begin(), Utils::LRE);
	result.push_back(Utils::PDF);
	}
	return ref new Platform::String(result.c_str());
	}

Is there an obstacle not to do the same approach for injecting these direction characters on displaying numerical values?

Let's assume you have to inject direction characters in any case.

This time we have to focus the clipboard copy method to bring a generic solution.

So it could be handled in the CopyPasteManager::CopyToClipboard method. We could check the RTL status from the current culture information first in beginning of the CopyToClipboard routine before we send the text data to the clipboard.

if the currently working localization is one of the rtl based language the text data would sending as is (with direction marks) otherwise we could trim these directional marks from the string and passing it to the clipboard. With this approach any text data could be filtered.

As I said i can't be sure your design expectations on this but it just my thoughts.

Thanks.

[grochocki]

Is there an obstacle not to do the same approach for injecting these direction characters on displaying numerical values?

I chatted with someone who had more context on what we are doing here, and they could not think of a reason we should not do what you are suggesting here and conditionally add the characters in RTL only.

That reduces the number of impacted users, but still does not get around copying in RTL, so we would still need to do something in CopyToClipboard.

[DaEkstrim]

I can't even begin to narrate the saga we went through due to the value that was copied from the calculator into an SQL script on MSSQL having hidden (!??) characters which obviously didn't show up in the script window and caused issues with the code consuming the value.

Why? Just... why?

[Salgat]

This created an issue for us also. Seems incredibly reckless to be inserting hidden characters in a result that you absolutely know people will be using.

[weidox]

Just encountered this when tried to paste calculator value into online banking and their system went nuts. What was happening was insane and annoying - well more of a problem on banking site, but they did not expect such malformed input.

[wschlossberg]

This is similarly driving me nuts with simple copies and pastes into DOS windows based on excel formulas (not from macros). I use Excel as a sort of dashboard for executing frequently changing CMD commands, to manage my environment, and to execute long robocopy commands and scripts.
(Microsoft 365 16.0.12624.20424 64 bit )

Please fix it ASAP Thanks

[kaleidocore]

Yeah, wow what a sneaky bomb. It completely broke our system and was a PAIN to find in our source code. Both Visual Studio and web browsers happily accepts these hidden chars, leaving us a "happy little surprise" much further down the line, during runtime.
The frustrating ability of this issue to hide and spread through multiple systems should put it right at the borderline of "virus"!