Browser and device compatibility based on actual tests

This delivery’s automated pass ran Chromium 150.0.7871.124 on Debian GNU/Linux 12. Two independent browser profiles opened a local production-style Worker. One profile created a Pase, the other joined with its code, both opened the DataChannel and a unique text was sent. A test file was then uploaded and the second profile reconstructed its name and content.

Public pages were also reviewed at 1280×800 and in a 390×844 viewport. The smaller case proves responsive layout and controls at mobile dimensions inside Chromium; it does not turn the computer into a physical phone or test camera hardware, operating-system suspension, cellular networking or a WebView. We keep that distinction instead of calling emulation a device test.

The flow depends on WebSocket, RTCPeerConnection, RTCDataChannel, Blob, object URLs, TextEncoder and common file APIs. A QR can be displayed without a camera; scanning within the interface needs compatible camera access and permission from the user. Copy and system sharing may also depend on permissions, secure context and operating-system support.

A page loading correctly does not prove that WebRTC will negotiate on that network. Compatibility is a combination of engine, version, policies, device and connectivity. Privacy extensions, managed browsers and embedded in-app browsers can change capabilities even when their engine resembles a better-known browser.

No real test was run in Safari, Firefox, the official Edge distribution, iPhone, iPad, physical Android, Windows or macOS. Embedded social-media browsers, e-readers and televisions were not tested either. It is reasonable to expect WebRTC in many modern browsers, but that expectation is not presented here as a confirmed Mándamele result.

Cross-engine combinations such as mobile Safari to desktop Firefox were not executed, and neither was QR camera capture on hardware. If an organisation depends on one exact combination, it should complete a non-sensitive text and file trial before adopting the flow. A list of browser brands without version, network and use case creates false confidence.

Update both browsers, open mandamele.com directly and avoid embedded WebViews. Create a fresh Pase, connect the second browser and send an identifiable sentence. Then use a small text file, check its name, download it and compare the contents. Finally test a representative file within the 50 MB limit while keeping both devices awake.

Repeat on the network that will actually be used. Two profiles on one machine validate application behaviour and local transport but do not reproduce corporate NAT, a VPN or a mobile carrier. If the use case requires those networks, include them explicitly in the acceptance matrix. Record exact version and date because browser behaviour can change with updates.

Visual compatibility means the menu, picker, code field and conversation remain usable without clipping. Connection compatibility means WebSocket and WebRTC operate. File compatibility adds memory, selection, Blob creation and download. A browser can pass one layer and fail another, so a useful result says which part was exercised.

On mobile dimensions, the application keeps a file picker visible; desktop adds drag and drop. Both paths call the same sending logic. QR camera access is optional because a code can always be typed. Likewise, preview support is not required for receipt: a format may be downloaded even when the browser cannot display it.

This guide should be updated when new reproducible tests exist. A positive result confirms the recorded version and scenario, not every future version. A failure on a restrictive network also does not prove that the browser engine is incompatible; it may reflect the lack of TURN or a local policy.

When reporting a problem, include full browser name, version, system, device, network type and failing stage. Do not share transferred content. That evidence helps distinguish an interface, signalling, negotiation or file-handling defect and expands the matrix without inventing coverage. Repeatable notes also let a later release confirm whether a browser update fixed or introduced the behaviour in the same test scenario.