When a new child window is spawned (such as for a Google login popup), those child windows were not receiving the mainWindow's properties. Chiefly among this was the userAgent which caused a bug in #831
* Add ability to inject multiple css/js files
* API doc: Move misplaced macOS shortcuts doc (PR #1158)
When I added this documentation originally, I guess I placed it in the wrong location.
* README: use quotes in example, to divert users from shell globbing pitfalls
Follow-up of https://github.com/nativefier/nativefier/issues/1159#issuecomment-827184112
* Support opening URLs passed as arg to Nativefied application (fix #405) (PR #1154)
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
* macOS: Fix crash when using --tray (fix #527), and invisible icon (fix #942, fix #668) (#1156)
This fixes:
1. A startup crash on macOS when using the `--tray` option; see #527.
![image](https://user-images.githubusercontent.com/22625791/115987741-99544600-a5b6-11eb-866a-dadb5640eecb.png)
2. Invisible tray icon on macOS; see #942 and #668.
![image](https://user-images.githubusercontent.com/22625791/115988276-24364000-a5b9-11eb-80c3-561a8a646754.png)
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
* API.md / --widevine: document signing apps to make some sites like HBO Max & Udemy work (fix #1147)
* Prompt to confirm when page is attempting to prevent unload (#1163)
Should alleviate part of the issue in #1151
* Add an option to upgrade an existing app (fix #1131) (PR #1138)
This adds a `--upgrade` option to upgrade-in-place an old app, re-using its options it can.
Should help fix #1131
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
* Bump to Electron 12.0.5 with Chrome 89.0.4389.128
* Add newly discovered Google internal login page (#1167)
* Fix Widevine by properly listening to widevine-... events, and update docs (fix #1153) (PR #1164)
As documented in #1153, for Widevine support to work properly, we need to listen for the Widevine ready event, and as well for certain sites the app must be signed.
This PR adds the events, and as well adds better documentation on the signing limitation.
This may also help resolve #1147
* Improve suffix creation + tests
* API: clarif in existing doc by the way
* Typo
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
Co-authored-by: Ben Curtis <github@nosolutions.com>
Co-authored-by: Fabian Wolf <22625791+fabiwlf@users.noreply.github.com>
Per #1112, I'm adding some common troubleshooting steps to the README. As well, this adds a checkbox requesting users to check this section before submitting a ticket, which will hopefully lead to more self-help.
As documented in #1153, for Widevine support to work properly, we need to listen for the Widevine ready event, and as well for certain sites the app must be signed.
This PR adds the events, and as well adds better documentation on the signing limitation.
This may also help resolve #1147
This adds a `--upgrade` option to upgrade-in-place an old app, re-using its options it can.
Should help fix #1131
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
This PR adds an optional, customizable menu of predefined bookmarks. In addition to containing a list of bookmarks, this file customizes the name of the menu and (optionally) allows assigning keyboard shortcuts to bookmarks. It adds a new command-line flag, `--bookmarks-menu <string>`, which can be set as the path to a JSON file containing configuration for the bookmarks menu.
Example of such a JSON file:
```json
{
"menuLabel": "Music",
"bookmarks": [
{
"title": "lofi.cafe",
"url": "https://lofi.cafe/",
"type": "link",
"shortcut": "Cmd+1"
},
{
"title": "beats to relax/study to",
"url": "https://www.youtube.com/watch?v=5qap5aO4i9A",
"type": "link",
"shortcut": "Cmd+2"
},
{
"type": "separator"
},
{
"title": "RÜFÜS DU SOL Live from Joshua Tree",
"type": "link",
"url": "https://www.youtube.com/watch?v=Zy4KtD98S2c"
}
]
}
```
## Checks
- [x] `npm run ci` passes
## Notes
Compared to the fork linked in #1065, this PR:
- adds no dependencies
- doesn't currently support submenus (this should be easy enough to add, but I didn't need it)
## Screenshot
<img width="853" alt="screenshot" src="https://user-images.githubusercontent.com/102904/115882015-5493a800-a41a-11eb-85ef-a190f3dbfe76.png">
I have 2FA (FIDO/Yubikey) set up for GitHub, and the session login was redirecting to my browser. Looking at the redirect path, it appears that github.com/session is involved, so adding that to internal login details.
With this patched, I'm able to login in to https://octobox.io/ in nativefier.
As discussed in #283 this PR will allow injected JS to do SOME interaction with the Electron session.
There is a full explanation of what this feature can, and cannot do, with examples in the api.md documentation.
This will provide a path for resolving many of our issues where users may "self-service" the solution by injecting JS that performs the task needed to meet their objectives.
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
See https://hub.docker.com/api/audit/v1/action/05620acd-9984-4e10-9053-3a7edc0c8558/ :
```
The command '/bin/sh -c npm link && npm test && rm -rf /tmp/nativefier* ~/.npm/_cacache ~/.cache/electron && chmod +x $NPM_PACKAGES/bin/nativefier' returned a non-zero code: 243
```
Culprit could be `rm -rf /tmp/nativefier*` : at this point /tmp/nativefier
doesn't exist, so `sh` cannot evaluate glob `/tmp/nativefier*`, and exits 1
See discussion at https://github.com/nativefier/nativefier/pull/1124#issuecomment-794751514 :
> @TheCleric I was about to merge this, then reconsidered one little thing (yes I wrote "little", I'm not reconsidering this whole thing 😅).
>
> I'm re-considering having the extra flag. I'm not so sure this will harm a lot of use cases. I'd like to 1. merge this PR, 2. immediately follow up with a small commit removing the flag & adjusting api.md, 3. release with the change well-documented / asking for feedback if this is problematic to anyone. (I'm not asking you any extra work, and like leaving an in-tree commit trace of considering the flag). If people complain with a valid reason, we'll restore the flag with a quick revert, else we're happy with one less flag and a reasonably-handled breaking change.
>
> Thoughts / objections?
Answered by:
> That seems reasonable to me.
>
> [discussion on an extra structured way to pass flags]