Bug 1461932 - Upload image UI shows "C:\fakepath\disk_name" after selecting a disk to be uploaded in Chrome (55 and 59)
Upload image UI shows "C:\fakepath\disk_name" after selecting a disk to be up...
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
4.2.0
Unspecified Unspecified
unspecified Severity high (vote)
: ovirt-4.2.0
: 4.2.0
Assigned To: Daniel Erez
Natalie Gavrielov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-15 12:07 EDT by Natalie Gavrielov
Modified: 2017-12-22 02:22 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
: 1474585 1474590 (view as bug list)
Environment:
Last Closed: 2017-12-20 06:14:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+


Attachments (Terms of Use)
engine.log, ui.log, server.log, image-proxy.log, snapshots from Chrome 55 and Chrome 59 (2.66 MB, application/zip)
2017-06-15 12:07 EDT, Natalie Gavrielov
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 79062 master MERGED webadmin: image upload - remove fakepath prefix 2017-07-06 05:10 EDT

  None (edit)
Description Natalie Gavrielov 2017-06-15 12:07:21 EDT
Created attachment 1288111 [details]
engine.log, ui.log, server.log, image-proxy.log, snapshots from Chrome 55 and Chrome 59

Description of problem:
When selecting a disk to be uploaded, UI shows "C:\fakepath\" + file chosen, instead of just the file chosen for Chrome 55 and 59 (Firefox works fine showing the file name only).
Snapshots attached.

Version-Release number of selected component:
ovirt-engine-4.2.0-0.0.master.20170606135217.gita02bf9d.el7.centos.noarch
ovirt-imageio-proxy-1.0.0-0.201706060741.git25ceb73.el7.centos.noarch
ovirt-imageio-common-1.0.0-0.201706060741.git25ceb73.el7.centos.noarch

and
ovirt-engine-4.2.0-0.0.master.20170612192318.gitf773263.el7.centos.noarch
ovirt-imageio-proxy-1.0.0-0.201705101937.git911f423.el7.centos.noarch
ovirt-imageio-common-1.0.0-0.201705101937.git911f423.el7.centos.noarch

How reproducible:
100%

Steps to Reproduce:
1. Go to webadmin -> Disks tab
2. Click on Upload -> Start 
3. Choose File

Actual results:
File chosen is displayed in the UI the following way:
C:\fakepath\the_filename

Expected results:
Just the filename (no C:\fakepath prefix)

Additional info:
Tested with two Chrome versions: 55 and 59:
- For 55, the upload is blocked and shows the following message:
  "The selected file cannot be opened".
- For 59 version there is no such message, and regardless, upload doesn't work because of a bug found for Chrome 58
Comment 1 Allon Mureinik 2017-06-15 12:39:36 EDT
Does this happen in 4.1.z too?
Comment 2 Daniel Erez 2017-06-15 12:54:49 EDT
It's actually a standard security measure of HTML5 [1]. 
The path could be revealed by configuring the browser's settings: https://www.nextofwindows.com/how-to-get-rid-of-cfakepath-in-ie-when-uploading-a-file-to-the-website-fix

@Allon - do we want to find some hack to remove this even though it's by html design?

E.g. https://stackoverflow.com/questions/21426232/how-to-remove-c-fakepath-in-webkit-browser-like-chrome-safari-opera

[1] "According to the specifications of HTML5, a file upload control should not reveal the real local path to the file you have selected, if you manipulate its value string with JavaScript. Instead, the string that is returned by the script, which handles the file information is c:\fakepath." 

[https://acidmartin.wordpress.com/2009/06/09/the-mystery-of-cfakepath-unveiled/]
Comment 3 Allon Mureinik 2017-06-15 12:59:46 EDT
(In reply to Daniel Erez from comment #2)
> @Allon - do we want to find some hack to remove this even though it's by
> html design?
This is a PM question, but my gut instinct is to close this as NOTABUG.
Yaniv?
Comment 4 Yaniv Lavi 2017-06-18 04:25:47 EDT
(In reply to Allon Mureinik from comment #3)
> (In reply to Daniel Erez from comment #2)
> > @Allon - do we want to find some hack to remove this even though it's by
> > html design?
> This is a PM question, but my gut instinct is to close this as NOTABUG.
> Yaniv?

Maybe we should not display the path at all.
I think just the file name or some checkbox would work better.
UX should probably be consulted.
Comment 5 Allon Mureinik 2017-06-18 05:10:36 EDT
(In reply to Yaniv Lavi from comment #4)
> (In reply to Allon Mureinik from comment #3)
> > (In reply to Daniel Erez from comment #2)
> > > @Allon - do we want to find some hack to remove this even though it's by
> > > html design?
> > This is a PM question, but my gut instinct is to close this as NOTABUG.
> > Yaniv?
> 
> Maybe we should not display the path at all.
> I think just the file name or some checkbox would work better.
> UX should probably be consulted.

Eldan, your two cents?
Comment 6 Eldan Hildesheim 2017-06-22 07:38:15 EDT
I don't really see a reason to show the full path unless we keep it for future purposes, so from my point of view: Show only the file name, no path.
Comment 7 Allon Mureinik 2017-06-26 04:03:04 EDT
(In reply to Eldan Hildesheim from comment #6)
> I don't really see a reason to show the full path unless we keep it for
> future purposes, so from my point of view: Show only the file name, no path.

Agreed.
Daniel - let's do that please.
Comment 8 Natalie Gavrielov 2017-06-26 04:22:15 EDT
I'm glad that you all came to the conclusion that it's best to show the filename only (which was the behavior in previous versions, such as 4.1) and not closing this as not a bug.

I somehow feel that none of you guys read the expected result in the description of the bug.

Here it is:

Expected results:
Just the filename (no C:\fakepath prefix)

Just saying..
Comment 9 Allon Mureinik 2017-07-06 08:38:25 EDT
Daniel - the patch is merged. Is there anything else we're waiting for here, or should it be moved to MODIFIED?
Comment 10 Natalie Gavrielov 2017-08-30 09:18:02 EDT
Verified with Chrome 59 and 60.
Build used: ovirt-engine-4.2.0-0.0.master.20170828065003.git0619c76.el7.centos.noarch
Comment 11 Sandro Bonazzola 2017-12-20 06:14:34 EST
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.