This patch introduces IPC::Connection which becomes the new base class
of ClientConnection and ServerConnection. Most of the functionality
has been hoisted up to the base class since almost all of it is useful
on both sides.
This gives us the ability to send synchronous messages in both
directions, which is needed for the WebContent server process.
Unlike other servers, WebContent does not mind blocking on a response
from its client.
When invalidating the frame we need to properly flag that so that
we trigger rendering the frame, even if "all" was flagged as being
invalidated. Otherwise it will only get rendered if anything else
happens to trigger it (such as focus change).
Fixes#3427
Do not fill the backing store mismatch area with the solid window
color if the window is transparent. This caused some minor flicker
when such a window is e.g. snapped to the left/right or maximized.
A malicious caller of set_params could have caused the ifr_name field to
lack NUL-termination. I don't think this was an actual problem, though, as
the Kernel always forces NUL-termination by overwriting ifr_name's last byte
with NUL.
However, it feels better to do it properly.
No behaviour change (probably).
A malicious caller can create a SocketAddress for a local unix socket with an
over-long name that does not fit into struct sock_addr_un.
- Socket::connet: This caused the 'sun_path' field to
overflow, probably overwriting the return pointer of the call frame, and thus
crashing the process (in the best case).
- SocketAddress::to_sockaddr_un: This triggered a RELEASE_ASSERT, and thus
crashing the process.
Both have been fixed to return a nice error code instead of crashing.
When a resize_aspect_ratio is specified, and window will only be resized
to a multiple of that ratio. When resize_aspect_ratio is set, windows
cannot be tiled.
We need to clip painting to the actual size to prevent corrupting
the area outside of the applet as the backing store is not
guaranteed to be perfectly in sync.
Fixes#3107
We need to update all button rectangles when the layout changed.
We also need to clear the taskbar button rectangle when we
remove a modal window button, so that WindowServer uses the
parent's taskbar button rectangle for the minimize animation.
If a modal window is being minimized, it may not have its own
taskbar rectangle. In that case, try finding a parent in the
modal window stack that does have one, and use that for the
animation.
Rather than blitting and rendering each window every time, only
render what actually changed. And while doing so, only render
the portions that are visible on the screen. This avoids flickering
because flipping framebuffers isn't always perfectly in sync with
the code, so it's possible that the flip happens slightly delayed
and we can briefly see the next iteration having partially completed.
Also, avoid touching the mouse cursor unless it is in an area that
needs updating. This reduces flickering unless it is over an area
that is updated often. And because we no longer render the entire
screen, we'll save the contents below the cursor so that we can
hide it before touching that area.
Fixes#2981
Various applications were using the same slightly verbose code to center
themselves on the screen/desktop:
Gfx::IntRect window_rect { 0, 0, width, height };
window_rect.center_within(GUI::Desktop::the().rect());
window->set_rect(window_rect);
Which now becomes:
window->resize(width, height);
window->center_on_screen();
This finally makes tooltips on menu applets the same as everywhere else!
Here's what went wrong:
WindowManager::process_mouse_event() receives a Window*&, determines the
hovered window and sets it accordingly. However there's a branch that
tests for menubar_rect().contains(event.position()) and returns early -
which resulted in hovered_window never being set to any MenuApplet
window, even hovered ones.
The hovered_window result is being used in WindowManager::event() and
passed to WindowManager::set_hovered_window(), which is responsible for
creating WindowLeft and WindowEntered events when the hovered window
changes, as a result of the mentioned chain of events this also never
happens for MenuApplet windows.
The WindowLeft event would the cause Window::handle_left_event() in
LibGUI to be called, which unsets the window's hovered widget, which
is necessary for the widget to receive a subsequent Enter event -
again, all of this never happened.
Now it's working as expected though, so we can start using tooltips on
menu applets :^)
In the case of an ongoing window drag/move/resize action
WindowManager::process_mouse_event() would return early, even before
delivering mouse events to windows with global cursor tracking enabled.
They would only continue to receive new mouse events once those actions
were completed.
Fixes#3116.
When maximizing a window that is blocked by a modal window, only
maximize the top window in the stack. However, if the stack is
minimized, restore all of them in addition.
Fixes#3074
This patch introduces the ClassicWindowTheme, which is our default
theme implemented as a Gfx::WindowTheme subclass.
In this initial cut, we move normal window frame painting and title
bar metrics helpers out of WindowServer and into LibGfx.
This will eventually allow us much greater flexibility with theming
windows, and also makes it easier to build applications that want to
render a window with a specific style for some reason. :^)
When clicking on a window's frame that is blocked by a modal
window, we want to bring the entire window stack to the front
regardless of where the user clicked in the frame (not just the
icon).
Change #2811 made window title stripes and window title shadow themable,
but it used the same stripe and shadow color for all window modes.
This is fine for the new 'basalt' theme which uses the same color
in all four window modes, but it changed the default theme so that
background windows had brown stripes and a brown shadow.
Instead, make the title stripe and title shadow themable per window mode,
and change the default theme to restore the colors it had before
change #2811: The title stripe color is the same as Border1 for all
window modes, and the title shadow is the same as the title stripe
darkened by 0.6.
This prevents windows from being opened directly on top of eachother,
and provides default behavior for when window position is not specified.
The new behavior is as follows:
- Windows that have been created without a set position are assigned one
by WindowServer.
- The assigned position is either offset from the last window that is
still in an assigned position, or a default position if no such window
is available.
Custom buttons can now be set using TitleButtonIcons under the
Paths group in themes. WindowFrame recognizes window-close.png,
window-minimize.png, window-maximize.png and window-restore.png
filenames.
I was a bit confused by the fact that a method named `build_system_menu()`
first enumerates a directory. Moving the app/category discovery to a dedicated
function that returns the GUI-relevant information makes this process a bit
less surprising.
As an added bonus, `g_app_category_menus` was actually only a temporary mapping,
and didn't need to be global. In theory, SystemMenu should use a handful fewer
of bytes now.
Use Core::guess_mime_type_based_on_filename() for this. It's obviously
not perfect, but it works better than just sending "text/html" for
everything no matter what. :^)
With this, System Monitor has "System Monitor" instead of
"SystemMonitor" as tooltip, matching the app's title bar
and menu bar title.
Same for File Manager and Text Editor.
If we add "(Not responding)" to the title of an unresponsive window,
the title rect needs to be wider or we'll have text-on-stripes.
Thanks to @SharpOB for reporting this bug!
The theming system can now control title bar height, title button
size, title stripe color and the title text shadow color.
The implemented theme metrics system could be later extended to LibGUI
to allow themes to change widget padding, border width, etc.
When walking the modal window stack upwards, we need to check if
the top modal window is still a descendant of the window that
the parent is blocked by. Fixes not all windows being brought to
the front when trying to active a parent in the middle of the
modal window stack.
* The parent information is necessary by the Taskbar to be able to
determine a modal window's parent
* Minimize and maximize modal window stacks together
This fixes a few problems with modal windows:
* If any child window, or any child window further down the
tree is considered modal, then all windows in that chain
are modal.
* When trying to activate a window blocked by a modal child
bring the entire stack of modal windows to the front and
activate the modal window.
* A window is modal if it has a parent and it's flagged as
modal, regardless of whether the ClientConnection has
created modal windows.
This technically supports diverging modal window trees as well,
where two modal windows share the same parent, allowing both to
be activated (including for input) but not the parent. And it
should also support modal window stacks of arbitrary depth.
This solves a problem where windows don't receive a WindowInputLeft
event when popup menus are opened. This prevented ComboBox being
closed when right clicking the application on the task bar.
Accessory windows are windows that, when activated, will activate
their parent and bring all other accessory windows of that parent
to the front of the window stack. Accessory windows can only be
active input windows. The accessory window's parent is always the
active window regardless of whether it is also the active input
window.
In order to route input correctly, input is now sent to the active
input window, which can be any accessory window or their parent,
or any regular window.
By adding a special LauncherType::Application we can still
get meta data for the application, but also know that we should
consider executing that binary as the default action. LaunchServer
will not do this for us, as it should probably not be allowed to
run arbitrary binaries that haven't been registered as handlers.
This allows marking a MenuItem as a default action, e.g. in a
context menu for an action that reflects what e.g. a double click
would perform.
Also enhance the window menu to mark the close action as the
default, and when double clicked perform that action.
Fixes#1289
This commit makes the WebServer accept a base path to serve.
This makes taking files out of the system significantly more simple
(depending on whom you ask).
I saw this assertion fire once and I don't know how I made it happen,
but it seems fine for client-less windows to become active, they just
don't have a menubar to install.
Everyone who connects to ProtocolServer now gets his own instance.
This means that different users can no longer talk to the same exact
ProtocolServer process, enhanching security and stability.
Instead of painting synchronously whenever a Paint request comes in,
the WebContent process will now buffer pending paints and coalesce
them and defer the actual paint using a zero-timer.
This significantly reduces flickering already, without doing any
double-buffering in the WebContentView widget.
The WebContentView widget now inherits from GUI::ScrollableWidget and
will pass its scroll offset over to the WebContent process as it's
changing. This is not super efficient and can get a bit laggy, but it
will do fine as an initial scrolling implementation.
Just like the single-process Web::PageView widget, WebContentView also
paints scrolled content by translating the Gfx::Painter.
fixes#2575
The extra ResizeEvent would be handled after on_rect_change, and would
reset the size of main_widget to what it was before the resize.
Bonus: Less unnecessary events.
The new ImageDecoder service (available for members of "image" via
/tmp/portal/image) allows you to decode images in a separate process.
This will allow programs to confidently load untrusted images, since
the bulk of the security concerns are sandboxed to a separate process.
The only API right now is a synchronous IPC DecodeImage() call that
takes a shbuf with encoded image data and returns a shared buffer and
metadata for the decoded image.
It also comes with a very simple library for interfacing with the
ImageDecoder service: LibImageDecoderClient. The name is a bit of a
mouthful but I guess we can rename it later if we think of something
nicer to call it.
There's obviously a bit of overhead to spawning a separate process
for every image decode, so this is mostly only appropriate for
untrusted images (e.g stuff downloaded from the web) and not necessary
for trusted local images (e.g stuff in /res)
Port the WebContent service to the new MultiInstance mechanism that
Sergey added. This means that every new WebContentView gets its very
own segregated WebContent process.
"Paint" matches what we call this in the rest of the system. Let's not
confuse things by mixing paint/render/draw all the time. I'm guilty of
this in more places..
Also rename RenderingContext => PaintContext.
CSS defines a very specific paint order. This patch starts steering us
towards respecting that by introducing the PaintPhase enum with values:
- Background
- Border
- Foreground
- Overlay (internal overlays used by inspector)
Basically, to get the right visual result, we have to render the page
multiple times, going one phase at a time.
After layout, we may want to repaint the page, so we now listen for the
PageClient::page_did_invalidate() notification and use it to drive a
client-side repaint.
Note that an invalidation request from LibWeb makes a full roundtrip
to the WebContent client and back since the client drives painting.
The "WebContent" service provides a very restricted instance of LibWeb
running as an unprivileged user account. This will be used to implement
process separation in Browser, among other things.
This first cut of the service only spawns a single WebContent process
when someone connects to /tmp/portal/webcontent. We will soon switch
this over to spawning a new process for each connection.
Since this feature is very immature, we'll be bringing it up inside of
Demos/WebView as a separate demo program. Eventually this will become
a reusable widget that anyone can embed and easily get out-of-process
web content in their GUI.
This is pretty, pretty cool! :^)
We were getting a little overly memey in some places, so let's scale
things back to business-casual.
Informal language is fine in comments, commits and debug logs,
but let's keep the runtime nice and presentable. :^)
Clients now receive HTTP status codes like 200, 404, etc.
Note that a 404 with content is still considered a "successful"
download from ProtocolServer's perspective. It's up to the client
to interpret the status code.
I'm not sure if this is the best API, but it'll work for now.
Instead of always running the responsiveness timer for IPC clients,
we now only start it after sending a message. This avoids waking up
otherwise idle clients to do ping/pong busywork.
- Parsing invalid JSON no longer asserts
Instead of asserting when coming across malformed JSON,
JsonParser::parse now returns an Optional<JsonValue>.
- Disallow trailing commas in JSON objects and arrays
- No longer parse 'undefined', as that is a purely JS thing
- No longer allow non-whitespace after anything consumed by the initial
parse() call. Examples of things that were valid and no longer are:
- undefineddfz
- {"foo": 1}abcd
- [1,2,3]4
- JsonObject.for_each_member now iterates in original insertion order
IPC::ClientConnection now tracks the time since the last time we got
a message from the client and calls a virtual function on itself after
3 seconds: may_have_become_unresponsive().
Subclasses of ClientConnection can then react to this if they like.
We use this mechanism in WindowServer to send out a friendly Ping
message to the client. If he doesn't Pong within 1 second, we mark
the client as "unresponsive" and recompose all of his windows with
a darkened appearance and amended title until he Pongs us.
This is a little on the aggressive side and we should figure out a way
to wake up less often. Perhaps this could only be done to windows the
user is currently interacting with, for example.
Anyways, this is pretty cool! :^)
You can now ask SystemServer to not only listen for connections on the socket,
but to actually accept them, and to spawn an instance of the service for each
client connection. In this case, it's the accepted, not listening, socket that
the service processes will receive using socket takeover.
This mode obviously requires the service to be a multi-instance service.
For this kind of services, there's no single PID of a running instance;
there may be multiple, or no instances of the service running at any time.
No keepalive functionality is available in this mode, since "alive" doesn't
make sense for multi-instance services.
At the moment, there's no way to actually create multiple instances of
a service; this is going to be added in the next commit.
If a window in the taskbar has progress, we'll now draw that progress
in the form of a progress bar behind the window title on the taskbar
button for the window.
Each window now has an associated progress integer that can be updated
via the SetWindowProgress IPC call.
This can be used by clients to indicate the progress of ongoing tasks.
Any number in the range 0 through 100 indicate a progress percentage.
Any other number means "no progress"
