BrowserBox VS puppeteer

Is that right? Could be a recent acquire if it's DOM mirroring.

I heard CF acquired S2 a few years ago, and what S2 did is they created a WebAssembly binary that composited the browser SKIA draw instructions on the client, and streamed the SKIA draw instructions from the server. Not without its issues, but certainly useful.

What we do is just stream pixels to the client. Yes it's expensive in terms of bandwidth, relatively. But the advantage is simplicity. And with a close server and bandwidth trending faster and cheaper, with the increasing drive to video consumption across media, I don't see bandwidth as an issue.

If you're interested, our code is on GitHub: https://github.com/BrowserBox/BrowserBox

Click through for a version on a server close to you that you can play with now.

Source code here: https://github.com/BrowserBox/BrowserBox

This demo is probably not really ready for a widespread audience, but luck it I’m just posting it anyway

> Edit: parent commenter seems to be promoting their product. Looks like a random remote browser, perhaps avoid entering important credentials there.

True. Maybe I should have put a full disclosure? I thought it was obvious, but I get if it wasn't. I'm sorry for not being more clear!

It's a good point to advise people to avoid entering important credentials in something that probably looks untrusted. I'd also advise that at this stage as we have no SLAs for now, and are just testing this SaaS-to-be demo of this source-available product:

https://github.com/BrowserBox/BrowserBox

Thank you for pointing out the reasonable and important security concerns. Although I should have probably done that myself, I was just so eager to help!

Aside: I am surprised tho that you were unable to even login on your VPN. I would think that the IP blocks we run the browser form and those of a VPN would be in the same category of 'cloud IPs', so why should it work on CloudTabs but fail for you directly on a VPN? Who knows?

These are difficult problems and perhaps the modern web has developed at a pace that older tech like RDP has not kept pace with. But Guacamole bucks that trend. The video shows how far it has come.

Guacamole is good, and I love that it's clientles and works in the browsers, but VNC lacks sound so you need to do that separately. Also the input lag when remote frames increase in frequency is challenging.

If you're looking for something lighter weight and possibly smoother and faster (albeit non-free software with a non-commercial option), check out BrowserBox: https://github.com/BrowserBox/BrowserBox

Solving input lag, and maintaining responsiveness across a range of bandwidth situations has been one of our priorities and I think we've mostly achieved.

We've accomplished this through a combination of sensible heuristics for congestion control, and using WebRTC with a fallback to WebSockets when faster. We also have audio out of the box, no set up required!

However there's always room to improve, which is why it makes it so exciting to work on. Depending on how close you are to a server you may encounter lag issues, too. Check out a free live demo of it working here (sorry, signup is not supported yet!):

https://browse.cloudtabs.net/signupless_session

Some other problems we solve that are not always so easy to configure with Guacamole (and are harder to do with an RDP layer in general), but much easier for us as we virtualize the browser itself are first class mobile support.

Obviously that's an issue with remoting desktops from small form devices in general, but if a browser is all you need remotely then we got your back! :)

Same time, BrowserBox will not be for everyone. It all depends on what you need. Get on touch if you are interested!

Run your browser on a remote machine? Using say BrowserBox: https://github.com/BrowserBox/BrowserBox

Full disclaimer: my company develops it.

to "repoint", or reorient an active RDP session to instead targe the "console", a sort of persistent virtual terminal session that the computer always has. From the days of when people actually sat in front of the machines they were using. Physically, like.

I thought that if I could send my RDP session to console then it would live. It would be alive!

And it was. But the audio still died.

All the while, I was context switching out of RDP back to my macOS desktop, to check my BrowserBox connection open in a regular browser tab. Every time, no matter what weird configurations, registry settings, or supposed ways to change various settings related to RDP, nothing worked. Every time audio still died.

This was quite possible the biggest, craziest bug I ever worked on. (Interestingly enough the second biggest, craziest bug I ever worked on was also audio related).

But maybe it wasn't a bug. Maybe it just wasn't to be. Perhaps the gods willed it to be not so. None shall ever, from now until the ashes fall upon the ghost of the world, and time stands finally still, stream audio from Windows Server without a real RDP connection.

It was during this period I also discovered the idea of a Windows Session Host server with Client Access Licenses. Turns out, you need to purchase a RDP license from Windows if you want more than 2 RDP sessions (approximately) to the same OS instance/VM.

