In preparation for the next release, bump the version number to 0.1. 0.1
will be an LTS release, which receives extended support in terms of
security updates (e.g. spidermonkey security updates). Please keep in
mind that as always no specific guarantees or response times are given,
and any updated are provided on a best effort basis.
Previously some projects had a demo integration of servo based on some
version of servo, and then never or rarely updated it. Providing an LTS
release offers an option to embedders to integrate servo, while reducing
API churn and having a somewhat fixed schedule to adhere to in terms of
upgrades. Currently, the plan is for a new LTS release every 6 months,
with additional documentation regarding API changes and recommended
migration patterns (best-effort and subject to change).
Testing: No functional changes. Additional testing will be performed
post-merge on the newly created release branch.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
It turns out the HarmonyOS version numbers can be confusing. This now
puts it as the same as the OpenHarmony version numbers.
As the SDKs are backwards compatible everything should still work with
newer SDKs.
Testing: CI will test compilation and installation and manually tested
by me.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This updates the Openharmony required version to API lvl 21 (6.0.0.1
OpenHarmony and 6.0.1 HarmonyOS).
We need API level 19+ for https://github.com/servo/servo/pull/41738,
however an API level 19 SDK was never released for OpenHarmony. API-20
seems to be the same as the the 6.0-beta release, so we are playing it
safe and directly going for the API-21 release, which is also the 6.0.1
release that the actual HarmonyOS 6 update was, so it should be the most
polished.
This also has the update for the version used in CI.
The HarmonyOS runners are already updated.
Testing: Successful openharmony run here:
https://github.com/Narfinger/servo/actions/runs/21755920480
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This version bump is a bit delayed, since I forgot to open the PR before
FOSDEM. The actual release will thus likely not be based on this commit,
but backported to the release branch, to stay in sync with our monthly
report.
There still has been no resolution on the `0.1` version bump situation,
hence another bump of the patch version.
Testing: Not required
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
We can start initializing servo without needing to wait for the
creation of a window.
This allows us to perform initialization of servo itself,
concurrently to the app UI thread setting up the app UI.
Once the native window is ready, we can then let servo create
the first window and load the initial URL.
This is also interesting in the context of using servo as a
webview library, where loading the library / initialising the
webview and loading the first url are typically decoupled
steps.
Note: on the android port the Java code is not touched, which means that
we effectively still
perform the initialization at the same point in time on android.
The change to call the base servo initialiation from the Java app, can
be done in a seperate PR, perhaps by someone more familiar with android
than me.
Follow-up PRs will add multi-window support, which means that some of
the multi-webview related code in this PR has open todos,
which will be addressed by follow-ups.
Testing: The ohos-port is tested in CI, the android port was manually
tested by me.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Currently, commandline arguments need to be used like this:
'--psn=--tracing_filter' which people can easily forget and use
'--psn=tracing_filter'.
This happened to multiple people and leads to weird issues, since the
argument is silently dropped.
Because OHOS appends a lot of other arguments and we don't have a good
way to filter out the OS provided arguments, we now print a big error
message that hopefully should be noticed by the user for a couple of
commonly used arguments.
Testing: Tested on device with and without the correct way to invoke
arguments.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
As discussed in the tsc-channel, prepare for the next release by cutting
a version on the last day of the month.
Note: The actual release would happen ~ 2 weeks from now, when the blog
post for november is ready.
This commit was produced by running `./mach release 0.0.3`.
Testing: Not required. Additional pre-release testing will happen after
the version bump and before the release, with potential patches being
cherry-picked to a release branch.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This makes it mostly that the correct keyboard will be selected and we
don't start with an uppercase letter.
Testing: Compiled on OHOS and looked on the phone.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Ran ./mach release 0.0.2 to update the version number and update the
license.html
This is in preperation for the v0.0.2 release with the next nightly, as
discussed on zulip.
Testing: Not tested
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
OHOS CI: Now we can benchmark specific files. These files need to be in
the runs.json and in the supprt/hitrace-bench folder.
A simple testcase of parsing html from string is included (taken from
https://github.com/servo/servo/issues/37223).
We copy all files in
support/hitrace-bench into the hap of the phone.
These files can use the console.log javascript command to get their
measured output.
Additionally, this now supports reporting resident-accordings-to-smaps
which is a slightly different memory than resident.
This needs update to hitrace-bench 0.7 which will be completed once the
PR is marked ready.
Testing: On action runner here:
https://github.com/Narfinger/servo/actions/runs/16118101025/job/45477031813
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Currently we just pause the compositor and replace the window in it
while having separate bookkeeping to remember which window belongs to
which tab.
Currently there are no tests for OHOS, so we cannot test the changes.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Co-authored-by: Jonathan Schwender <55576758+jschwe@users.noreply.github.com>
Uses the native ohos-api crates to get the required information for
starting servoshell.
This increases the minimum API version requirement to API-14.
Testing: Tested on device.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Co-authored-by: Jonathan Schwender <55576758+jschwe@users.noreply.github.com>
Split out `save_output_image_if_necessary` into its own file so the code
can be shared by servoshell on the desktop and ohos.
Additionally, hook it up to the loop in OHOS and have OHOS allow
exiting.
Testing: Manual testing on ohos and desktop.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
The `Column()` height and thus also the XComponent height extends beyond
the physical display for unknown reasons. This is a problem on websites
that have a footer bar, since the footer is partially below the display
end.
Using Flex with Column direction works as expected.
Testing: Manual inspection with DevEco Testing inspecting the height of
the children elements in ArkUI
Fixes: Part of the servoshell surface extending beyond the physical
screen on ohos
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
The `shell` suffix causes issues with the startup profiling tools on
OpenHarmony. The profiler fails to detect the start of the app.
This is fixed by renaming the app. I tried various
different variations and identified the `shell`
suffix to be the culprit.
E.g. `org.servo.shell` has the same issue, so its not
a length issue.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This avoids future crashes if new unknown parameters
are passed by the runtime to the app.
It does make it slightly more inconvenient for the user,
since they must use `=` and space at the right place now.
This will also be updated in the book accordingly
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Override the `onBackPress` callback, which by default
brings the application to the background and instead
tell servo to go back one page.
Users can invoke this by swiping from the left edge to the middle.
There is no equivalent callback / gesture to go forward.
In the default browser swiping from the right side to the middle
also invokes the goBack callback.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
These following four OHOS specific arguments are being passed by the
OHOS runtime to the EntryAbility, which then passess them on to Servo's
argument parsing logic:
* `--debugApp=false`
* `--send_to_erms_targetAppDistType=os_integration`
* `--send_to_erms_targetAppProvisionType=release`
* `--send_to_erms_targetBundleType=0`
When Servo's argument parsing logic encounters an unrecognized argument,
it terminates the process after logging an error to stderr (which is not
visible in hilog).
This patch simply filters out these arguments so the parsing logic
doesn't fail.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
* ohos: Bump minimum CMake version
By bumping the minimum CMake version, we avoid a deprecation warning.
The OH 4.0 SDK ships with CMake 3.16, so we can be sure that we have CMake 3.16
or newer available.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
* ohos: Allow passing arguments to servoshell
Allows passing options passed via `wants` to the Ability through to servoshell.
This allows easier debugging, either by calling servoshell from a test app,
or from the commandline, e.g.
```
hdc shell aa start -a EntryAbility -b org.servo.servoshell -U "https://www.wikipedia.org" \
--pb dom.webgpu.enabled true \
--ps dom.webgpu.wgpu_backend "gl" \
--pi layout.threads 4
```
Note: While the OH `wants` API differentiates between boolean, string and integer values, we convert
everything back to strings, so we can reuse the same parsing code as the desktop servoshell.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
---------
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
* ohos: Support product flavors
Support different product flavors (e.g. with different signing
configurations) by supporting --flavor on ohos.
The flavor influences the package path for OH packages, so
allow the flavor parameter on build + package + install
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
* Fix smoketest
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
Bundle resource files into the .hap, so they are available
as files in the application sandbox, instead of included
into the shared library.
This should slightly reduce the binary size in debug and
release mode.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
25372340 added back and forward apis to the ohos servoshell.
157e28c5 vendored the ohos demo ArkTS app into the servo repo,
but did not include the back and forward buttons, which
were added in the meantime.
This commit adds the missing back and forward buttons to the ArkTS code.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
