Failing tests `identifier 't' has already been declared` Jitsi

[humanamburu]

What is your Scenario?

Simple open Jitsi call page test

What is the Current behavior?

All the same, behavior as described here:

• Identifier 't' has already been declared
• page works when opened manually, no issues or errors were observed

What is the Expected behavior?

TestCafe should be able to render the app independent of the host scripts

What is your public website URL? (or attach your complete example)

https://meet.jit.si/testcafe_error

What is your TestCafe test code?

await t.navigateTo('https://meet.jit.si/testcafe_error');
await t.wait(500000);

Your complete configuration file

No response

Your complete test report

No response

Screenshots

Test:

Manual (everything works fine):

Steps to Reproduce

1. https://meet.jit.si/testcafe_error
2. Open the call page using testcafe

TestCafe version

1.18.1

Node.js version

14.15.4

Command-line arguments

testcafe --skip-js-errors --hostname localhost $NODE_DEBUG_OPTION "chrome --use-fake-ui-for-media-stream --use-fake-device-for-media-stream"

Browser name(s) and version(s)

Chrome 96

Platform(s) and version(s)

macOS 10.15.7

Other

No response

[AlexanderMoiseev]

Hi,

Your testing page has javascript errors. By default, TestCafe tests fail if a javascript error occur. Please fix your page errors first or ignore them by using --skip-js-errors option and let us know the result.

[humanamburu]

Hello @AlexanderMoiseev,

I retested with --skip-js-errors option and the issue is still blocking the testing flow, could you please reopen issue again? The issue is absolutely identical to the https://github.com/DevExpress/testcafe/issues/5659 that marked as fixed.

I've updated commands and screenshots sections.

Thank you in advance.

[AlexanderMoiseev]

Hello,

Unfortunately, I could not reproduce this behavior - when I use --skip-js-errors option, the test passes for me.

Please send us a video to demonstrate how you reproduce the issue. Make sure that the callstack with the problem is also visible.

[humanamburu]

@AlexanderMoiseev thank you for the quick response, I've added the video, hope it will help!

[AlexanderMoiseev]

Hi @humanamburu,

It looks like the video you added isn't publicly available - I cannot open it.

[humanamburu]

@AlexanderMoiseev sorry for the inconvenience, updated to public.

[miherlosev]

Hi @humanamburu

Thank you for the shared video. I've reproduced the issue.

For team: The issue is in script processing with temporary variable creation.

[RicardoMiguel]

Hi,

I'm also being affected by this. Is there any estimation to when a fix will be released? Thanks!

[github-actions[bot]]

No updates yet. Once we get any results, we will post them in this thread.

[aal89]

I'm having the same issue. Are there any updates on this?

Jitsi Meet library has this code:

if (state.haveParticipantWithScreenSharingFeature && String(features['screen-sharing']) === 'true') {
    const {
        features: localFeatures = {}
    } = state.local || {};

    if (String(localFeatures['screen-sharing']) !== 'true') {
        state.haveParticipantWithScreenSharingFeature = false;

        // eslint-disable-next-line no-unused-vars
        for (const [key, participant] of state.remote) {
            const {
                features: f = {}
            } = participant;

            if (String(f['screen-sharing']) === 'true') {
                state.haveParticipantWithScreenSharingFeature = true;
                break;
            }
        }
    }

}

