Generate markdown inside docs/appActions.md from actions/appActions JSDoc.
Adding an npm command for this called "docs" I think would be good.

Default behavior on Safari, Chrome and Firefox is to open in a new window

related electron/electron#645

Other browsers open a new window if new tab is selected with no open windows

I wanted to open the discussion to see if it would be a good idea to store application state inside the top level process. I'm thinking it would be better but I'm a little bit concerned about a perf hit. I think it would be OK though.

Right now each browser window maintains its own appState. This issue is posted to discuss changing that.

appState would change to be at a top level a collection of browsers. Each would contain a collection of frames and pretty much everything that is there now.

It would also enable cross frame state like pinned sites to exist more easily.

Some of the main changes that would be needed:

• The dispatcher would be changed to do IPC.
• components could no longer access the read only view it has of appStore, and would work only off of passed up data.

CC @diracdeltas @bridiver @aekeus

Login to Feedly.com using google never actually logs me in. I can access mail.google.com after the authentication through the feedly sign-on page, but I can't access Feedly itself. I haven't tried other sites that use google login

1. open brave.com
2. open a new tab and close it
3. type google.com into the url bar for the original tab, press enter. the url bar is not updated during redirects and the autosuggest bar lingers.

Steps to reproduce:

1. Create 10 tabs

(node) warning: possible EventEmitter memory leak detected. 11 crashed listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at EventEmitter.addListener (events.js:239:17)
    at EventEmitter.once (events.js:265:8)
    at createGuest (/Users/bjohnson/Documents/brave/browser-electron/node_modules/electron-prebuilt/dist/Electron.app/Contents/Resources/atom.asar/browser/lib/guest-view-manager.js:51:16)
    at EventEmitter.<anonymous> (/Users/bjohnson/Documents/brave/browser-electron/node_modules/electron-prebuilt/dist/Electron.app/Contents/Resources/atom.asar/browser/lib/guest-view-manager.js:167:66)
    at emitThree (events.js:97:13)
    at EventEmitter.emit (events.js:175:7)
    at EventEmitter.<anonymous> (/Users/bjohnson/Documents/brave/browser-electron/node_modules/electron-prebuilt/dist/Electron.app/Contents/Resources/atom.asar/browser/api/lib/web-contents.js:91:27)
    at emitTwo (events.js:87:13)
    at EventEmitter.emit (events.js:172:7)

We have some:
this.webview.addEventListener in frame.js

We could remove those as well when the component unmounts. Not sure if this is required but @diracdeltas mentioned she sees some messages still about leaked events when there are a lot of tabs.

Steps to reproduce:

1. Enter google.com in the address bar, hit return and let the page load
2. Re-type google.com in the address bar and hit return again
3. Page does not refresh

On all other browsers this triggers a refresh of the page

Probably some state change causing the webview to be re-rendered.

The next-tab arrow button in the tab bar looks fine when the last tab is active:

but it looks weird (no gradient) when another tab is active:

Some app state will grow over time and is not practical to update on every dispatch request. One way to handle it would be to update it through the actions/dispatcher, but only keep a timestamp/version number in the state itself

sites: version,
bookmarks: version

Each window can detect when its version is out-of-date and load the most recent version from async storage or similar

currently it just lingers until some event happens (tab switch, navigation, focusing urlbar, etc.).

Steps to reproduce

1. Type google.com into the address bar
2. Wait for search bar panel to appear
3. Press return
   The search bar panel will stay open showing google

This is probably an electron level fix.

We often call several actions in a row that change state. This seems rather inefficient and we should be able to chain them together to update several values in a single dispatcher call

Check that we're using these babel / webpack optimizations:

"optimisation.react.constantElements",
"optimisation.react.inlineElements",

if the suggested link is the same as the current page, it won't reload the page, but the title and urlbar are still updated to the suggested link.

It does log me in, but the next page never appears, I clicked around a bit and ended up on the main twitter feed screen. So the form action is performing the login, just advancing to the main feed isn't working

I assume context menu actions aren't hooked up? I can research further if that isn't the case

The shield, reload, and star buttons seem to show the default cursor if you hover over the top half and the pointer cursor if you hover over the bottom half.

Steps to reproduce:

1. select the address bar
2. remove all text and hit return
   tries to load non-existent page

Desired behavior:
For a blank page do nothing
For a page with a url restore the url and select

FYI @bridiver since you've been working on this area

Local keyboard shortcuts don't work in a new window until focus switches to another window and then back to the new window. Keyboard shortcuts like Cmd-T for new tab work fine however.

Readme should have instructions for writing/running tests.

Currently it re-opens at the position before the active frame.

Steps to reproduce:

1. Open the browser with a new window
2. Use the reload menu item or shortcut

Reload should be disabled and have no effect if there is no content to reload

My main torrent search site, and IIRC one of the top 5 torrent search sites.
Using ABP plug in other browsers completely sanitizes the site.

Most browsers block non-user initiated popups by default (with some notification and an option to allow), but electron does not appear to provide a mechanism to tell the different in the new-window event.

