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]
In 6b266b7815, as I got rid of deprecated dep `wurl`, I wrote:
> This one may be problematic, as it used to do TLD stuff:
> https://github.com/websanova/node-url/blob/7982a613bc/wurl.js#L4
>
> So, the new WHATWG-URL-based implementation will consider
> `asana.com` to be "external" to `app.asana.com`, contrarily to before.
> Given the nature of Nativefier, I think it's actually what to expect,
> that in this case you're "out of the app", and in e.g. asana's landing
> page, which you'd expect to see in your browser.
Turns out it's even more problematic: @TheCleric notices in https://github.com/nativefier/nativefier/pull/1124#issuecomment-790279403
that this breaks app `https://evernote.com` doing its login in `www.evernote.com`
The present change fixes this, by behaving mostly similarly to before,
but without re-introducing `wurl` or another dep needing a TLD/SLD list.
- Docker builds for Windows are fixed (fixes #997)
- Switched over to use Alpine (as was indicated as desired in https://github.com/nativefier/nativefier/issues/375#issuecomment-304247033) - which may mean #375 is fixed as well.
- Fixed bug where Docker has the wrong line endings when copying from a Windows host
- Fixed the invalid `arm` arch to `armv7l`
- Add `npm t` to the docker build to ensure tests pass before we start trying to do builds
- Add a message to help the user when trying to build Mac apps on Windows as a non-Admin (currently an unhelpful exception)
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
This one may be problematic, as it used to do TLD stuff:
https://github.com/websanova/node-url/blob/7982a613bc/wurl.js#L4
So, the new WHATWG-URL-based implementation will consider
`asana.com` to be "external" to `app.asana.com`, contrarily to before.
Given the nature of Nativefier, I think it's actually what to expect,
that in this case your "out of the app", and in e.g. asana landing's page,
which you'd expect to see in your browser.
Let's see if users disagree with that.
We don't need a fancy _"portable (Windows/Linux/macOS) implementation
of Unix shell commands on top of the Node.js API"_, we just want to run
a simple script. Replacing with using stdlib `child_process.spawnSync`.
Thinking about it again, the user-friendlier `a.x` syntax has one disadvantage
over `^a.b.c`: it doesn't force deps upgrades when they upgrade Nativefier.
`a.x` is fine on initial install, but a user with an insecure dep
(e.g. axios 0.19.0) will _not_ get fixed axios 0.21.1 on upgrading Nativefier.
-> Come back to `a.x` everywhere.
Still not introducing package locks, they're too confusing to new devs.
See https://github.com/nativefier/nativefier/pull/1099#issuecomment-761250232