(See: https://github.com/jitsi/jitsi-meet/blob/477d47c10ddf18416fedf8a977bd0b3f63dc2dae/react/features/base/participants/reducer.js#L292)

This compiles into this with hammerhead:

if (e.haveParticipantWithScreenSharingFeature && "true" === String(u["screen-sharing"])) {
    const _hh$temp1824 = e.local || {},
        _hh$temp1824$features = _hh$temp1824.features,
        t = _hh$temp1824$features === void 0 ? {} : _hh$temp1824$features;
    if ("true" !== String(t["screen-sharing"])) {
        e.haveParticipantWithScreenSharingFeature = !1;
        for (const _hh$temp1825 of e.remote) {
            const _hh$temp1826 = __arrayFrom$(_hh$temp1825),
                t = _hh$temp1826[0],
                n = _hh$temp1826[1];
            const _hh$temp1827 = n,
                _hh$temp1827$features = _hh$temp1827.features,
                t = _hh$temp1827$features === void 0 ? {} : _hh$temp1827$features;
            if ("true" === String(t["screen-sharing"])) {
                e.haveParticipantWithScreenSharingFeature = !0;
                break
            }
        }
    }
}

Then identifier 't' has already been declared on line: t = _hh$temp1827$features === void 0 ? {} : _hh$temp1827$features;

A for-of loop and within it destructering assignments. I believe hammerhead fails to properly handle this.

Related issues: https://github.com/DevExpress/testcafe-hammerhead/issues/2515 https://github.com/DevExpress/testcafe-hammerhead/issues/2506

[miherlosev]

Hi @aal89

Thank you for the detailed information. We will investigate it.

[aal89]

Any updates on this? We're working around this now using a custom (hacky) patch, but would love a proper fix for it.

[github-actions[bot]]

No updates yet. Once we get any results, we will post them in this thread.

[miherlosev]

The simplest code to reproduce

for (const [t,n] of []) {
    const {features: t={}} = n;
}

It's possible to use the destruction assignment to redeclare the t variable.

[miherlosev]

Hi @humanamburu,

TestCafe runs tests using the URL-rewritten proxy. This approach is good. However, there is a way to improve the stability and speed of test execution - the native browser automation API. We have a test execution mode uses native browser automation - we call it the Proxyless mode. In Proxyless mode, a few issues are already fixed. By the way, this issue was also fixed in Proxyless mode. This option is available in all interfaces:

// Command-line
testcafe chrome tests --experimental-proxyless

// Programmatic
const testcafe = await createTestCafe({ experimentalProxyless: true });

// Configuration file
{
   "experimentalProxyless": "true"
}   

Setup the testcafe@2.1.1-alpha.3 version and try running your tests in Proxyless mode. I look forward to your results. Note that at present it is an experimental mode. Also, the Proxyless mode is implemented only in Google Chrome. It will not work correctly if you run tests in a non-Chrome browser or in a combination of other browsers.

[humanamburu]

Thank you! @aal89 could you please take a look?

[aal89]

I took a look at the experimental setting but it did not work (I also updated to TestCafe 2.2.0). I found another bug. It seems that testcafe-hammerhead still rewrites some headers even though I switched on the proxyless flag. It prepends this into the authorization header: ~~~TestCafe added this prefix to control the authorization flow~~~ but it never removes it anymore. So executing our testsuite now shows 401's all over the place.

But there's some good news too. I did do another test. I asserted in our auth checks for this particular string, when it finds it, it removes it. Just to check if proxyless, in theory, would work. And it works!

Ongoing discussion: https://github.com/DevExpress/testcafe/issues/4474 testcafe-hammerhead Code: https://github.com/DevExpress/testcafe-hammerhead/blob/4751c9fd97df3e4a0d505cc909cbd191fd1d227a/src/utils/headers.ts

[miherlosev]

Hi @aal89,

Thank you for sharing this information. We will investigate it.

[miherlosev]

Hi @aal89,

The testcafe@2.3.1-alpha.1 version contains a fix connecting with handling the 401 HTTP status code. Try to run the tests with this version and let us know the results.

[aal89]

I will check asap, thank you @miherlosev !

[Artem-Babich]

Hi @aal89

Could you clarify if the original issue is resolved, as well as the issue with the HTTP 401 status code? Please note that we renamed the proxyless option to native-automation in TestCafe v2.5.0.

[github-actions[bot]]

This issue was automatically closed because there was no response to our request for more information from the original author. Currently, we don't have enough information to take action. Please reach out to us if you find the necessary information and are able to share it. We are also eager to know if you resolved the issue on your own and can share your findings with everyone.