Skip to content

Workweek dogfooding

jdm edited this page Nov 11, 2014 · 1 revision

Servo workweek - dogfooding experience

UI / Chrome approach

  • dherman: What should we do for UI appearance and chrome?
  • kmc: Maybe use Fennec shell?
  • dherman: Bad idea to use Firefox shell on desktop; there we should try to do something with maybe a UI designer.
  • zwarich: If you put it on Android, then all the people who have to use iPhones can't use it
  • pcwalton: Cross-platform even OSX and Linux is not a good idea.
  • zwarich: Need to be platform-specific.
  • mrobinson: How about just using the Web Platform and being largely chromeless.
  • kmc: Need for Gaia anyway.
  • zwarich: For a browser, bad for perf long-term
  • pcwalton: Eventually, should be good enough. Only near-term thing I can think of is custom shells for OSX & Linux. That's just a fair amount of work. For a throwaway, it doesn't make sense. Being Chromeless (as we've done so far, but maybe using CEF) balances the work we need to do.
  • dherman: Minimalism hides many design issues.
  • pcwalton: Biggest problem is the lack of a URL bar.
  • dherman: Came up in security - how much flexibility. Probably, once we start releasing binaries, how far along is the quality? The first version may just be wikipedia, so no UI at all. Or a fixed set of sites for this prepreprepreview, you just get a dropdown with 5 sites. Want to think about first impressions - how will this look and are there embarrassments?
  • pcwalton: My biggest concern is linux graphics driver bugs. Distro issues, subpixel text, graphics driver bugs, etc. It's just so sad. It's not worth spending time on.
  • mbrubeck: Only GPU rendering?
  • kmc: Just worse with GPU. We may have to do software compositing with offscreen mesa so there's a safe mode.
  • zwarich: Performance claims on Linux on top of X seems ridiculous.
  • dherman: How big of a segment of the tech elite audience is on Linux?
  • jack: Lots.
  • pcwalton: Especially people who are Mozilla-friendly.
  • mbrubeck: It's not a number that's grown in the last decade, but it hasn't shrunk either.
  • pcwalton: It's big in the early adopter crowd, which is linux, but not the hip OSX Web N.0 crowd.
  • dherman: We should not antagonize our Linux friends, but should acknowledge what the limits are to what we can do to have a great experience on Linux.
  • pcwalton: Issue is - do we have a basic layers fallback implementation for Linux and XP? One of the big things I did during FF Android mobile was go GL layers only without a fallback. I don't see a point in investing in Linux+X - Wayland is in much better shape.
  • dherman: Good. Investing in Wayland support on Linux sounds better.
  • larsberg: Be Wayland-only?
  • mbrubeck: Going back to Chrome, if it's a bar with a text file where you can type a URL, then if it's something we can fill in during our development, it's a nice entry point for people who want to contribute to Servo. They can make our stupid URL bar look prettier; have a Reload button; etc.
  • pcwalton: There's a huge chasm between Chromeless and Chromeless+URL bar. Immediately you're no longer using cross-platform toolkit stuff like glutin.
  • mbrubeck: I was envisioning glutin, and just having a rect within Servo, use conrad or the piston GUI API to put stuff there. Then anybody in Rust can build some stuff to extend it.
  • kmc: Can do a servo shell with piston/conrad.
  • mbrubeck: Yes, that could evolve.
  • dherman: If we started the basic bits, that's great.
  • larsberg: Should we be talking about dogfooding on desktop? We only care about mobile now.
  • pcwalton: Desktop, but let's talk about it...
  • jdm: Let's talk about features we need for dogfooding

Features we need for dogfooding

  • jdm: Here are some issues that are required to view basic pages: https://github.com/servo/servo/milestones/Dogfooding
  • jack: Probalby need some jQuery stuff. innerHTML, etc.
  • kmc: Also need fragment parsing.
  • gw: Don't you need jQuery for basically every website?
  • jdm: Things on this list include iframes that load. And getting a load event that reflects when things have loaded. Cookies.
  • simonsapin: Basic jQuery functionality, or the whole test suite?
  • jdm: Just enough to not block further JS.
  • kmc: Would be nice to grab the test suite, ala WPT, and mark known regressions.
  • jdm: We do that in FF.
  • cgaebel: And bootstrap, too.
  • jack: Is libeditor in there?
  • jdm: Forms / textarea? Yes.
  • jack: This has layout text area, but we need to type things in it...
  • mbrubeck: Document.write?
  • kmc: Yes, it's very common. And not much work at this point.
  • jack: I bet nobody'd notice. it's not used for anything other than ad networks.
  • mbrubeck: It's more that when document.write fails, it stops script running.
  • gw: I thought it's widely used...
  • jack: My understanding is that's primarily in ad network code.
  • jdm: element.style
  • pcwalton: That's the largest thing I immediately run into. That's most of jQuery.
  • jack: We have AJAX, so if we had style and innerHTML, we'd be pretty much there.
  • gw: getComputedStyle?
  • kmc: Not sure.
  • dherman: When you talk about dogfooding, do you have a concrete set of websites.
  • jdm: Github and Critic, for me.
  • pcwalton: HN.
  • kmc: Rust language docs with the search bar working. Doesn't even need cookies.
  • gw: etherpad
  • zwarich: content-editable is unrealistic. Probably even in 2015.
  • bruno: MDN.
  • jdm: DOM SPEC!
  • pcwalton: doesn't it work?
  • bruno: Needs document.write.
  • dherman: I'd expect github and MDN to be hard
  • jdm: We are parasites! We don't need to edit MDN :-)
  • manish: IRCCloud?
  • zwarich: Hard...
  • pcwalton: Twitter. Not a lot of editing requirements there...
  • dherman: Good scrolling dogfooding test.
  • mbrubeck: Have Servo read the firefox cookie jar!
  • zwarich: No. Don't. Totally insecure.
  • kmc: Maybe just a readonly cookie jar...
  • pcwalton: Just make cookies work. Send them up to the constellation.
  • jdm: There's someone working on cookies right now. There will be a PR soon. It's a resource task.
  • pcwalton: Just want it sandboxed; sounds fine.
  • cgaebel: reddit
  • jack: I need to be able to vote!
  • kmc: In dogfooding, our resource loading is slow and synchronous; we should fix that.
  • pcwalton: Yes, and in line with all of our goals.
  • jack: Network stack needs some attention.
  • kmc: Also moving off rust-http.
  • zwarich: Lots of things wrong with page and resource loading right now that need to be fixed.
  • pcwalton: I like twitter, wikipedia, reddit, HN, github. Lots of simple sites. What's blocking me personally is CSSOM, not logging in, and URL bar. At that point, I'd use it for simple things. I like how smooth the graphics are.
  • kmc: Not as smooth on linux, which makes it harder for us to adopt...
  • pcwalton: You could fix those issues!
  • jack: Or we could buy pcwalton a linux box...
  • dherman: One purpose of dogfooding is getting it on your critical path. Fix the papercuts.
  • mbrubeck: URL fixup would be great.
  • jdm: Funny you mention that!
  • simonsapin: On the commandline, we have to distinguish file from domain names.
  • mbrubeck: If the file exists open, otherwise...
  • kmc: Is there a spec?
  • simonsapin: There is no commandline spec.
  • kmc: URL bar?
  • simonsapin: No.
  • kmc: Then we can do something reasonable and write the spec?
  • mbrubeck: FF has a huge complicated thing. Would like defaulting to http://
  • simonsapin: Why not https://?
  • kmc: I like that.
  • larsberg: Facebook?
  • zwarich: Desktop is hard. Dynamic loading is hard.
  • larsberg: Maybe mobile? Their native app is terrible.
  • dherman: Probably not.

URL bar

  • dherman: I like the idea of doing something small and getting volunteers or designers involved.
  • pcwalton: My idea with rust-alert was to bridge the gap between things like glutin and monkeypatching the window that glut was popping up with.
  • jack: Rust-whatever worked fine, just broke in linux.
  • pcwalton: Just add a URL bar natively on each platform via the native widnow handle? Really not bad.
  • kmc: Maybe we shouldn't put in the work, but there are tons of rust gamedevs who might want to do it.
  • mbrubeck: In the windowing API, instead of passing it in, you can specify the viewport for Servo to draw to. That's the goal for the app that creates the window not to have to give the whole thing to Servo.
  • pcwalton: Maybe making our own cross-platform miniui (like minibrowser) isn't a bad idea.
  • jack: We have 2 platforms. Why be cross-platform?
  • zwarich: If you have ever tried to write cross platform GUIs, you would not want to.
  • dherman: Agreed, so do not try to abstract.
  • zwarich: Just put a URL field and back/forward. Also, per-platform, how do you composite GL content with the window?
  • jack: Can't we just use CEF?
  • mbrubeck: Can we just use CEF?
  • jack: I know GTK and can do Linux.
  • pcwalton: I'll do OSX.
  • jack: Put it in ports.
  • zwarich: Chrome directory.
  • kmc: Name is confusing.
  • dherman: Very careful with naming. Don't make this look like a product from Mozilla.
  • zwarich: Fortunately, a screenshot will make that clear :-)
  • dherman: Careful edge here. Don't want to sound too much like a real product.
  • mbrubeck: More about the directory structure.
  • jack: We should not call anything Chrome.
  • mbrubeck: We need to replace the binary.
  • jack: Maybe examples/
  • pcwalton: Or tools/
  • dherman: More repos?
  • pcwalton: Sure. Have to test that later.
  • jack: In-tree for now.
  • pcwalton: We'll use native controls for now for our chrome.
  • zwarich: The native controls give you a consistent look with the rest of the applications on the platform.
Clone this wiki locally