After moving to navigables, we started reusing the code that populates
session history entries with the srcdoc attribute value from iframes
in `Page::load_html()` for loading HTML.
This change addresses a crash in `determine_the_origin` which occurred
because this method expected the URL to be `about:srcdoc` if we also
provided HTML content (previously, it was the URL passed along with the
HTML content into `load_html()`).
The FIXME at the bottom of Timer.nativeRun was on the money, and was
the cause of some leaked timers. Solve the issue by passing the
EventLoopImplementation to the JVM Timer object and retrieving it's
thread_local timer list, and posting the events to the Impl rather than
trying to invoke the receiver's timer event callback directly in
the Timer thread. Because the implementation of
ALooperEventLoopManager::did_post_event() reaches for
EventLoop::current(), we also need to make sure that the timer thread
acutally *has* an EventLoop, even if we don't expect to use it for
anything. And we need to make sure to pump it to clear out any of the
poke() invocations sending 4 bytes to the wake pipe for that thread.
This function used to live in AndroidPlatform.cpp, but was removed
during the transition to the new app. We still need to extract the
assets from the tarball that CMake creates. At least, until we come
up with a generic "Resource" concept in LibCore.
Timers run in their own thread, to take advantage of existing Java
Executor features. By hooking into ALooper, we can spin the main
Activity's UI thread event loop without causing a fuss, or spinning the
CPU by just polling our event loop constantly.
This will let us spawn a new process for an Android Service to handle
all our WebContent needs. The ServiceConnection is manged by each
WebView. The lifecycle of the Service is not quite clear yet, but each
bindService call will get a unique Messenger that can be used to
transfer the WebContent side of the LibIPC socketpair we use in other
ports.
The simple smoke test makes sure that we can boot up an android emulator
with our package in it, and that the WebView is visible on boot.
More tests to come with more features :^)
This folder is gitignored because we copy a generated tar file to it
during the build so that the android build tools will add it to our
APK file. However, the gitkeep was not re-added when the folder moved.
This allows our WebViewImplementationNative class to paint into an
Android Bitmap class from the onDraw() view event. We also set the
viewport geometry from the view since we're setting the Kotlin Bitmap
at the same time.
This ports over the `LADYBIRD_USE_LLD` option from the standalone
Ladybird build and generalizes it to work for mold as well: the
`LAGOM_USE_LINKER` variable can be set to the desired name of the
linker. If it's empty, we default to trying LLD and Mold on ELF
platforms (in this order).
This template app from Android Studio should hopefully be more fun to
work on than the Qt wrapped application we were using before. :^)
It currently builds the native code using gradle rules, and has a stub
WebViewImplementationNative class that will wrap a c++ class of the same
name that inhertis from WebView::ViewImplementation. Spawning helper
processes and creating proper views in Kotlin is next on the list.
These classes are used as-is in all chromes. Move them to LibWebView so
that non-Serenity chromes don't have to awkwardly reach into its headers
and sources.
This adds menu items to open an interactive JavaScript console for a web
page. This more or less mimics the Qt implementation of the console.
Hooks are included to tie the lifetime of the console window with the
tab it belongs to; if the tab is closed, the console window is closed.
This creates WebView::ConsoleClient to handle functionality that will be
common to the JS consoles of all Ladybird chromes. This will let each
chrome focus on just the UI.
Note that this includes the `console.group` functionality that only the
Serenity chrome previously had. This was a FIXME in the Qt chrome, and
it is implemented such that all chromes will receive this functionality
for free.
The LadybirdWebView currently assumed it is viewed with a Tab instance.
This will not be true with the JavaScript console. This patch removes
this assumption by plumbing WebContent callbacks through a new protocol.
The Tab interface then implements this protocol.
For example, the JavaScript console will invoke window.scrollTo(0, INF)
to scroll to the bottom of the console after updating its contents. The
NSScrollView being scrolled here seems to behave oddly if we scroll
beyond its limit (e.g. mouse events stop working). Prevent this by
limiting scrolling to the NSScrollView's document rect.
We were relying on TabController setting the web view's initial viewport
in [TabController windowDidResize], which has been triggered when the
Tab is first created. However, it turns out that only happens due to the
toolbar being added to the Tab window, causing a resize event. When the
web view is embedded in a window without a toolbar, this resize event is
not triggered. Therefore, we must set the viewport ourselves when the
web view is added to a window.
Currently, the only NSWindow type in the AppKit chrome is the Tab. Once
we have other window types (e.g. Inspector), commands which assume they
are used on a Tab will either crash or behave weirdly.
This changes the createNewTab: command to accept the tab from which the
new tab is created, rather than assuming that tab is the key window. So
if some JS on a page calls window.open() while a non-Tab window is key,
the new tab will be opened within the same tab group.
This also changes closeCurrentTab: to work on any key window. Regardless
of whether the key window is a Tab or some other window, pressing cmd+W
should just close that window.
This lets the user choose a color scheme which differs from the active
system theme. Upon changing the color scheme, the scheme is broadcast to
all active tabs, and will be used in new tabs.