Looks like it should be a pretty simple change. We can probably add something to:

  # Make new windows requested by links behave like "window.open"
  @webContents.on '-new-window', (event, url, frameName) ->
    options = show: true, width: 800, height: 600
    ipcMain.emit 'ATOM_SHELL_GUEST_WINDOW_MANAGER_WINDOW_OPEN', event, url, frameName, options

from atom/browser/api/lib/browser-window.coffee from electron assuming that covers both direct clicks on window.open initiated from onClick events (both are typically allowed by default)

Test plan

#6900 (comment)

Steps to reproduce:

1. Open Brave and maximize it
2. Keep creating tabs until you reach 6
3. Tabs will finally resize for the window

Not sure what the correct behavior should be here with a fixed number of tabs. Currently they only expand to fit the window size when there are 6 in the tab group. Maybe they should always fit the window width and get smaller until they max out at 6? @bradleyrichter ?

This makes it impossible to differentiate between window.open that should happen in a new window vs a new tab. Typically browsers will open in a new window if window.open "features" are provided

Steps to reproduce:

1. Start the Browser
2. Create a second window
3. Local shortcuts (urlbar focus, tab navigation, dev tools, etc...) don't work, but app shortcuts (new tab) do
4. Switch back to the first window
5. Switch back to the second window again
6. Local shortcuts now work on the second window

Steps to reproduce:

1. Enter google.com into the address bar and press return
2. type 'blah' into the address bar
3. press the escape key
4. text box loses focus, but text remains

Desired behavior:
escape should close the search bar panel if open, clear 'blah' and restore google.com, but keep focus and select

Reloading/stopping loads via the toolbar button doesn't work

Steps to reproduce

1. Enter google.com in the address bar and load
2. press cmd/ctrl-l or click in address bar
3. current text will not be selected

Behavior on other browsers is to select the text when activating the address bar with either method

Implement computedThemeColor based on a page's favicon color.
Also add computedThemeColor to state documentation.

After opening content dev tools, you can't use the local shortcut to close them again.
STR:

1. Command+Option+I to open dev tools
2. Command+Option+I to close dev tools

Expected results:
It closes even though the devtools window has focus

Actual results:
You need to focus back to the parent window first.

@bridiver maybe we need to register with localShortcut the devtools window?

When I open 10 or so tabs in the browser, I get this error repeatedly:

> [email protected] start /Users/yan/repos/browser-electron
> NODE_ENV=development electron . --debug=5858

(node) warning: possible EventEmitter memory leak detected. 11 crashed listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at EventEmitter.addListener (events.js:239:17)
    at EventEmitter.once (events.js:265:8)
    at createGuest (/Users/yan/repos/browser-electron/node_modules/electron-prebuilt/dist/Electron.app/Contents/Resources/atom.asar/browser/lib/guest-view-manager.js:51:16)
    at EventEmitter.<anonymous> (/Users/yan/repos/browser-electron/node_modules/electron-prebuilt/dist/Electron.app/Contents/Resources/atom.asar/browser/lib/guest-view-manager.js:167:66)
    at emitThree (events.js:97:13)
    at EventEmitter.emit (events.js:175:7)
    at EventEmitter.<anonymous> (/Users/yan/repos/browser-electron/node_modules/electron-prebuilt/dist/Electron.app/Contents/Resources/atom.asar/browser/api/lib/web-contents.js:85:27)
    at emitTwo (events.js:87:13)
    at EventEmitter.emit (events.js:172:7)

Steps to replicate:

1. Open two tabs with google.com
2. Type some random text in the address bar for one them
3. Switch to the other tab
4. text will remain in address bar

Behavior in Safari, Chrome and Firefox:

• Switch to the other tab => updates address bar with tab url
• Switch back => random text is preserved

Test plan

1. Visit https://www.w3schools.com/js/tryit.asp?filename=tryjs_prompt
2. Click the Try it button on the right hand side
3. Confirm prompt is shown; text should be selected
4. Type Brave and click OK
5. Confirm Hello Brave! How are you today? is shown
6. Repeat steps 2 - 5, except press enter to submit instead of clicking OK
7. Click the Try it button on the right hand side
8. Click Cancel button
9. Confirm User cancelled the prompt. is shown
10. Repeat steps 8 and 9 except press escape instead of clicking Cancel

Original issue description

We can patch here:
https://github.com/atom/electron/blob/c4931bb2d12f5905cdf434ed6ff1a755ccad053f/atom/renderer/lib/override.coffee#L92

window.prompt

https://itunes.apple.com/us/app/patient-io/id825109942?mt=8 displays correctly on other browsers, but the images are blocked on Brave

If we go MPL2 we should have the header on each file unfortunately.
Asked Brendan for a decision on which license we want.

Electron's local shortcut package doesn't work properly when a new window is open. Menu shortcuts do work properly. You can fix them by unfocusing the new window and then refocusing it. First found by Yan. Fix is possibly in electron's local shortcut package.

The installation routine on Windows 10 shows a number of error dialogs during installation. They seem to relate to a missing Lodash package.

The browser operates as expected.