Commit graph

22 commits

Author SHA1 Message Date
Milan Burda
aa2b2f7c8f fix: security: don't allow arbitrary methods to be invoked on webContents via IPC (#15919) 2018-12-04 16:12:21 +01:00
Cheng Zhao
ca7dec2082 fix: default prop of location should be empty str 2018-12-04 17:11:26 +09:00
Cheng Zhao
fc4e10b6c0 fix: set setter of window.location 2018-12-04 16:23:52 +09:00
Anrock
e80e3a53e9 feat: introduce LocationProxy for BrowserWindowProxy 2018-12-04 16:23:52 +09:00
Samuel Attard
176a76217c
chore: have 'use strict' consistently across our lib files (#14721) 2018-09-23 00:28:50 +12:00
Samuel Attard
558fff69e7
chore: update to standard 12 2018-09-14 14:57:01 +10:00
Samuel Attard
795447f61a Implement dialog (alert/confirm) blocking as a user switch after the first dialog
* This is to enable more browser-like behavior so that users who run third-party code
  will not be DOS'ed with alerts and confirms.  This is already handled like this
  in most major browsers so this will greatly help these developers
2018-03-06 11:19:15 +09:00
Kevin Sawicki
553021bc9c Only assign opener when not using nativeWindowOpen 2017-07-17 11:55:15 -07:00
Birunthan Mohanathas
7d2226e05e Let Chromium manage document.visibilityState and document.hidden
Chromium already includes the necessary plumbing to manage the
visibility properties and `visibilitychange` event so this gets rid of
most of our custom logic for `BrowserWindow` and `BrowserView`.

Note that `webview` remains unchanged and is still affected by the issues
listed below.

User facing changes:

- The `document` visibility properties and `visibilitychange` event are
  now also updated/fired in response to occlusion changes on macOS. In
  other words, `document.visibilityState` will now be `hidden` on macOS
  if the window is occluded by another window.

- Previously, `visibilitychange` was also fired by *both* Electron and
  Chromium in some cases (e.g. when hiding the window). Now it is only
  fired by Chromium so you no longer get duplicate events.

- The visiblity state of `BrowserWindow`s created with `{ show: false }`
  is now initially `visible` until the window is shown and hidden.

- The visibility state of `BrowserWindow`s with `backgroundThrottling`
  disabled is now permanently `visible`.

This should also fix #6860 (but not for `webview`).
2017-06-06 15:16:01 -07:00
Ryohei Ikegami
1d73e84a29 Merge branch 'master' into native-window-open 2017-04-27 12:03:55 +09:00
Kevin Sawicki
95ef422ab4 Coerce offset to number in renderer process 2017-04-26 12:37:16 -07:00
Kevin Sawicki
2c48300daa Fix typos in comment 2017-04-26 09:09:42 -07:00
Kevin Sawicki
246937a372 Convert targetOrigin to string in render process 2017-04-26 09:08:47 -07:00
Kevin Sawicki
3894c1c625 Convert frameName/features to strings in render process 2017-04-26 09:08:47 -07:00
Kevin Sawicki
c90fd4dc88 Convert message/title to strings in render process 2017-04-24 09:15:01 -07:00
Ryohei Ikegami
a1f9a45276 Use native window.open implementation 2017-03-19 17:41:20 +09:00
Kevin Sawicki
6bcfd0630c Document implemented APIs at the top 2017-01-16 12:38:16 -08:00
Kevin Sawicki
fbcbfbda6a Add back BrowserWindowProxy location property 2017-01-16 12:38:16 -08:00
Kevin Sawicki
f3852c57fc Use empty string for comparison 2017-01-16 12:38:16 -08:00
Kevin Sawicki
2e6d08c652 Remove unneeded this prefix 2017-01-16 12:38:16 -08:00
Kevin Sawicki
bb260343de Move more functions to outer scope 2017-01-16 12:38:16 -08:00
Kevin Sawicki
3f7b3c4bd7 Implement window overrides in main context 2017-01-16 12:38:16 -08:00