SeleniumHQ / selenium

A browser automation framework and ecosystem.
https://selenium.dev
Apache License 2.0
30.22k stars 8.11k forks source link

Consecutive file uploads using SendKeys with Chrome v75 or later. (C#) #7472

Closed werfmark closed 2 years ago

werfmark commented 5 years ago

šŸ› Bug Report

Consecutive file uploads to an Input[type=file] element with SendKeys duplicate files uploaded before in Chrome v75 or later. In Chrome v74 this didn't happen. Specifically uploaded a file will make all files be uploaded again. So a 4th file upload will unintentionally upload file 1, 2 and 3 again.

To Reproduce

Detailed steps to reproduce the behavior:

  1. Search an "input[type=file]" WebElement
  2. Use ChromeWebDriver with Chrome 76.0.3809.87 installed and Selenium.Chrome.WebDriver 76.0.0 and Selenium.WebDriver 3.141.0
  3. Use SendKeys twice on the input element to send a file (NOTE: not two files at once but consecutively)

Expected behavior

The files are uploaded once each.

Actual behavior

The first file is uploaded twice, the second file once.

Test Code C

using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using System;
using System.IO;
using System.Reflection;

namespace UnitTestProject1
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
            var driver = new ChromeDriver(Directory.GetCurrentDirectory(), new ChromeOptions());

            driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(15);

            driver.Url = "https://gofile.io/?t=uploadFiles";

            var path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
            var pdfFile1 = $"{path}\\Files\\File1.pdf";
            var pdfFile2 = $"{path}\\Files\\File2.pdf";

            var input = driver.FindElementByXPath("//input[@type='file']");

            input.SendKeys(pdfFile1);
            input.SendKeys(pdfFile2);

            Assert.AreEqual(2, driver.FindElementsByXPath("//tbody//tr[@role='row']").Count);
        }
    }
}

The two files are random PDFs in a folder called Files in the solution with "Copy always to Output Directory"

Environment

OS: Windows 7 64bits Browser: Chrome 76.0.3809.87 Selenium Webdriver: 3.141.0

Potential Workaround

There is a potential workaround for not having to upload files consecutively by uploading them all at once by using SendKeys with one string with multiple filenames separated by "\n" but this does not work if you're using RemoteWebDriver with LocalFileDetector, see: https://github.com/SeleniumHQ/selenium/issues/7408

jimevans commented 5 years ago

@werfmark I refer you to my comment on #7489. There is likely little that can be done by the language bindings to change this behavior, unless the LocalFileDetector is not correctly handling file lists with embedded \n delimiters. I can see a case in the .NET bindings, at least, where they might not be handling that correctly.

JohnChen0 commented 5 years ago

The behavior of ChromeDriver 75 and later has been updated to conform to the latest W3C WebDriver standard. For this particular case, the standard (https://www.w3.org/TR/webdriver/#element-send-keys) specifies that "If multiple is true files are be appended to elementā€™s selected files." So I believe ChromeDriver working correctly by keeping the existing selected files and adding the new ones.

werfmark commented 5 years ago

Hmm I don't quite see how "If multiple is true files are (to) be appended to element's selected files." in the W3C standard means that uploading a second file results in the first file uploaded again. As I understand it uploading a second file should append it to the element's selected files and thus only 2 files are shown uploaded in total?

I don't see how this W3C webdriver standard wording means this functionality is as intended. Also if it does somehow mean that (I find it hard to grok the exact meaning) I find it an unlogical choice. If you want to add multiple files to an input element consecutively for some reason this means there is no way to do that elegantly now?

Basically I don't understand this behaviour to be intentional, if it is however it makes no sense?

twalpole commented 5 years ago

@werfmark The spec says nothing about files actually being uploaded, just about adding the files to the file input. As you've noticed the issue is that if you have a change event handler on the file input that automatically uploads attached files it creates a condition where files will get repeatedly uploaded. This is because on the first change event there is one file attached to the file input(which gets uploaded but not cleared), then on the second change event two files are attached to the file input so two files get uploaded, etc. The appending behavior has been argued as making no sense (because it's not something a user can actually do) by a number of people, but it was originally implemented/specified like that for legacy reasons and has stayed in the spec.

As you've mentioned, uploading multiple files at once is possible, in the spec (\n separated names), and should work even with a File detector (although you may need to execute JS to set the elements value property to null before attaching multiples if the input already has files attached). This does appear to work correctly with the Ruby bindings locally and remotely to the current standalone server release version for both Chrome and Firefox, so it does point towards it possibly being an issue in the bindings you're using.

barancev commented 4 years ago

It seems that consecutive file uploads work in as specified.

So I want to reframe this issue: attaching and uploading multiple files at once should be supported in C#, it works locally but not with RemoteWebDriver yet.

markhm commented 4 years ago

I've just observed this behaviour described in this issue on Java as well.

Selenium Java: org.seleniumhq.selenium/selenium-java:3.141.59
Chromedriver v79.0.3945.36
macOS 10.15.2 (19C57) / OpenJDK 13.0.1

The workaround works.

Is there any other place this should be reported...?

dethu commented 4 years ago

I also noticed behavior described here using Python.

Selenium Python: 3.141.0
Chromedriver v79.0.3945.36
OS: Host machine: Ubuntu 19.04.
Remote WebDriver machine: Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-74-generic x86_64) with aerokube/selenoid:1.10.0

The potential workaround does not work

There is a potential workaround for not having to upload files consecutively by uploading them all at once by using SendKeys with one string with multiple filenames separated by "\n" but this does not work if you're using RemoteWebDriver with LocalFileDetector, see:

7408

There is a fix for Java as i found out https://github.com/SeleniumHQ/selenium/issues/7408#issuecomment-555341644

so i have a same question:

Is there any other place this should be reported...?

odonovan-johnd commented 4 years ago

I've just hit this issue on an Angular project, luckily I found this. Unfortunately, I'm not able to do the "\n" with the way our file uploads are managed. Has there been any work on correcting this behaviour?

nandesu commented 4 years ago

I also noticed behavior described here using Python.

Selenium Python: 3.141.0
Chromedriver v79.0.3945.36
OS: Host machine: Ubuntu 19.04.
Remote WebDriver machine: Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-74-generic x86_64) with aerokube/selenoid:1.10.0

The potential workaround does not work

There is a potential workaround for not having to upload files consecutively by uploading them all at once by using SendKeys with one string with multiple filenames separated by "\n" but this does not work if you're using RemoteWebDriver with LocalFileDetector, see:

7408

There is a fix for Java as i found out #7408 (comment)

so i have a same question:

Is there any other place this should be reported...?

Any update on this for Python? \n isn't working for me either.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 14 days.

github-actions[bot] commented 2 years ago

This issue was closed because it has been stalled for 14 days with no activity.

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.