In case the above URL does not work, here's the HTML file.

Deleted: test.html 180 bytes

test.html 180 bytes View Download

Alternative example URL:
http://liam-w.xyz/test.html

Tested in chrome # 57.0.2987.133 and Canary #59.0.3061.0 on Win 10.0 & 7 and not able to reproduce the issue.Please find the screen shots for your reference.

Steps Followed:
1. Navigate provided HTML / http://liam-w.xyz/test.html in chrome stable.
2. Click on choose file option >> browse file dialog window opened as expected.
3. Able to select the files.

@Reporter: Could you please let me know if i have missed anything and if possible, please create new profile with out extensions and apps.Re-check once and let us know the observations and specific URL of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 707307.png 178 KB

	707307.png 178 KB View Download

Thanks for the quick attention.

The only difference between our environments are that I'm using the 64-bit build of Chrome on Windows 10 (latest stable build of Windows 10).

I'm using a 100% clean install of Windows 10 and Chrome. I'm not logged into any specific profile, no apps or extensions installed at all. Totally vanilla Chrome.

It may be worth testing it on a 64-bit build, but that seems odd. Heh, though not quite as odd as a TLD apparently dictating whether the browse files dialog opens or not...

In the meantime, I'm going to do a quick screen recording which I will upload and provide the link. Obviously you won't be able to see much other than the browse file dialog just not opening...

Thanks again,

Chris

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hello,

As promised, please view the following YouTube video.

The video opens with the versions screen open. I then open the example URL and this demonstrates the issue. I then open a locally hosted version of the test, routed through a .zone TLD and that works fine.

https://youtu.be/Pzy0i1bQ8pI

As a somewhat interesting note, the original example URL (http://mattwservices.xyz/test.html) seems to work fine. I'm currently trying to find out from the owner of that domain whether anything has changed there.

It does make me wonder if the TLD thing is a red herring, but clearly there does appear to be something going wrong somewhere in some cases some of the time.

Regards,

Chris

The gent who owns the mattwservices.xyz domain has since confirmed that, despite there being absolutely no changes to anything, everything now works fine.

This doesn't make a lot of sense, but there was definitely an issue there and there is still (for me and others) an issue with the other .xyz domains we've tried.

Unable to reproduce this issue on Windows 10 -64 Bit with chrome #57.0.2987.133 
Observed that on clicking "choose file" it is opening pop-up box to select the file to upload.

chris@ could you re-try the same scenario on clean profile with no apps/extensions and let us know your observations.

Thank You...

Deleted: Issue 707307.PNG 6.0 KB

	Issue 707307.PNG 6.0 KB View Download

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hello @kkaluri

It unfortunately isn't going to make a difference as to how many times I try it, it will remain to be reproducible.

Please see this new video:
https://www.youtube.com/watch?v=GfMXQ1VJadA

In the first few seconds you will see the current version info (most recent stable) followed by me resetting my profile (it was already a clean profile, no apps or extensions) before I proceed to test it on four different URLs.

Three of the URLs do not work:
http://liam-w.xyz/test.html
http://mattwservices.xyz/test.html
http://localhost.xyz/test.html

One of the URLs does work:
http://localhost.zone/test.html

The two "localhost" URLs are the most significantly interesting because:

1) They are locally hosted
2) Both the local domains point to exactly the same IP (127.0.0.1 of course)
3) Both the local domains point to the same web server

Yet, the result is that the one with an ".xyz" TLD does not work, the one with a ".zone" TLD does work.

Unfortunately, regardless of whether this issue can be reproduced by the developers, I think we've done enough (and I am just reporting it on behalf of several people who can also reproduce the issue) to prove that this is a genuine issue.

The fact that the developers cannot reproduce this is certainly an obstacle (and a confusing and frustrating one at that!) but we need to find a way around that so we can diagnose it further.

Is there anything you can recommend? Any log files to look at? Any way of enabling any sort of additional logging or debug information? I'm a developer myself (though not one who is familiar with the internals of Chromium) so I should be able to complete any additional technical tasks to help debug this if you can point me in the right direction.

Many thanks to everyone who has given this their attention so far.

Chris

Is this reproducible in Incognito Window?

Yes. 

Thank you for providing more feedback. Adding requester "tkent@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I confirmed the issue was reproducible with Google Chrome 58 stable, and was NOT reproducible with Google Chrome 60 canary.  I assume this was already fixed.