intoli / remote-browser Goto Github PK

I'm really excited about this project. A potential gotcha was pointed out in the hn thread, so I thought I'd take the conversation here since that thread seems to have lost momentum.

How can we simulate typing using remote-browser? Technically we can set an input element's value to something, or create keypress, keydown, etc. events. But it seems that webdriver takes a different approach that's closer to true user input. I don't know how webdriver does it, but the use case is a website that, say, auto-formats a phone number or credit card number as you type it. Sometimes these don't work when you set the value of the input field. Another example is JS-based validations. The type method on puppeteer and selenium seem to fool the browser into thinking a user is typing. How might we achieve this in remote-browser?

Hi Sir @intoli , I am a graphic designer and I want to contribute to your project by proposing a logo as i have noticed that the project has no logo yet. I am giving this designs as a gift if you liked it i will send you the needed files asap. If you have suggestions like color preference just let me know sir and I will edit it.

Here are my designs: I made 2 designs

DESIGN 1

logomark

logotype A

logotype B

DESIGN 2

logomark

logotype A

logotype B

Best regards,
Tobaloidee

Supporting Selenium JavaScript API would be great as it seems to be more popular that WebExtensions API.
For example, navigation to url can be done in Selenium terms:

await driver.get('https://intoli.com');

instead of:

browser.tabs.create({ url: 'https://intoli.com' });

PS: some time ago I've made similar project - autotester. It's a browser extension that transforms selenium commands into WebExtensions API calls. Maybe it would be useful.

Hi, I'm having an issue trying the package.

The code is taken from the example.

const Browser = require('remote-browser').Browser;

(async () => {
  // Create and launch a new browser instance.
  const browser = new Browser();
  await browser.launch();

  // Directly access the Web Extensions API from a remote client.
  const tab = await browser.tabs.create({ url: 'https://intoli.com' });
  const screenshot = await browser.tabs.captureVisibleTab();
})();

I use macOs, firefox is my default browser. However, when I start with 'node index.js', Chrome is launched, and I receive the following error :
Failed to load extension from:. Manifest file is missing or unreadable

It would be nice for people to be able to try things out without having to worry about installing geckodriver. We can strip this out when we move off of Selenium.

When you connect remotely to a server. Is the javascript execution done on the remote server or on the client browser? i guess what i'm trying to figure out is that when you connect to a remote server does the browser becomes just a DOM viewer and all of the JS executions happens on a remote server. i'm in need of a library to create a cloud browser such as puffin. i need to offload all of JS executions to a remote server.

How do I access this API?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/proxy

I expected the following but it doesn't work:

let settings = await browser.proxy.settings
...

Safari serializes async arrow functions to

async function (variable) => { // code }

which is invalid. This only happens for the outermost function, so it should be relatively easy to add special handling for this case. We should also report this to Safari, it seems to be in violation of the ECMA spec:

If the object was defined using ECMAScript code and the returned string representation is not in the form of a MethodDefinition or GeneratorMethod then the representation must be such that if the string is evaluated, using eval in a lexical context that is equivalent to the lexical context used to create the original object, it will result in a new functionally equivalent object.

This didn't work out so well the first time due to the webpack exclude regexes, this is a second attempt.

We won't want this long-term, but it will be helpful during development while we have the project listed as a git dependency in other projects.

Turbo might be relevant here.

See conversation in #67.

It's convenient for quickly launching browsers, but it really shouldn't be necessary.

It will be easier to get a fresh start on the interface because so much will be changing.

This would be nice both for debugging and for quickly scripting things in your everyday browser. There are security considerations though. Perhaps a key would have to be entered and the client can do some proof of identity based on that.

Hi,

I'm figuring out how to intercept requests. I have to following snippet inside my code:

    browser.webRequest.onBeforeRequest.addListener(
      function(details) {
        return { cancel: details.url.indexOf('news.ycombinator.com') != -1 };
      },
      { urls: ['<all_urls>'] },
      ['blocking'],
    );

Inside the manifest.json (remote-browser module) I've following permissions:

"permissions": ["<all_urls>", "tabs", "webRequest", "webRequestBlocking"]

But my code gives following error:

Invalid listener for webRequest.onBeforeRequest

What am I doing wrong?

It would be nice to add --headless browser option when launching in production, available in Chrome since v59, also available in Mozilla Firefox.

The README makes multiple references to a 'Remote Browser' extension, but neither provides a link to it or any steps to to install it from source (possible the src/extension directory). I am really not sure if I am missing something, but it feels like a lot of people might get stuck here when trying to run remote-browser against their daily use browser.

When I take the "Intoli Remote Browser Tour" i. e. on page 5 and click on the Image Data entry within the console after running the example I get the following image which is basically Ok for privacy reasons but nonetheless other than what I would have expected?

I have recently started using remote-browser and when I was working on it, I realized that the documentation is extremely lacking and it took me snooping around the code a lot of time to figure out what's happening.

Towards that effort, I would like to work on the documentation for this project and hence creating this issue so that we can discuss what all needs to be covered. A list of topics off the top of my head are:

1. Setting up the browser extension
2. How to pass arguments to the evaluateInContent function and the rationale behind why variables are not closed-over. This one took me quite some time to figure out till I realized that the function is serialized and sent over to the browser. In retrospect, it looks quite obvious, but would be very deterring to new users.
3. A troubleshooting guide to wait for document loads. I am not sure how the evaluator.readyState works, but it didn't work for me. I am using a kind-of hack to wait before proceeding:

function waitFor(browser, tabId, elementLookupList) {
    return new Promise(resolve => {
        const interval = setInterval(checkForElements, 500);

        function checkForElements() {
            const allReadyPromise = elementLookupList.map(ele => {
                return browser[tabId](ele);
            })

            Promise.all(allReadyPromise)
                .then((elements) => {
                    if (elements.every(x => x)) {
                        resolve();
                    }
                })
        }
    });
}

// USAGE
await waitFor(browser, tabId, [
     () => document.getElementById('fldLoginUserId') != null,
     () => document.querySelectorAll("input[name='fldSubmit'][value='Continue']").length === 1
]);

4. A few more examples of what can be done. I really like the format of the small video you have created to show a live session with a running browser. If the documentation can improve on the process, it would get a lot of people invested very quickly (or so is what I think).

I was thinking of starting with some basic additions to the current README, maybe add more details to each section - especially places where I got stuck and then move on to a caveats guide as well. Before starting, I'll share a quick outline of what I am thinking about the documentation and once we both agree that it looks good, I'll write it out and submit a PR.

Please let me know what else you think can be useful and should be included in the documentation and I'll work on the outline accordingly.

We should allow connecting to remote browser instances for use within the product tour.

This is making the builds non-deterministic because port conflicts can arise. I don't think it's worth it to deal with this uncertainty for now, better to re-evaluate later when performance becomes an issue.