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.
