| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
We can't do this in the renderer package, because we need to import MUI
files that are not exported (MUI v6 is not ESM yet).
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
| |
Use explicit prop threading to pass the MainStore to components, which
makes the data dependencies more explicit and enables better
testability.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We render the location bar and notification banners separately for each
service and keep track of the BrowserView size separately for each
service to reduce the tearing that appears when people switch services.
The tearing cannot be eliminated completely, because it comes from the
separation between the main and renderer processes. But we can at least
try and reduce the IPC round-tripping and layout calculations required
to accurately position the services.
This approach has an overhead compared to the single
BrowserViewPlaceholder approach, because the renderer process has to
layout the location bar and notification for all services, not only the
selected one. The number of IPC messages during windows resize is also
increased. To compensate, we increase the throttle interval for resize
IPC messages and let electron itself resize the BrowserView between IPC
updates. (We must still keep pumping IPC messages during window resize,
because, e.g., changes in notification banner size due to re-layouting
will still affect the required BrowserView size).
If further reduction of IPC traffic is needed, we could implement
batching for resize IPC messages and more intelligent throttling via a
token bucker mechanism.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The location bar should be visible on error page to let people see and
change the URL if needed.
Additionally, it must be visible on insecure connections to show people
that the connection if not secure.
In the future, the location bar should also be shown if the loaded
website is uncommon in the context of the current service, i.e., it is
not explcitly allowlisted by the recipe.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
| |
Add react-i18n to make us able to use i18next translations in the
renderer process just like we do in the main process.
Translations are hot-reloaded automatically.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a "failed" state for services where the BrowserView and WebContents
should be left around to keep history and allow people to navigate back.
Access to the browser history otherwise doesn't seem possible
(see https://github.com/electron/electron/issues/26727
and https://github.com/electron/electron/issues/7186),
so destroying BrowserView and managing our own history is not possible.
Also keep https://github.com/electron/electron/issues/24113 in mind.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows customization of stores both in the renderer and in the main
process. Instead of exposing a basic model type from the shared module
(which was be overwritted with more specific props in the main package),
we expose factory function that can create specific model types in
both the renderer and the main process.
Using these package-specific customization to stores, the renderer
package can attach IPC calls directly to store objects, which the main
package can attach the handlers for IPC calls and other internal
actions.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
| |
InputBase paddings are idiosyncratic if there is both a start and an end
adornment. To simplify the styles, we override the styling from InputBase
and compute our own paddings.
The animated color change when switching from a secure site to an
insecure one was distracting, so we disable color animations in the
location bar.
|
|
Still needs adding event handlers to actually navigate the browser.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|