Native Messaging Host (Chrome) failing on receiving messages properly when ported form Python 2 to Python 3

Hello there! Let's dive into a fascinating technical blog post about a challenge faced when porting the Native Messaging Host from Python 2 to Python 3. We'll uncover the root cause of the issue and explore the solution that brought everything back to working order.

Problem: Native Messaging Host Failing to Receive Messages Properly

As you embark on the journey from Python 2 to Python 3, you might encounter a peculiar issue where the Native Messaging Host struggles to receive messages correctly. Don't worry; you're not alone. Many developers have faced this hurdle, and together, we'll navigate through it.

The Culprit: Endianness and Data Types

After careful investigation, the culprit behind this perplexing problem was revealed to be a combination of endianness and data type complications introduced by the transition from Python 2 to Python 3. Let's break it down:

Endianness:

Endianness refers to the order in which bytes are stored in computer memory. There are two common formats: big-endian and little-endian.

In big-endian, the most significant byte (MSB) is stored first, followed by the least significant byte (LSB). Conversely, in little-endian, the LSB comes first, and the MSB follows.

The issue arose because Python 2 and Python 3 handle endianness differently, leading to discrepancies in how messages were interpreted.

Data Types:

Python 2 and Python 3 also differ in their handling of data types. In Python 2, integers are typically 32-bit, while in Python 3, they are 64-bit by default.

This difference in data size caused problems when reading the message length (stored as a 4-byte integer) from the web application. The Native Messaging Host couldn't correctly interpret the length, resulting in the improper handling of messages.

The Solution: Addressing Endianness and Data Types

To resolve this issue, we needed to address both endianness and data type discrepancies. Here's how we did it:

Endianness:

We used the `sys.byteorder` attribute to determine the endianness of the system. Based on that, we employed the appropriate byte order (big-endian or little-endian) when unpacking the message length.

Data Types:

To handle the difference in data types, we explicitly specified the byte order and size when converting the message length bytes to an integer.

This ensured that the message length was correctly interpreted, leading to the proper handling of messages.

The Full Working Code:

def read_thread_func():
  while True:
    # Read the message length (first 4 bytes).
    text_length_bytes = sys.stdin.buffer.read(4)

    if not text_length_bytes:
      sys.exit(0)

    # Unpack message length as 4 byte integer.
    if (sys.byteorder == 'big'):
      text_length = int.from_bytes(text_length_bytes, byteorder='big')
    else:
      text_length = int.from_bytes(text_length_bytes, byteorder='little')

    # Read the text (JSON object) of the message.
    text = sys.stdin.read(text_length)

    if (os.path.exists('./data')):
      with open('./data', 'w') as f:
        f.write(text)
        f.close()
    else:
      with open('./data', 'x') as f:
        f.write(text)
        f.close()

Conclusion:

By addressing both endianness and data type differences between Python 2 and Python 3, we were able to successfully port the Native Messaging Host and restore its ability to receive messages properly. This serves as a valuable lesson in understanding the nuances of language transitions and the importance of meticulous attention to detail.