Exposing these in the renderer didn't make sense as they weren't backed
by the same instance / value store. This API should be browser only
especially now that we have nativeTheme.themeSource. Exposing in
//common was a mistake from the beginning.
* docs: Add recent Electron version to security checklist
* Update docs/tutorial/security.md
Co-Authored-By: Mark Lee <malept@users.noreply.github.com>
* Update docs/tutorial/security.md
Co-Authored-By: Pedro Pontes <pepontes@microsoft.com>
* Update docs/tutorial/security.md
Co-Authored-By: Mark Lee <malept@users.noreply.github.com>
* feat: add nativeTheme.shouldUseDarkColorsOverride to allow apps to override Chromiums theme choice
* spec: add tests for shouldUseDarkColorsOverride
* chore: add missing forward declarations
* refactor: rename overrideShouldUseDarkColors to themeSource
* chore: only run appLevelAppearance specs on Mojave and up
* chore: update patch with more info and no define
* Update spec-main/api-native-theme-spec.ts
Co-Authored-By: Jeremy Apthorp <jeremya@chromium.org>
* Update api-native-theme-spec.ts
* Update api-native-theme-spec.ts
* Update api-native-theme-spec.ts
* test: tsify more WebContents specs
* getFocusedWebContents
* setDevToolsWebContents, isFocused, isCurrentlyAudible
* getWebPreferences, openDevTools
* before-input-event
* zoom-changed
* sendInputEvent
* insertCSS
* startDrag
* focus, getOSProcessId
* zoom api
* more closeAllWindows
* fix detached dev tools test
* fix zoom-changed test
* compare the correct kind of id 🤦♂️
* 'fix' openDevTools test to wait for multiple focus events
* fix tests? 🤞
* use request instead of blur to detect openExternal success
* try not timing out the keychain for testing
* use blur event on mac, sigh
* oh, right, still gotta open an actual url
I've asked #19775 because I was frustrated with how hard it was to find a way to fix (instead of hide) the CSP warning in Electron and I complained that even the official quick start guide wasn't compliant with the security checklist at https://electronjs.org/docs/tutorial/security. Someone helped me out with a CSP meta tag which I have later noticed is indeed mentioned in the checklist, too: https://electronjs.org/docs/tutorial/security#csp-meta-tag. I have not used the checklist one verbatim because it prevents a `script` tag from working when serving `index.html` through the `file:` protocol as the quick start does. I instead used the one the person in my issue recommended which seems to work well to me. I am not that well versed in CSP so there might be a better policy to include with the quick start, but this is what I've got for now.
Sometimes it's necessary to convey more information about the window to screen reader users only (simply putting everything to the window title might be unnecessarily noisy).
For example, Chromium uses that technique to tell screen reader users that the window is in incognito mode (the incognito window looks differently and doesn't have «incognito» in the title, but for blind users the screen reader will announce that it's incognito).
In the `dialog` documentation (and the generated typings in `electron.d.ts`), it is mentionned that the `icon` property only supports `NativeImage`, but the `nativeImage` documentation says that:
```
In Electron, for the APIs that take images, you can pass either file paths or NativeImage
```
* feat: Implement BrowserWindow.moveAbove(mediaSourceId)
BrowserWindow.{focus,blur,moveTop}() are not enough in some
situations. For example when implementing an overlay that
follows another window that can lose focus. In that case
it is useful to move the overlay above the tracked window.
sourceId is a string in the format of DesktopCapturerSource.id,
for example "window:1869:0".
Notes: Added BrowserWindow.moveAbove(mediaSourceId)
https://github.com/electron/electron/issues/18922
* feat: Implement BrowserWindow.getMediaSourceId
Return the Window id in the format of DesktopCapturerSource's id.
For example "window🔢0".
https://github.com/electron/electron/issues/16460
Notes: Added BrowserWindow.getMediaSourceId
* feat: add new nativeTheme API
* chore: deprecate and clean up old systemPreferences theme APIs in favor of new nativeTheme module
* chore: clean up and deprecate things per feedback
* chore: add tests for deprecate and clean up invert impl
* build: when is a boolean not a boolean???
* docs: remove implicit 'any' and 'Object' types from the docs
* docs: more docs improvements, remove all remaining empty interfaces
* chore: update tests for better types
* restore stash
revert
some things work others dont
tracking area for rescue
manual popup
restore drag n drop
cleanup
* fix: make tray not block main process (#18880)
* fix: make tray not block main process
* make AtomMenuModel refcounted
* add support for ansi codes in title
add remove TODOs
* chore: use ScopedPumpMessagesInPrivateModes in tray (#18977)
* chore: use ScopedPumpMessagesInPrivateModes in tray
* revert refcounting of AtomMenuModel
* Prefer WeakPtr for posting tasks to handle unexpected destruction
* cleanup .h
* cleanup .mm
* add imports
add missing include
* fix: crash when tray popup called twice (#18999)
* remove highlightMode and TODOs
* remove unnecessary copy
The `event` type and keyword is reserved by the typescript generator, in the future we should throw an error from the generator if someone uses a reserved interface like that.
This also splits and documents the InputEvent type way better so that TS
users get strong type safety.
Fixeselectron/typescript-definitions#36
Closes#11371.
Previously, we didn't consider the return value of the webRequest URLPattern mate converter, which meant that when the pattern wasn't correctly parsed owing to invalid filter specification users would not be made aware of that fact and would just think that the filtering itself had failed. This corrects that error by moving the business logic of url pattern parsing out of the converter and into the function itself so that granular and specific errors can be thrown.
There's also no real reason that i'm aware of not to allow wider breadth of filters by letting users use a wildcard for effective TLD, so I also overrode that (default for the 1-arg Parse is not to allow that).
Finally, I added some examples of url filter types for users to reference.
4d8a055 (#19226) introduced incorrect instructions for 'opting out' of dark mode in Electron 7.0.0 and for enabling it on older versions. The boolean values for the `NSRequiresAquaSystemAppearance` key were inverted.
* test: move some BrowserWindow specs to the main process
* uncomment cross-site test
* move more tests
* re-enable, refactor and move visibilitychange specs
* move new-window event tests and re-enable them on mac
* move max/minimize event tests
* move modal tests
* move beginFrameSubscription tests
* move savePage test
* move BrowserWindow options argument is optional test
* move restore, unmaximize, fullscreen tests
* move parent window tests
* don't wait for show event on windows (#8664)
* add debugging logs to fullscreen tests
* more debugging on windows
* explicitly destroy browserviews to prevent crash during gc
* only await show on darwin
* more event timing fixes
* disable max/minimize event tests on linux, since they're broken on CI
Resolves#18805.
We want to keep default move conflict handling behavior in that it's still what most users would expect, but there exist edge cases in which users may not want to be forced into that behavior.
This thus introduces an optional conflict handler that allows developers access to more granular move actions. They could now allow the user to choose whether to delete an existing app in favor of the current one being moved, or whether to quit the current app and focus on the existing one should it both exist and be running. I added a fair amount of new documentation outlining this behavior, but if there are things users may benefit from seeing examples of or nuances that should be added please leave feedback!
This adds the NSRequiresAquaSystemAppearance key to our default Info.plist file which will tell macOS to auto-switch our effectiveAppearance in sync with the OS. The dark mode documentation has been updated to reflect how to opt *out* of this but it is also noted that certain dark mode APIs will not work on Catalina if you opt out.
Remind user the contents.executeJavaScript will not run their code immediately if the web page still in running. Without the knowledge, user would think their code not function properly and it's hard to debug because different page have different loading time.
According to [web-contents.js](731edbe2b6/lib/browser/api/web-contents.js (L199))
