[Bug]: ByteArraySettingViewer stops synchronizing Base64/Hex values after the first conversion and may cause a null content exception

[HyperCrack1]

This issue respects the following points:

• This is a bug, not a question or a configuration issue; Please visit our forum first to troubleshoot with volunteers, before creating a report. The links can be found here.
• This issue is not already reported on GitHub (I've searched it).
• I'm using an up to date version of OpenBullet2. We generally do not support previous older versions. If possible, please update to the latest version before opening an issue.
• I agree to follow OpenBullet's Code of Conduct.
• This report addresses only a single issue; If you encounter multiple issues, kindly create separate reports for each one.

Description of the bug

I found what appears to be a bug in the ByteArraySettingViewer used for ByteArraySetting (for example, the RAW HTTP Request body editor).

The initial conversion between Base64 and Hex works correctly, but after switching modes or editing the values multiple times, the synchronization becomes inconsistent.

Eventually the HTTP Request block may fail with:

ArgumentNullException: Value cannot be null. (Parameter 'content')

even though the content textbox is not empty.

Reproduction steps

Create a new HTTP Request block.
Select RAW request.
Keep Base64 mode selected.
Enter a valid Base64 value.
It is converted correctly.
Switch to Hex mode.
The value is converted correctly.
Edit the value again (or switch between Base64 and Hex multiple times).
Enter an invalid Base64 string such as:
dsa

or continue editing after several mode switches.

What is the current bug behavior?

Actual behavior

After several edits or mode switches:

Automatic Base64 ⇄ Hex conversion stops working.
The editor appears to contain data, but the underlying byte array becomes invalid or null.
Executing the HTTP Request may throw:
ArgumentNullException: Value cannot be null. (Parameter 'content')

What is the expected correct behavior?

Base64 and Hex views should always stay synchronized.
Every edit should update the opposite representation.
Invalid input should be reported to the user without corrupting the stored byte array.
The HTTP Request block should never receive a null content value while the editor contains text.
Actual behavior

After several edits or mode switches:

Automatic Base64 ⇄ Hex conversion stops working.
The editor appears to contain data, but the underlying byte array becomes invalid or null.
Executing the HTTP Request may throw:
ArgumentNullException: Value cannot be null. (Parameter 'content')

Creating a completely new HTTP Request block temporarily restores the correct behavior until the issue happens again.

Possible cause

ByteArraySettingViewerViewModel silently ignores conversion errors:

try
{
...
}
catch
{
}

Both the Base64 and Hex setters swallow every exception without restoring a valid state or notifying the UI.

As a result, FixedSetting.Value can become invalid while the editor still displays text, eventually leading to a null byte array being used by the HTTP request handler.

It may also be worth checking whether the Base64/Hex property synchronization is always triggered after repeated edits and mode switches.

Version of the client

2.0

Type of client

Web client

Environment

- OS:
- Virtualization:
- Browser:

OpenBullet2 logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Relevant LoliCode if needed

Additional information

No response