Browser Requirements

The Document Editor and the Document Viewer run in the browser, so both your users' browsers and the connection to your server matter. Check the documented browsers for the Document Editor and what the connection needs for both components if your application shows documents in the browser, and before you deploy behind a firewall, proxy or load balancer.

Server-side document processing with ServerTextControl and MailMerge has no browser requirements.

Supported Browsers

The requirements documentation lists the following browsers for the Document Editor:

• Microsoft Edge
• Mozilla Firefox 31 or higher
• Google Chrome 36 or higher
• Apple Safari 5 or higher

These minimum versions are old, and every current version of these browsers meets them. The documentation does not list newer minimum versions or tested versions. The README of the Angular Document Editor package describes the editor as working in any HTML5-based browser, including Google Chrome, Firefox, Safari and Microsoft Edge. The requirements documentation has no separate browser list for the Document Viewer.

How the Browser Connects to Your Server

Both components run in the browser, but neither works on its own. They connect to a backend that runs TX Text Control .NET Server, in different ways. The table describes an ASP.NET Core backend; the Node.js version of the Document Editor connects to a Node.js WebSocketServer instead, as Document Editor describes.

Document Editor: WebSocket Connections

The Document Editor synchronizes every change with the server. The editor in the browser opens a WebSocket connection to your ASP.NET Core application, which enables WebSockets with app.UseWebSockets() and adds the TX Text Control middleware with app.UseTXWebSocketMiddleware(). The middleware connects over TCP to the Document Editor backend TXTextControl.Web.Server.Core, by default on port 4283.

For the editor to work, the following must be true:

• The browser can open WebSocket connections. The WebSocket URL starts with ws:// for pages served over HTTP and with wss:// for pages served over HTTPS.
• Firewalls allow WebSockets. If the network security policy blocks WebSockets, the Document Editor cannot be used. Some older firewalls inspect traffic on port 80 and block WebSockets. In this case, using HTTPS (port 443) solves the problem.
• Load balancers keep the session on one node. A Document Editor session is tied to one backend instance, because the backend holds the live document state. Configure session affinity (sticky sessions) so that the WebSocket connection stays connected to the same node.
• The hosting platform has WebSockets enabled. On Azure App Services for Windows, enable WebSockets (and 64-bit) in the settings of the App Service before you publish. See Azure.
• The backend endpoint is reachable from the middleware. If the Document Editor backend runs on a different machine, open its port in the firewall and configure the WebSocket middleware with the same address and port. Text Control recommends configuring the endpoint explicitly in containerized or load-balanced environments and with multiple backend instances.

Authentication tokens in the query string of the WebSocket URL can appear in web server and reverse proxy logs; the Document Editor can send them in the Sec-WebSocket-Protocol header of the handshake instead, as Keep Tokens Out of Logs describes.

For Classic ASP.NET applications on the .NET Framework, the requirements for the Document Editor list IIS 8.0 or higher and an installed WebSocket protocol.

Document Viewer: HTTP Requests

The Document Viewer does not use a WebSocket connection. Its JavaScript calls the HTTP methods of the TextControl controller in your backend, which loads the document, renders its pages and sends them to the browser. Since version 32.0 SP3, the viewer can load a document with long polling: the server streams the pages as it generates them, and users can start reading before all pages are loaded.

A network that allows normal HTTP or HTTPS requests to your application is sufficient. If your frontend is a separate Angular, React or JavaScript application, its basePath setting points to the backend URL, and the backend must allow cross-origin requests (CORS).

Related Pages

• Troubleshooting WebSockets — what to check when the Document Editor cannot connect.
• Document Editor — how the editor frontend, middleware and backend work together.
• Document Viewer — how the viewer loads documents from its backend.
• Scaling TX Text Control Document Editor Applications — load balancing and sticky sessions.