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

feat: webContents.loadURL returns a promise #15855

Merged
merged 7 commits into from Dec 6, 2018

Conversation

Projects
None yet
3 participants
@nornagon
Contributor

nornagon commented Nov 27, 2018

Description of Change

Many tests use the following pattern to load a page in a WebContents and wait for the load to finish:

async () => {
  webContents.loadFile('path/to/page.html')
  await emittedOnce(webContents, 'did-finish-load')
  // ... do something with the page
}

This is an aesthetic improvement over the callback method of webContents.on('did-finish-load', ...), but is unfortunately flaky: it is sometimes possible that the 'did-finish-load' event is emitted before the listener is registered (see #15853 for example, which fixes the flaky test described in #15095). This is to do with the fact that the tests use the BrowserWindow module via the remote API, so there is a short window of time after loading the URL but before the event listener is registered. If the event is fired during that window, it will be lost, and the test times out.

It's possible to eliminate the additional emittedOnce helper call, clean up the code, and remove the possibility of flakiness by having loadURL return a promise. The above could would be written as follows with this patch:

async () => {
  await webContents.loadFile('path/to/page.html')
  // ... do something with the page
}

Checklist

  • PR description included and stakeholders cc'd
  • npm test passes
  • tests are changed or added
  • relevant documentation is changed or added
  • PR title follows semantic commit guidelines

Release Notes

Notes: webContents.loadURL and loadFile now return a promise

@nornagon nornagon requested review from ckerr and MarshallOfSound Nov 27, 2018

@nornagon nornagon requested review from electron/docs as code owners Nov 27, 2018

@nornagon nornagon referenced this pull request Nov 28, 2018

Merged

test: fix a bunch of flaky tests related to emittedOnce #15871

2 of 2 tasks complete

@nornagon nornagon force-pushed the loadurl-promise branch 2 times, most recently from 775952e to cfdca61 Nov 29, 2018

navigationStarted = true
}
}
const stopLoadingListener = () => {

This comment has been minimized.

@deepak1556

deepak1556 Nov 29, 2018

Member

We could instead use content::ChildProcessSecurityPolicy::CanRequestURL to determine if a navigation will happen and abort with did-fail-load on our end for these types of cases.

This comment has been minimized.

@nornagon

nornagon Nov 29, 2018

Contributor

I figured this would be a reasonable "catch-all", since I think did-stop-loading will be emitted regardless of what happens?

This comment has been minimized.

@nornagon

nornagon Nov 29, 2018

Contributor

but CanRequestURL might be a good extra check to give a more informative error

This comment has been minimized.

@deepak1556

deepak1556 Nov 29, 2018

Member

since I think did-stop-loading will be emitted regardless of what happens?

yup that is correct, its emitted whenever a document stops its resource loading be it failure or success. Having this check can simplify existing url validity check https://github.com/electron/electron/blob/master/atom/browser/api/atom_api_web_contents.cc#L1157

@nornagon nornagon force-pushed the loadurl-promise branch from cfdca61 to 886aefc Dec 3, 2018

@MarshallOfSound

Looks good from here

@nornagon nornagon merged commit 442c1b2 into master Dec 6, 2018

21 checks passed

Absolute Zero
Semantic Pull Request ready to be squashed
Details
WIP ready for review
Details
appveyor: win-ia32-debug AppVeyor build succeeded
Details
appveyor: win-ia32-testing AppVeyor build succeeded
Details
appveyor: win-ia32-testing-pr AppVeyor build succeeded
Details
appveyor: win-x64-debug AppVeyor build succeeded
Details
appveyor: win-x64-testing AppVeyor build succeeded
Details
appveyor: win-x64-testing-pr AppVeyor build succeeded
Details
ci/circleci: linux-arm-debug Your tests passed on CircleCI!
Details
ci/circleci: linux-arm-testing Your tests passed on CircleCI!
Details
ci/circleci: linux-arm64-debug Your tests passed on CircleCI!
Details
ci/circleci: linux-arm64-testing Your tests passed on CircleCI!
Details
ci/circleci: linux-checkout Your tests passed on CircleCI!
Details
ci/circleci: linux-ia32-debug Your tests passed on CircleCI!
Details
ci/circleci: linux-ia32-testing Your tests passed on CircleCI!
Details
ci/circleci: linux-ia32-testing-tests Your tests passed on CircleCI!
Details
ci/circleci: linux-x64-debug Your tests passed on CircleCI!
Details
ci/circleci: linux-x64-testing Your tests passed on CircleCI!
Details
ci/circleci: linux-x64-testing-tests Your tests passed on CircleCI!
Details
release-notes Release notes found
@release-clerk

This comment has been minimized.

release-clerk bot commented Dec 6, 2018

Release Notes Persisted

webContents.loadURL and loadFile now return a promise

@nornagon nornagon deleted the loadurl-promise branch Dec 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment