Meeting 2014 01 21

Agenda

• Servo workweek

Attending

• larsberg, jack, pcwalton, jdm, ibnc, simonsapin, brson, samsung

workweek

• jack: I'm working on fixing up CSS matching
• pcwalton: I'm working on speeding up parallel layout
• simon: I'm rebasing some Rust changes
• jdm: I'm doing the JSManaged work to remove @-boxes in layout
• larsberg: I'm fixing ref tests and improving the android port
• ibnc: working on position:fixed, creating ref tests, and fixing iframe issues

list items in acid2

• simonsapin: there are four list items. one has display:none.
• jack: oh, this PR includes cascading the list items. Are there any ref tests for that PR?
• samsung: not yet. today we will add ref tests.
• simonsapin: for inside, it's easy because the marker is just text (like inline elements). for position:outside, it is harder to get it outside
• pcwalton: so you need a separate flow that is the list flow? Not just a block flow?
• jack: we control the indentation, don't we? if the list markers are outside the list, they are some number of ems outside the list, right? we should be able to have the exact same ref test
• simonsapin: maybe. depends on how we implement it.
• jack: hopefully you can come up with a ref test for it. If not, that's OK. but we should have some ref tests. Simon also suggested we use these w3c spec tests. I will send an email with the test link, and I'll send one with the CSS2.1 features. Using a couple (not all!) of the tests there would help. For example, on overflow:hidden, there are some CSS2.1 tests that do not work. I have added those tests to the bug so that we can check them. We should do the same thing for these list elements. A bug with some tests listed: https://github.com/mozilla/servo/issues/1290 The CSS2.1 tests are here: http://test.csswg.org/suites/css2.1/20110323/html4/toc.html
• jack: we will review PRs. Do you have any questions?

Questions about :hover

• parkjaemon: two PRs related to some features. Can we talk about those :hover comments?
• jdm: Preventdefault does not stop hover. And Gecko sends out mouse events every time the mouse moves for hover.
• jack: Should we be re-building the displaylist?
• pcwalton: Yes, I believe so.
• jack: Do we need that support to implement hover?
• jdm: DOM events is the correct way to do it.
• pcwalton: which requires us to rebuild the displaylist. events go first to layout and then you build the display list and then figure out what node to send it to.
• jack: But we already support clicking on links. Can't we do hover the exact same way?
• pcwalton: The difference is that we don't want to flood layout every time you move the mouse.
• jdm: Gecko just sends out the mouse events and is building display lists.
• simonsapin: when gecko does selector matching, it sets bits on elements that have :hover, which makes them available.
• pcwalton: The only thing I can think to do otherwise is cache the previous displaylist.
• jack: what do we do now?
• pcwalton: we try to cache the previous display list. As you move the mouse around, we can just perform hit testing on the display list. Then we can use that bit (like gecko does, indicating if something is affected by hover).. no. As you mouse over, you have to always send an event to script. But the :hover may change properties of the DOM causing a repaint, which requires asking layout to reflow.
• jack: So, the first thing to do is to get mouse move events working into script.
• pcwalton: We could do a reflow every time you move the mouse to determine which item you are hovering over. That is step 2.
• jack: How do you know which element you are over?
• pcwalton: Layout needs to know the position of the mouse.
• jdm: Mouse move goes through each element in the DOM. If they do not have a hover event registered, they do not set it. (All elements have mousemove event handler and check for mouse over self)
• pcwalton: Script should then set the hover state as a bit on the element. Then, layout selector matching can query that bit. So, just add another method to LayoutNode that is getHoverState, and then you need to trigger a reflow on every mouse move. (this is a different step 2). Eventually we can make this faster.
• jdm: We do not have infrastructure for handling events on our DOM objects right now. They all go through script. Only addEventListener is hooked up. Clicking on links is hardcoded to skip DOM events and follow a link.
• jack: Should we implement hover without adding the DOM events?
• jdm: We should set up event handling so that it works in our own rust code from the DOM. We should fix the events to be handled properly from DOM events instead of hacking it to work in layout like we did for click events.
• jack: I'll first fix click events to work the right way. Then, others can implement hover in terms of the work that jack does (using DOM events through rust event handlers). Issue #790 (https://github.com/mozilla/servo/issues/790 ). jdm will open a bug for how to fix click handlers which jack will fix. Then we can do hover on top of that work, which is what works for hover on ACID2.
• jack: Did that discussion help?
• parkjaemon: yes.

overflow:hidden

• jack: who worked on overflow:hidden?
• parkjaemon: nobody is assigned to it.
• jack: There are some bugs in it. Does it work for ACID2?
• sammykim: no, we did not. https://github.com/mozilla/servo/issues/1290 and I added some tests for it that fail, but I didn't check if it passes for ACID2. I'm not sure what's going wrong there, but if you could take a look at it, that would be good.

servo on android

• jack: did lars' latest response fix it for you? servo on android?
• aydinkim: I have tried to solve the problem, but I did not update it. I updated the issue page on the wiki. I have some questions in there.
• jack: what SDK version? API level?
• aydinkim: API: 18
• larsberg: I am using r9 and API level 18 as well.
• jack: releng is setting up the android buildbot. NDK 8 and API 16 .
• larsberg: Rust requires 18.
• jack: is that new?
• brson: All I know is we require 18. do you know why?
• larsberg: there is a bug with weak symbols.
• jack: I need them to make new packages for us at NDK 9 and API 18. This is also a problem for our Lion bugs (thoguh that is going away).
• brson: Maybe that is a Rust bug and we should support older SDKs.
• jack: will you do that?
• brson: No.
• jack: We will use NDK9 and SDK/API18. Our release engineering team does not want to support multiple things, but can.
• larsberg: aydinkim - please check to see if the _rust_crate_map symbol is shown or not appearing (https://github.com/mozilla/servo/issues/1495 ). I am sorry I was slow to reply the last two days - I was traveling and had poor internet access.
• jack: brson, how is the android tester going for rust?
• brson: Going well. I have not seen a green build, but it is almost complete. The failures are not random, it is just hard to keep working because we regress minor features as code is added to Rust. Right now, it is external syntactic extensions that are causing cross-compilation failures. I am working on that now. We are at the point where android kind of works consistently.
• jack: Can you gate the build on it?
• brson: No.
• jack: Are we close? If we could gate them, these checkins would not not pass. What's stopping us?
• larsberg: We need one green build...
• brson: Yes, we're always one commit behind from having everything work.
• larsberg: Could xfail something and say break nothing new...
• brson: I am doing that.
• jack: I do not know when we will have servo android buildbot
• larsberg: Can we just run our own?
• brson: We could contract some people out to make them for us.
• jack: So, at least we have android building. Hopefully we will help get it working on your android machines and we should have everything fixed before the next rust upgrade. If we do not get the android buildbot in place, we will set up another machine on brson's desk.