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

Can dialog#showOpenDialog return File instances instead of paths? #6809

Closed
jakubzitny opened this issue Aug 11, 2016 · 5 comments
Closed

Can dialog#showOpenDialog return File instances instead of paths? #6809

jakubzitny opened this issue Aug 11, 2016 · 5 comments

Comments

@jakubzitny
Copy link
Contributor

Currently, when choosing files from filesystem using dialog#showOpenDialog, it "returns an array of file paths chosen by the user". That's strings.

However, when using a <input type="file".. form or a drag&drop for taking files into a browser, these return instances of File.

Would it make sense / would it be possible to return Files from Electron's showOpenDialog?

@jakubzitny jakubzitny changed the title Can dialog#showOpenDialog return File instanced instead of paths? Can dialog#showOpenDialog return File instances instead of paths? Aug 11, 2016
@zcbenz
Copy link
Member

zcbenz commented Aug 12, 2016

No, File is an DOM element while showOpenDialog is an API in the main process.

@zcbenz zcbenz closed this as completed Aug 12, 2016
@jakubzitny
Copy link
Contributor Author

@zcbenz I understand the differences. However, now the deveopers have to deal with different file input from user in renderer and in menu. Right now, the only way to upload or read a file from showOpenDialog (let's say it's app menu) is to use node's fs. I can use streams to make this efficient, but I always have to handle this differently than file from file input or from drag and drop. Why not use the already implemented and optimized File stuff?

I think this is totally valid scenario to consider. main and renderer can communicate, there should be a way to implement this. I am now "hacking" it around by having invisible file input in the renderer that's triggered from tha app menu. But this is stupid if Electron already has the dialog stuff.

What do you think?

@zeke
Copy link
Contributor

zeke commented Aug 26, 2016

. I am now "hacking" it around by having invisible file input in the renderer that's triggered from tha app menu.

Can you share your hack here?

@jakubzitny
Copy link
Contributor Author

jakubzitny commented Aug 26, 2016

@zeke So I have hidden file input in renderer, I send ipc message from Main after user clicks on a menu item, the message is listened to in renderer and when it arrives I call webFrame.executeJavaScript where I click on the hidden file input.

This is on the page:

<input type="file" id="file__hidden" style="visibility: hidden" multiple />

This in the main process:

const template = [
  {
    label: 'File',
    submenu: [
      {
        label: 'Open Files',
        click() {
          mainWindow.webContents.send('hidden-file-input-open')
        }
      }
    ]
  }
]
Menu.setApplicationMenu(Menu.buildFromTemplate(template))

And this in the renderer:

ipcRenderer.on('hidden-file-input-open', (e, args) => {
  document.getElementById("file__hidden").click() // this does not work

  // this does work
  const code = 'document.getElementById("file__hidden").click()'
  electron.webFrame.executeJavaScript(code, true)
})

The true in webFrame.executeJavaScript actually makes it work. It was suggested by @zcbenz in #6268. I hope you're not going to "fix" this possibility before there is a reasonable way to get instances of a File from dialog's showOpenDialog() 😉

I've cloned electron-quick-start and added all possible combinations of handling files in both main and renderer processes. It's at jakubzitny/electron-file-hack.

We're talking about this issue in electron Slack channel, please join if you have anything to say.

@jakubzitny
Copy link
Contributor Author

jakubzitny commented Aug 27, 2016

I just found out that this issue is related to #749.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants