- Date: Tuesday 30th May 2023 at 15:00 UTC
- Location: jitsi
- Status update
- Enabling Layout 2020 by default?
- Stylo upgrade
- GitHub permissions
- Demos
- Minibrowser
- Linux Foundation
- Outreach
- AOB
attending: asajeffrey, atbrakhi, cybai, jdm, Loirooriol, matlu, metajack, mrego, mrobinson, mukilan
rego: We have been making progress in Layout 2020 and elsewhere: outlines, iframes, scrolling etc. We have recently started looking at float support.
rego: We hope to land initial support for floats soon, adding more support later. We have been working on upgrading both style and WebRender as well.
rego: We have also been taking care of maintenance, fixing the build and fixing some crashes.
rego: Discussion internally about whether to make Layout 2020 the default engine and what to post as the nightly.
jdm: Strongly in favor of Layout 2020 as the default.
martin: I agree with making Layout 2020 the default, we might want to keep the nightly builds up
rego: If no one is opposed we can make 2020 the default.
martin: as the new engine doesn't have parity with the old one
jdm: would we get any valuable from users testing a nightly build of an engine we're no longer working on
martin: it depends for what people are using nightly builds
jdm: probably for finding regressions
martin: we're probably missing an index on nightly builds, to make that more useful
martin: I'm not super oppose
rego: Sounds like we have an agreement. No one is objecting to switching to the new engine by default.
oriol: I have been building a list of commits from gecko that affect their copy of style and applying them to Servo. Some of these changes require extra changes. Of the list of these changes, I have 20% of them ready.
martin: after this is finish do you think it makes sense to push our changes upstream to gecko?
oriol: I think we should try to keep them as close as possible. Maybe we can consider some kind of bot that moves these commits between engines.
rego: We can discuss more with Emilio at some point.
rego: We've been reducing the list of people with write permissions on the repository and removing folks who have been inactive. There is still the possibility to remove more people. Most patches are landed via bors, so not many people need write access.
martin: I understand there's a certain limitation about who can run tryjobs, do we want to keep the developers group with people that can run tryjobs
jdm: try permissions through homu, or what's the relationship with github permissions?
martin: is that all controlled from saltfs?
jdm: yes
jdm: the github permissions were mostly for labelling issues in the past
jack: last time I checked permissions were more fine tuned, but not very well yet
rego: We can look to see what kind of permissions people need to add labels.
rego: https://demo.servo.org/
rego: We've been looking at the old Mozilla Servo Experiments page and have forked the repository and revamped the page.
rego: We are exploring demos with WebGL and planning to look into WebGPU or GStreamer. Does anyone here have an ideas for Servo demos that are still to be revamped and added to the page.
alan: There were some WebXR demos that I put together. I don't know if they're still active or not.
rego: Right now the default servo browser is pretty basic. Should we add some more UI to make testing servo a little easier.
rego: Nothing really fancy, but something like a back button and URL bar.
alan: My memory was the original plan was to have separate chrome for the different OSes or have one common Chrome.
alan: I think the most recent plan was to move to native Chrome.
jdm: In terms of what it takes to create a slightly better experience, I can imagine two different avenues. In the past we went with a full browser experience and that was a bunch of effort. Assuming we don't want to spend time on maintaining a browser experience, I could imagine we could go for drawing the UI as GL calls and the most bare bones possible or build an embedding on top of a toolkit like GTK.
martin: there's this basic toolkit called egui, that uses WebGL
jdm: Outsourcing the UI bits to something like egui might make sense if we can get the GL set up correctly.
jdm: It feels low hanging fruit for making the project more accessible.
jack: Looks good to me.
alan: Hot take from 2 years ago is that the problem with an HTML interface is a JavaScript calls is that you have to bypass the security mechanism and makes the code horrible.
alan: Big blocker last time.
jack: Paul had a design (mozbrowser iframe design), but it didn't get implemented. It would work based on web apis to call back to a special web socket and doing the admin commands that way.
jack: the other thing to note is that if you do use egui: We had a little gui before and internationalization was a big nightmare. We had a lot of long standing bugs dealing with things like keyboard support. Back then things like winit didn't help you at all.
jack: If it's a demo thing, maybe you can just handwave that away.
jack: We did this about 3 or 4 times and after a months each one stopped working.
jack: Daala had something like that. If developers are using, maybe it won't bitrot.
rego: Yep, it would be analogous to content shell or minibrowser.
rego: Last meeting we raised the idea of moving Servo to Linux Foundation Europe. We are still managing this.
mats: I'm still waiting for the official charter, but I think it's close. If you look at LFE, they have a lot of traction. More than 100 companies joined this spring. More might be interested in joining the Servo effort. I think we can vote on this in the next TSC.
rego: Seems like feedback is positive so far.
rego: martin attended the RustNL conference and gave a talk about the project.
rego: https://www.youtube.com/watch?v=9Q4yNlbfiYk&t=18225s
rego: Next week we have the Web Engines Hackfest. Delan will also give a talk about Servo there and we will have a breakout session.
martin: I'm running the breakout session on the hackfest, if anyone has ideas for topics for the breakout session?
rego: web engines hackfest brekout session: Igalia/webengineshackfest#16
mats: One question about Amsterdam was interest in the web view.
martin: in Rust we can have a more generic webview API and Servo could have an implementation of that API
martin: there's one project that integrates around platform webviews
martin: there's an issue with Servo right now is that you need to compile it if you want to integrate it in a project, as it's not in crates.io
simon: i may be missing context here but crates.io does not ship binaries, so having that v.s. a git dependency takes just as long to compile
simon: what crate.io brings is versioning
martin: That's right. This was two separate issues that prevent servo from being easily used in rust projects:
martin: 1. It's not easy to get from crates.io.
martin: 2. It takes a long time to compile, so it's not really feasible as the embedded web view for UI frameworks that are looking for < 5 second compile times.
martin: there was the request of getting Servo integrated in a project without compiling, maybe exposing an API that can be consumed
fabrice: I would love to see support for something similar to <iframe mozbrowser> with a less hackish implementation (convincing the constellation that an iframe was actually top-level was not pleasant). Alan is right about the security issues and the need for a better story on privilege separation that would be needed for something like a custom element.
manish Goregaokar: we could still do occasional releases of the monorepo. a slight problem is that we'd have to do 0.x releases since we maintain no stability. ICU4X does periodic monorepo publishes and it works well
mats: Documenting crates and making it easier for people to use Servo.
rego: this comment from Nico: https://servo.zulipchat.com/#narrow/stream/263398-general/topic/Enabling.20Layout.202020.20by.20default/near/361011689
rego: There are a lot of crates to improve documentation.
mats: Lots of people know rust, but maybe it's still complicated to get into using and working on Servo.