Turns out, too, that this notion was not related at all to getting audio to work.

It really seemed like I'd never get there. I was starting to think: Cut my losses, abandon it. It was a nice dream, shame it didn't work out, but that's what happens sometimes.

One day, I woke up with a hunch, that if I could someone use VNC at the same time as RDP, perhaps I could trick the repointed console session into staying alive. I didn't know how or why this should happen, but it just seemed like: it should, somehow. As if through all my intense working with Windows, it was somehow whispering to me, telling me how it wanted to be treated. As if Windows itself wanted this to occur, and somehow through all the interacting with it, I'd absorbed that message. And figured it out. I knew I was onto something with this. Momentum, and optimism, returned. I felt re-energized. I began to feel like this was possible. But still, I had no idea how to do it.

Turns out, I eventually figured it out. And made it repeatable. And further that it worked on: Windows Server 2022, Windows Server 2019. It also, IIRC, worked on Windows 10 and Windows 11.

I formalized it all into a ridiculous PowerShell script where nothing now seemed impossible (so I went so far as to even use crazy C#-in-PowerShell hacks to close windows automatically as part of the install process, just to ensure that all that epic work, 10 hour days, maybe for over two weeks or more, were not wasted. And finally I ended up with a script that actually managed to both install BrowserBox, and set up the required VNC/RDP dance needed to keep the Windows audio drivers active, even when I do not have an RDP connection.

It was kind of complex, and like synchronized swimming, depended crucially on the order of the orchestrated VNC and RDP connections, and what was done in each session, but roughly, the process the enable audio on Windows versions, went like this:

- Create an initial RDP connection to the Windows based server for setup.

- Set up the application by performing a normal install of BrowserBox

- Open up registry key settings enabling: multiple (the maximum allowed for free, which is 2) sessions; and connecting to localhost

- Also set up a login script that will perform "The Magic Task" described below.

- Install VNC, and configure it with a password. From within that RDP session, create a VNC connection from that Windows server to itself, and ensure that VNC window is open and not minimized.

- From within that loopback VNC session just created, execute the logon script (which will happen automatically) to perform the Magic Task. The Magic Task is: use tscon to repoint the current main active RDP connection (from my local computer to this remote Windows machine) to instead point at console, disconnecting me, and creating a ourobouros-double-loopback-VNC-RDP-ying-yang super session that is self-stabilizing and crucially (Crucially! because at that point it had been 3 weeks of effort!), keep the audio streaming

The music might die one day. But not today.

I managed to factor out this code into a relatively reusable-esque script that I called Thunderbird (because I was so in awe of myself at that point haha!)

You can see the code here:

https://github.com/BrowserBox/BrowserBox/blob/boss/windows-s...

Postscript

Turns out tho, despite all that effort, Windows was never a very popular target for BrowserBox. Sure, good to prove that it works there and provide a first blush at support, but in the end, not that many people use Windows to run BrowserBox. As proud as I am of that achievement, I can't even guarantee the method described still works today. The script had so many moving parts, I imagine it would be pretty fragile. Also, I have a suspicion that, as of this post today, Microsoft may hear this and want to lock down this seeming workaround because, even tho I don't think there's a way to use it to get more RDP connections that licensed, it sort of seems like something that shouldn't be possible, so I'm kind of worried they will just stamp it out.

This sucks. Supply chain is such an issue.

Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an npm release for it. But my project BrowserBox (lightweight virtualized web browser) only uses ~800 dependencies including all descendents, with only 19 top-level deps (cool your heels non-JavaScript folks, this is comparatively lightweight for a full stack boing).

I'm considering just snapshotting all 800 deps into a @browserbox namespace at npm. And then tracking any vulnerabilities discovered and patching the fixes.

It sounds crazy, but that's where we are. At least that way I "own" all the dependencies and can guarantee (up to company security at least) that we don't have supply chain vulns on the Node/JS side.

https://socket.dev

https://github.com/BrowserBox/BrowserBox

I am not in any way associated with the developers at puppeteer, but if you are looking for a way to contribute, they are open source

With the advent of tools like Puppeteer and now Playwright, end-to-end testing has become much easier and more reliable. For anyone who's used Selenium in the past, you know what I'm talking about. Puppeteer has opened the way in terms of E2E tooling, but Playwright has taken it to the next level and made it easier to await for certain selectors or conditions to be fulfilled (via locators), thus making tests more reliable and less flaky. Also, it's a game changer that it introduced a test-runner - this made the integration between the headless browser and the actual test code much smoother.

1.Puppeteer: Puppeteer is a Node library that provides a high-level API to control headless Chrome or Chromium using the DevTools Protocol. Key Features: More control over Chrome. Enables web scraping. Allows taking screenshots and generating PDFs for UI testing. Measures load times through the Chrome Performance Analysis tool

HTML to PDF conversion is a common requirement in modern web applications. It allows users to save web pages, reports, and other content in a format that is easy to share and print. There are many libraries and services available for converting HTML to PDF, each with its own strengths and weaknesses. In this article, we will compare some of the most popular HTML to PDF renderers in Node.js, including Puppeteer, Playwright, node-html-pdf, and Onedoc.

Playwright seems to be a superior library for working with headless browsers than Puppeteer, but I will go with Puppeteer.

Puppeteer is a Node library that provides a high-level API to control headless Chrome or Chromium. It's primarily used for browser automation, making it a powerful tool for end-to-end testing of web applications, taking screenshots, and generating pre-rendered content from web pages.

Puppeteer

Website: pptr.dev Repositório: GitHub

# Define variables PYTHON := python3 POETRY := poetry PYTEST := pytest PIP := pip3 PROJECT_NAME := web automation with Pyppeteer .PHONY: install install: $(POETRY) install @echo "Dependency installation complete" $(PIP) install -r requirements.txt @echo "Set env vars LT_USERNAME & LT_ACCESS_KEY" # Procure Username and AccessKey from https://accounts.lambdatest.com/security export LT_USERNAME=himansh export LT_ACCESS_KEY=Ia1MiqNfci .PHONY: install poetry-install: poetry install .PHONY: test test: export NODE_ENV = test .PHONY: test pyunit-pyppeteer: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/pyunit-pyppeteer/test_pyunit_pyppeteer.py .PHONY: test pytest-pyppeteer: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s -n 2 tests/pytest-pyppeteer/test_pytest_pyppeteer_1.py \ tests/pytest-pyppeteer/test_pytest_pyppeteer_2.py .PHONY: test pyunit-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/starting-browser-session/pyunit/test_pyppeteer_browser_session.py .PHONY: test pytest-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s \ tests/starting-browser-session/pytest/test_pyppeteer_browser_session.py .PHONY: test asyncio-run-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/starting-browser-session/asyncio_run/test_pyppeteer_browser_session.py .PHONY: test asyncio-run-complete-pyppeteer-browser-session: - echo $(EXEC_PLATFORM) - $(PYTHON) tests/starting-browser-session/\ asyncio_run_until_complete/test_pyppeteer_browser_session.py .PHONY: test pyppeteer-button-click: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/button-click/test_page_class_click.py .PHONY: test pyppeteer-activate-tab: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/active-tab/test_page_class_bringtofront.py ###### Testing Custom Environment - https://miyakogi.github.io/pyppeteer/reference.html#environment-variables # Available versions: 113, 121, and default .PHONY: test pyppeteer-custom-chromium-version: - echo $(EXEC_PLATFORM) - echo 'Browser Version:' $(CHROMIUM_VERSION) - $(PYTEST) --verbose --capture=no -s tests/custom-configuration/test_launcher_exe_path.py ###### Testing Headless - https://miyakogi.github.io/pyppeteer/reference.html#launcher # Available values: headless and non-headless .PHONY: test pyppeteer-custom-browser-mode: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/custom-configuration/test_launcher_headless.py .PHONY: test pyppeteer-generate-pdf: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/generate-pdf/test_page_class_pdf.py .PHONY: test pyppeteer-generate-screenshot: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/generate-screenshots/test_page_class_screenshot.py .PHONY: test pyppeteer-cookies: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/handling-cookies/test_page_class_cookies.py .PHONY: test pyppeteer-dialog-box: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/handling-dialog-box/test_handling_dialog_box.py .PHONY: test pyppeteer-iframe: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/handling-iframe/test_page_class_iframe.py # Like Puppeteer, Navigation operations mentioned below only work in Headless mode # goBack: https://miyakogi.github.io/pyppeteer/reference.html#pyppeteer.page.Page.goBack # goForward: https://miyakogi.github.io/pyppeteer/reference.html#pyppeteer.page.Page.goForward # Bug Link # https://github.com/puppeteer/puppeteer/issues/7739 # https://stackoverflow.com/questions/65540674/how-to-error-check-pyppeteer-page-goback .PHONY: test pyppeteer-navigate-ops: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/navigate-operations/test_page_class_navigation_ops.py .PHONY: test pyppeteer-request-response: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/request-response/test_page_class_req_resp.py .PHONY: test pyppeteer-viewport: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/setting-useragent-viewports/\ test_page_class_useragent_viewport.py::test_mod_viewport .PHONY: test pyppeteer-non-headless-useragent: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/setting-useragent-viewports/\ test_page_class_useragent_viewport.py::test_get_nonheadless_user_agent .PHONY: test pyppeteer-headless-useragent: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s tests/setting-useragent-viewports/\ test_page_class_useragent_viewport.py::test_get_headless_user_agent .PHONY: test pyppeteer-dynamic-content: - echo $(EXEC_PLATFORM) - echo $(BROWSER_MODE) - $(PYTEST) --verbose --capture=no -s -n 4 tests/handling-dynamic-content/\ test_page_class_lazy_loaded_content.py .PHONY: test pyppeteer-web-scraping: - echo $(EXEC_PLATFORM) - $(PYTEST) --verbose --capture=no -s tests/web-scraping-content/\ test_scraping_with_pyppeteer.py .PHONY: clean clean: # This helped: https://gist.github.com/hbsdev/a17deea814bc10197285 find . | grep -E "(__pycache__|\.pyc$$)" | xargs rm -rf rm -rf .pytest_cache/ @echo "Clean Succeeded" .PHONY: distclean distclean: clean rm -rf venv .PHONY: help help: @echo "" @echo "install : Install project dependencies" @echo "clean : Clean up temp files" @echo "pyunit-pyppeteer : Running Pyppeteer tests with Pyunit framework" @echo "pytest-pyppeteer : Running Pyppeteer tests with Pytest framework" @echo "pyunit-pyppeteer-browser-session : Browser session using Pyppeteer and Pyunit" @echo "pytest-pyppeteer-browser-session : Browser session using Pyppeteer and Pytest" @echo "asyncio-run-pyppeteer-browser-session : Browser session using Pyppeteer (Approach 1)" @echo "asyncio-run-complete-pyppeteer-browser-session : Browser session using Pyppeteer (Approach 2)" @echo "pyppeteer-button-click : Button click demo using Pyppeteer" @echo "pyppeteer-activate-tab : Switching browser tabs using Pyppeteer" @echo "pyppeteer-custom-chromium-version : Custom Chromium version with Pyppeteer" @echo "pyppeteer-custom-browser-mode : Headless and non-headless test execution with Pyppeteer" @echo "pyppeteer-generate-pdf : Generating pdf using Pyppeteer" @echo "pyppeteer-generate-screenshot : Generating page & element screenshots with Pyppeteer" @echo "pyppeteer-cookies : Customizing cookies with Pyppeteer" @echo "pyppeteer-dialog-box : Handling Dialog boxes with Pyppeteer" @echo "pyppeteer-iframe : Handling iFrames with Pyppeteer" @echo "pyppeteer-navigate-ops : Back & Forward browser operations with Pyppeteer" @echo "pyppeteer-request-response : Request and Response demonstration using Pyppeteer" @echo "pyppeteer-viewport : Customizing viewports using Pyppeteer" @echo "pyppeteer-non-headless-useragent : Customizing user-agent (with browser in headed mode) using Pyppeteer" @echo "pyppeteer-headless-useragent : Customizing user-agent (with browser in headless mode) using Pyppeteer" @echo "pyppeteer-dynamic-content : Handling dynamic web content using Pyppeteer" @echo "pyppeteer-web-scraping : Dynamic web scraping using Pyppeteer"

This library works by creating an instance of WhatsApp web running inside an instance of headless chrome automated by puppeteer. In my testing, I ran into tons of compatibility issues when trying to use these dependencies inside anything other than a bare-bones Node.js + express server. Also, we can’t spin up a new instance of chrome and WhatsApp web each time a user sends a message, this will exhaust our allowed WhatsApp connections (4 max), not to mention that doing this will make the response times painfully slow.