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

webContents‘s will-prevent-unload event is helpless for true use #24994

Open
xland opened this issue Aug 17, 2020 · 9 comments
Open

webContents‘s will-prevent-unload event is helpless for true use #24994

xland opened this issue Aug 17, 2020 · 9 comments

Comments

@xland
Copy link
Contributor

@xland xland commented Aug 17, 2020

When developers use webContents‘s will-prevent-unload event,
They want to ask the user to confirm something most of the time.
Like this:

win.webContents.on('will-prevent-unload', event => {
    let choice = dialog.showMessageBoxSync({
      title:'do you want to close',
      buttons:['cancel','yes']
    });
    if(choice === 1)  event.preventDefault();
    //...
  })

Actually,They can not use dialog.showMessageBoxSync,
because dialog.showMessageBoxSync is synchronous,
It will block the main process event loop, and cause some unpredictable problems.

But They can not use the asynchronous method dialog.showMessageBox either,
because dialog.showMessageBox can not prevent the will-prevent-unload event
Code:

  win.webContents.on('will-prevent-unload', async event => {
    let choice = await dialog.showMessageBox({
      title:'do you want to close',
      buttons:['cancel','yes']
    });
    if(choice === 1) event.preventDefault();  //this code is useless
    //...
  })
@zcbenz
Copy link
Member

@zcbenz zcbenz commented Aug 19, 2020

I agree the API design is wrong. We should provide a callback to pass the result asynchronously.

@SimplyAhmazing
Copy link

@SimplyAhmazing SimplyAhmazing commented Aug 24, 2020

@zcbenz I'm new to contributing to Electron, so I'd like to work on this

@aboutdevz
Copy link

@aboutdevz aboutdevz commented Aug 25, 2020

good

@ashikvarma11
Copy link

@ashikvarma11 ashikvarma11 commented Sep 29, 2020

@zcbenz @SimplyAhmazing Is anybody working on this issue now? If not, I would like to try this.

@SimplyAhmazing
Copy link

@SimplyAhmazing SimplyAhmazing commented Sep 29, 2020

@ashikvarma11 I attempted to work on this issue but got stuck as I don't have Electron development experience and couldn't figure out an existing pattern to model a solution for this. Feel free to take it. I'd also be happy to pair with you on it if you know how to do it and can impart some knowledge.

@adilanchian
Copy link

@adilanchian adilanchian commented Oct 2, 2020

Taking a look at this issue, I have some thoughts:

I agree the API design is wrong. We should provide a callback to pass the result asynchronously.

Digging through the code I do see that showMessageBox is defined as follows

void ShowMessageBox(const MessageBoxSettings& settings,
                    MessageBoxCallback callback)

It looks as though there is already a callback in this method that can be passed in that looks like this:

typedef base::OnceCallback<void(int code, bool checkbox_checked)>
    MessageBoxCallback;

With this information, I'm not actually sure what the full ask is here. Any insight on this would be awesome! Thanks in advance :)

@imrahul361
Copy link

@imrahul361 imrahul361 commented Oct 3, 2020

@SimplyAhmazing If anyone has not taken this issue. I like to know how to do it. Please help

@nicktz1408
Copy link

@nicktz1408 nicktz1408 commented Jan 16, 2021

Hello, what's the status of this? Is anyone working on it? I would love to give a helping hand!

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

Successfully merging a pull request may close this issue.

None yet
9 participants