Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of native dialogs inconsistent with handling in Firefox #6815

Closed
dfn-certling opened this issue Jan 11, 2022 · 5 comments
Closed

Handling of native dialogs inconsistent with handling in Firefox #6815

dfn-certling opened this issue Jan 11, 2022 · 5 comments
Assignees
Labels
BROWSER: Firefox FREQUENCY: level 1 Good first issue TYPE: bug The described behavior is considered as wrong (bug).

Comments

@dfn-certling
Copy link

What is your Scenario?

I have a form with a beforeunload handler attached on changes. I want to write a test that verifies the conditions of the dialog being shown.

What is the Current behavior?

The dialog appears when opened in the browser directly, but it is not triggered when exercised in a test.

What is the Expected behavior?

The dialog should be triggered in the test.

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

The behavior can be reproduced with the following example page

<html>
<body>
    <script>
        var formSubmitting = false;
        var setFormSubmitting = function () { formSubmitting = true; };

        window.onload = function () {
            window.addEventListener("beforeunload", function (e) {
                if (formSubmitting) {
                    return undefined;
                }

                e.preventDefault();
                e.returnValue = '';
            });
        };
    </script>
    <form method="post" onsubmit="setFormSubmitting()">
        <input type="text">
        <button type=submit>Ok!</button>
    </form>
    <button type="button" onclick="window.location.reload()">Refresh!</button>
</body>
</html>

This is an adaption of the example used in #5994 (comment). According to the MDN documentation on onbeforeunload strings returned or set for returnValue are not presented to the user anymore. The example present in the documentation gives the above e.preventDefault() and e.returnValue commands to display the dialog, which works in Firefox directly.

What is your TestCafe test code?

import { Selector } from 'testcafe';

fixture `New Fixture`
    .page `file:///<path>/test.html`
    
test(`New Test`, async t => {
    await t
        .setNativeDialogHandler(() => true)
        .typeText('form input', 'wqeqweqw')    
        .click(Selector('button').withText('Refresh!'))

    console.log(await t.getNativeDialogHistory());
});

Your complete configuration file

No further configuration

Your complete test report

 Running tests in:
 - Firefox 95.0 / Linux 0.0

 New Fixture
[]
 ✓ New Test


 1 passed (1s)

Screenshots

No response

Steps to Reproduce

  1. Run the above test with Firefox; at least in my setup no dialog is logged
  2. Compare with opening the page directly in the browser and testing by hand

Curiously some changes to the example page do trigger it. One way is to set a nonempty string for the returnValue, another one is to switch the order of calling preventDefault and setting returnValue. None of these changes change the result when testing in the browser directly, and they are not required by my reading of the MDN documentation. This only happens in Firefox, Brave for example (Chromium based) triggers the dialog also in the test all the time.

TestCafe version

1.18.1

Node.js version

v16.13.1

Command-line arguments

testcafe firefox test-handler.js

Browser name(s) and version(s)

Firefox 95.0

Platform(s) and version(s)

openSUSE Tumbleweed

Other

No response

@dfn-certling dfn-certling added the TYPE: bug The described behavior is considered as wrong (bug). label Jan 11, 2022
@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label Jan 11, 2022
@dfn-certling
Copy link
Author

Browsers and standards... Digging further into this, the example in MDN is a bit weird, since setting the returnValue to an empty string just seems not to be what the HTML standard describes to prompt the user. Under 8 it says to show the dialog if evt.preventDefault() was called (the event is cancelled) or evt.returnValue is not the empty string.

But the comment in MDN's example is correct about Chrome, which has an outstanding bug that requires the returnValue to be set to any value to prompt the user. So while MDN seems to go against the standard, it correctly addresses Chrome's behavior.

This just for references or curiosity. It remains that Firefox shows the dialog irrespective of the order of calling preventDefault and setting returnValue. Run in testcafe, the order matters if returnValue is set to the empty string.

@aleks-pro
Copy link
Collaborator

Hello @dfn-certling ,

Thank you for pointing out this issue and sharing the code example.
We reproduced the empty output for the Firefox browser. We will research this issue in detail.

@need-response-app need-response-app bot removed the STATE: Need response An issue that requires a response or attention from the team. label Jan 18, 2022
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had any activity for a long period. It will be closed and archived if no further activity occurs. However, we may return to this issue in the future. If it still affects you or you have any additional information regarding it, please leave a comment and we will keep it open.

@github-actions github-actions bot added the STATE: Stale An outdated issue that will be automatically closed by the Stale bot. label Jan 19, 2023
@dfn-certling
Copy link
Author

The issue is still present as originally described with TestCafe 2.2.0, Node v16.18.0 and Firefox 108.0.2.

@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label Jan 19, 2023
@github-actions github-actions bot removed the STATE: Stale An outdated issue that will be automatically closed by the Stale bot. label Jan 20, 2023
@Aleksey28 Aleksey28 removed the STATE: Need response An issue that requires a response or attention from the team. label Jan 20, 2023
@PavelMor25 PavelMor25 self-assigned this Nov 21, 2023
@AlexKamaev
Copy link
Contributor

fixed in DevExpress/testcafe-hammerhead#2980

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BROWSER: Firefox FREQUENCY: level 1 Good first issue TYPE: bug The described behavior is considered as wrong (bug).
Projects
None yet
Development

No branches or pull requests

6 participants