Visiting the browser again

Note: This is a description of me failing to render a “Hello world” app. If you’re not interested in the process I went through please head directly to “This is finally the one I get the hello world to show in UW browser”

In this post I’ll try to make the UW browser to present the Hello world application described “What happened in the simulation”. My guess is that the Hello World application should be a part of the browser which would render the component by executing Javascript code returned by the serverApp.

Lets inspect the browser folder of the repo. Please bear with me as I’m not very up to date nor very interested in frontend development. I love and use Vue.js and Bootstrap when I need them, but other than that I’m not really up to date with React, Angular or other frontend libraries. They come and go so fast…

Rendering resources

It seems that the browser relies heavily on UIKit for rendering. The network/browser/resources/html/template/browser.html is where the application UI gets rendered with webview component being the main area for displaying websites. After a quick inspection of main.js I’ve found that webview is a tag supported by Electron. It all makes sense that it can be used to render classic websites but how do I display the Hello World application?

As you can see in browser/view/index.js line 43 setting new URL triggers a change of url variable on mainComponent . This is where I need to look for hints. With the mainComponent being an instance of reactive and browser/resources/js/ractive.js being minimized it makes it a bit more tricky. Luckily Reactive.js is and external library which seems well documented.

But for now I think this direction is not really the way I should go. Instead I should inspect how “uw://” prefix get’s handled and how could I reach my local server.

The uw://

Support of uw protocol is provided by browser/protocol/index.js line 90. The loadURL function is the place I should look into. I’ve added console.log(‘loadURL’, arguments) above line 29 of browser/protocol/index.js to see if it gets called. And it does but in the terminal window used to launch Electron app and not the frontend. Guess I’ve missed the frontend/backend part of the application execution. Makes sense though that custom networking being handled via some IPC mechanism, eg. ipcMain, though this is not the case here. Guess it’s a topic for another post on how the browser is structured and what exactly happens when you type in the address.

The newly added log presented these values:

loadURL [Arguments] {
  '0': '127.0.0.1',
  '1': '',
  '2': {
    method: 'GET',
    url: 'uw://127.0.0.1/',
    referrer: '',
    headers: {
      Accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9'
    }
  },
  '3': [Function: bound ]
}

So something is missing here, where’s my 8888 port which should point to my serverApp? It starts to make sense that it’s not working. I don’t have anything running locally on port 80 so will change that by modifying the serverApp/index.js line 18 to expose the server on port 80.

But wait, obviously when i use port < 1024 I’d need to run the server with root permissions. I don’t want that, instead will try to force the request to use port 8888. This is a bit of a hack but right now I’m focused exclusively on making the serverApp serve the hello world application.

So going back to scripts/simulate.js line 11 shows me what I should do specify servicePort: 8888 for the declaring the connection in browser/protocol/index.js line 57 so it ends up looking like this:

const freshConnection = await uws({
    service,
    profile,
    servicePort: 8888
});

Now back to the browser I type in just uw://127.0.0.1 - because the port no longer matters as it’s hardcoded to 8888. I press enter and get a reaction from the server!

Hello serverApp

Unfortunately it fails, the browser thinks that client: ERROR => No packet size number -> Invalid Packet and the browser page stays empty.

I guess it’s related somehow to the encryption and certificates which make the browser not understand the server’s response.

̶M̶a̶y̶b̶e̶ ̶I̶’̶l̶l̶ ̶b̶e̶ ̶m̶o̶r̶e̶ ̶l̶u̶c̶k̶y̶ ̶n̶e̶x̶t̶ ̶t̶i̶m̶e̶.̶

Followup, more detailed look into the browser-server exchange is in “Visiting the browser yet again”.