On 7/24/17 1:53 AM, Manish Goregaokar wrote:
and the styloVsGecko / issue (which does not block landing since
it's a
slight discrepancy between stylo and gecko)
Looks like it's a difference in vertical alignment. How sure are we
that this won't affect web pages outside of media controls?
On 6/2/17 12:34 PM, Michael Howell wrote:
$ echo -n "Allow style sharing elements with ID selectors" | wc -c
Misleading, unfortunately, because that changeset on its own doesn't
allow anything of the sort.
-Boris
___
dev-servo mailing list
On 6/2/17 11:50 AM, Anthony Ramine wrote:
Though not required, it’s a good idea to begin the commit message with a single
short (less than 50 character)
Just so we're clear, 50 characters is about 9 words.
- Fix style sharing of elements affected by id selectors
No, that's not what it
On 6/2/17 5:18 AM, Anthony Ramine wrote:
In the following screenshot, you can see one doesn't even know what that commit
is supposed to do from its title, because it is way too long to be informative.
OK, what is the proposed cap on first line of commit message?
Everything I've seen suggests
On 4/17/17 12:09 PM, Milan Raj wrote:
It would be great to have more control externally to know and control when
records are added or removed from the undo / redo stack.
https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html was an
abortive attempt to create a spec for this sort of
On 3/27/17 12:05 PM, Jack Moffitt wrote:
Yes, but since layout runs in parallel and is pretty fast, I'd think
the common case was that it would be done by the time it got the
second request.
I doubt layout is "pretty fast" on the scale involved here, which is
"hundreds of times per frame".
On 3/27/17 10:36 AM, Jack Moffitt wrote:
Responses to layout queries are just sent messages (if layout needed
invoking to answer them). It is possible to send them early as soon as
the relevant data has been computed. Servo does not do this currently
though. An initial implementation could just
On 3/16/17 7:35 PM, Krishna karthick Balaji wrote:
I am trying to write tests for MutationObserverAPI
(https://github.com/servo/servo/wiki/Mutation-observer-project)
Are these tests covering something not already covered by the various
dom/nodes/MutationObserver* tests?
-Boris
On 3/2/17 2:40 PM, Nikhil Shagrithaya wrote:
Shouldn't it be possible to extend speculative parsing to continue parsing
HTML instead of just fetching other resources?
For what it's worth, Gecko does this: speculatively tokenizes off-thread
even if the parser is blocked.
If a
On 11/3/16 4:30 PM, Simon Sapin wrote:
Servo defines:
type AttrValue = std::string::String;
type Identifier = servo_atoms::Atom;
type ClassName = servo_atoms::Atom;
type LocalName = html5ever_atoms::LocalName;
type NamespacePrefix = html5ever_atoms::Prefix;
Ah, perfect.
On 11/3/16 3:17 PM, Simon Sapin wrote:
An important aspect is that atoms with different static sets are
different Rust types.
Just to check that I understand correctly...
Are element names atoms? Which static set do they come from?
Presumably the html5ever one?
When parsing CSS selectors,
On 9/19/16 6:49 PM, Jim Blandy wrote:
grandparent (origin O)
parent (origin P, P != O)
child (origin O, same as grandparent)
then the grandparent and the child are in the same UoRSOBC. The grandparent
can say `frame.contentWindow.frames[0]` to get its grandchild
On 9/7/16 11:55 AM, Geoffrey Sneddon wrote:
There are plenty of rendering bugs that don't involve text, and
practically if you're generating arbitrary web pages it's easy to solve
all of those problems by simply not including text (though you'll need
to give boxes explicit heights!).
Does
On 6/22/16 11:17 AM, Manish Goregaokar wrote:
We don't close down the tree except for CI fires
Yes, I understand your model. You don't have to explain it to me.
I was just pointing out that for normal commits you prefer the model of
test-each-thing, but for style system you would prefer the
On 6/22/16 9:52 AM, Manish Goregaokar wrote:
This has one significant drawback: it places a pretty serious burden on
whoever performs the sync. In particular, in addition to merging the
actual code (already needs some expertise), they become responsible for
handling any test failures that arise
On 6/22/16 8:47 AM, Manish Goregaokar wrote:
Changes to webrender would be made in m-c or servo/webrender,
whichever is more convenient, and there is a periodic sync operation.
This has one significant drawback: it places a pretty serious burden on
whoever performs the sync. In particular,
On 6/21/16 12:20 PM, Lars Bergstrom wrote:
I'm still a bit worried about this unless the revert rate comes down pretty
significantly for any shared branch between servo and gecko.
That's fair. We should certainly not make inbound that shared branch! :)
But we'll see how the proposals come
On 6/21/16 8:34 AM, Lars Bergstrom wrote:
If a backout lands as a `git revert` of the offending commit(s) I'm certainly
less concerned, as that's annoying but not impossible for people to continue
rebasing against.
Right, that's how backouts land.
The way it was explained to me (and I may
On 6/20/16 8:35 PM, Lars Bergstrom wrote:
Backouts came up in the discussion, and I tried to make it pretty clear that
they are not compatible with a GitHub-style development model (even if you
*could* hypothetically do crazy things like force-pushing rewritten histories
to master).
Wait,
On 2/3/16 1:46 PM, Josh Matthews wrote:
Nikki asked for suggestions for how to review code, so here's my first
attempt at writing down a general suggested workflow for reviewing Servo
code:
https://github.com/servo/servo/wiki/Code-review
Somewhere in there, one should read the commit messages
On 11/4/15 12:09 PM, Manish Goregaokar wrote:
I'd prefer to avoid diverging from the spec wherever possible -- even if
other browsers disagree (with the spec and with each other)
I think Ms2ger was talking about cases in which the spec disagrees with
all browsers, who agree with each other.
On 11/3/15 4:52 AM, David Bruant wrote:
@Manish: additionally, perhaps leave a comment in the open spec bug
Oh, yes. Any time the spec does not match reality or sanity, do let the
spec author know.
-Boris
___
dev-servo mailing list
On 11/2/15 2:21 PM, Manish Goregaokar wrote:
We have three choices here, we can wait indefinitely until the spec gets
fixed, we can implement the spec as is (which require major changes and
affect perf or complexity), or we can hope that nobody relies on this
behaviour (given that it's not
On 4/28/15 5:23 AM, David Bruant wrote:
Another possibility is for the reporter to make a PR with the test case.
Just stop. We're talking about making it _easy_ to report issues, yes?
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
On 4/28/15 10:33 AM, Jack Moffitt wrote:
This is an issue, but hasn't hit us much yet.
Sure. I assume if it had you would have been dealing with it. ;)
It's easy enough to use the ``` syntax to include arbitrary things
into a bug report. This is how we often attach logs and such. You
can't
On 4/27/15 8:38 PM, Josh Matthews wrote:
https://github.com/servo/servo/wiki/Meeting-2015-04-27
I've mentioned this a few times, but...
For a layout engine, being able to attach an actual testcase to a bug
report is _really_ useful once you get out of just build it mode and
into fix all the
On 1/28/15 12:33 PM, Josh Matthews wrote:
I'm not certain what you're asking. The events come from another thread,
so they need through some kind of event queue. Today, that's the
per-origin event loop.
OK. That means, for example, that you can't navigate away from a page
that's in the
On 1/28/15 7:21 AM, Josh Matthews wrote:
My current line of thinking is that we send a message to the compositor
that puts the pipeline in the modal state and pops up a dialog.
Additionally, the message contains a Sender, with the script task
waiting synchronously on the corresponding Receiver;
On 1/27/15 5:46 PM, Josh Matthews wrote:
We don't have the notion of a global event loop or anything. We
effectively have an event loop per script task (ie. event loop per TLD),
but no ability to spin it arbitrarily at the moment.
How do you plan to implement alert()? Do you plan to allow an
On 1/12/15 2:39 PM, Josh Matthews wrote:
the obvious downside is that a tab's event loop will be cluttered with
constant attempts to poll for incomplete network responses during page
load.
Not just during page load. I expect this to peg the event loop on any
site that uses long polling (see
Apparently Blink has been changing how they handle style invalidation on
DOM mutations.
https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8/edit?pli=1#heading=h.xa3ovcncd2vp
has a writeup of sorts for those who are interested.
-Boris
On 10/28/14, 1:15 PM, Patrick Walton wrote:
In other words, what are examples of
the major pain points that DLBI was designed to handle in Gecko?
You should double-check with Matt Woodrow, but three things come to mind:
1) Pre-DLBI, invalidation code was scattered all over layout and it was
On 10/20/14, 1:29 PM, Josh Matthews wrote:
https://github.com/servo/servo/wiki/Meeting-2014-10-20
I'm not sure I understand the sync script bit.
You don't want to block user interaction with the page while fetching a
script. You also don't want to block the parser tokenization prescan,
On 10/14/14, 12:26 AM, Simon Sapin wrote:
Is there anything other than SVG that might require an XML parser
XMLHttpRequest and DOMParser, no?
but it sounds unlikely that real content relies on an entire
document failing to parse.
XMLHttpRequest not only relies on it, but relies on the
On 10/6/14, 3:53 AM, Cameron Zwarich wrote:
Where do most of the small strings larger than a single character that benefit
from the inline small string optimization originate, the DOM or user JS code?
That's a good question.
When the optimization was added, strings that originated in the DOM
On 10/6/14, 7:44 PM, Boris Zbarsky wrote:
Just to check, what's the plan for doing overflow: sticky?
I mean position: sticky, of course. ;)
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
On 10/5/14, 2:27 PM, Cameron Zwarich wrote:
I am opposed to anything that requires string copies between the DOM and JS
The only way to do that with SpiderMonkey in its current state is to use
JSString for your string type. You cannot safely grab the chars from a
SpiderMonkey string and
On 7/18/14, 4:10 PM, Manish Goregaokar wrote:
- Rewrite the Header class to contain bytes
Note that you need header bytes for web APIs like XMLHttpRequest.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
On 5/29/14, 11:39 AM, Simon Sapin wrote:
I’m aware that every style struct must contain either only inherited
properties, or only reset (non-inherited properties). Other than that,
what’s the guiding principle to decide how many structs to have, and
which properties go where?
Initially the
On 5/8/14, 9:06 PM, Keegan McAllister wrote:
This is all a bit moot if a parser never lives across a JS operation that could
GC.
If you want your parser to be able to parse web pages with script tags
in them, I don't see how you can possibly avoid GC while the parsing is
only partially
On 4/28/14, 6:02 PM, Keegan McAllister wrote:
Ultimately I'm sort of pessimistic about table-less interning, because it
proposes to speed up parsing at the expense of layout.
A thought.
If the goal is to speed up parsing in a separate task by avoiding
contention on a table, have we
On 4/23/14, 8:53 PM, Brian Anderson wrote:
We're assuming nobody is going to be attacking Rust symbols though
Oh, right, that's the other worry.
We've had security issues in the past due to things like input
type=fİle being treated as a file input by some parts of the system
but not others.
On 4/20/14, 2:16 PM, Patrick Walton wrote:
Yes, I think it can. :( But there's an easy workaround: just fall back
to sequential layout for a subtree if the speculation fails. That will
eliminate the cascading series of speculation failures leading to
exponential blowup problem and allow
On 4/3/14 8:03 AM, Henri Sivonen wrote:
Have we instrumented Gecko to find out what the access patterns are
like?
We have not, but I will bet money the answer is different for
benchmarks and actual content...
-Boris
___
dev-servo mailing list
On 3/31/14 8:44 PM, Josh Matthews wrote:
https://github.com/mozilla/servo/wiki/Meeting-2014-03-31
A note on tables and pagination: that's a place where you won't really
be able to lean on Gecko experience. Or more precisely, table
pagination in Gecko is at the state where all pagination is
On 3/29/14 6:56 PM, Simon Sapin wrote:
Or I guess we could use what I’ll call evil UTF-8, which is UTF-8
without the artificial restriction of not encoding surrogates.
http://en.wikipedia.org/wiki/CESU-8
As far as I understand, a parse error in the spec is meant for
conformance checkers
On 3/29/14 8:23 PM, Patrick Walton wrote:
This is just 29 bytes of code when assembled. This is likely larger than
the equivalent `nsRuleNode`
The right comparison is not nsRuleNode but nsCSSSelector, right?
These are actually pretty bloated in Gecko right now. For example,
.foo #a is
On 3/4/14 5:33 PM, Josh Matthews wrote:
I know that some contributors have expressed confusion about the new
JST types that are all over the DOM. I've started a guide to try and
clear up how to use them; please feel free to suggest further topics or
make edits yourself:
On 2/13/14 5:56 PM, Robert O'Callahan wrote:
2) Fragmentation. With something like overflow:fragments, absolute
positioning can affect the number of fragments you generate, which can
affect the size of the container of the fragments.
Ugh. I thought one of the points of absolute positioning
On 12/16/13 1:54 PM, Josh Matthews wrote:
https://github.com/mozilla/servo/wiki/Meeting-2013-12-16
Some questions on github issues:
1) Do we plan to stick with them for the entire lifetime of servo? That
is, does github plan to grow reasonable options for at a minimum release
tracking and
I generally consider it pretty intractable, but the Blink folks are
trying it: http://code.google.com/p/chromium/issues/detail?id=283623
The idea is that a layout flush should only do layout until the part we
care about is stable. Or something.
The Blink bug highlights some of the issues
On 8/31/13 2:15 PM, Patrick Walton wrote:
Dromaeo is pretty old and is basically SunSpider.
Dromaeo has a bunch of DOM micro-ish-benchmarks on the one hand and
microbenchmarks of common JS libraries (jquery, etc) on the other. Just
make sure to run the DOM and CSS portions of it, not the
On 8/31/13 10:41 PM, Jack Moffitt wrote:
The DOM ones were specifically what I had in mind. CSS testing
probably doesn't make much sense unless we can test stuff we've
already implemented in order to compare to the upcoming Rust style
system.
The vast majority of the tests labeled as CSS in
On 8/30/13 11:55 PM, Josh Matthews wrote:
The current DOM bindings can only fallibly unwrap object types that have
complete WebIDL prototype chains (ie. we can grab the interface ID array
from the object and compare the slot in the chain we care about with the
one we're trying to unwrap). This
On 8/8/13 8:18 PM, Josh Matthews wrote:
On a related note, saneyuki added support for some element types that
don't have their own interfaces and just use HTMLElement.
Note that there are other cases where multiple element types all use the
same interface that's not HTMLElement (e.g. col and
On 7/30/13 3:30 AM, Simon Sapin wrote:
a. A CSS representation of the whole selector list a a string, for the
CSSOM’s selectorText
b. The specificity for the cascade
c. Just the data structures we need for matching
I think this would work, but maybe the cost of a. cancels whatever we
gain in
On 7/29/13 11:38 AM, Simon Sapin wrote:
type Namespace = i32 // Is this some kind of interning as well?
In Gecko, yes.
* Use vectors / arrays instead of linked lists for AtomList,
PseudoClassList and SelectorList. (Less allocations) This could make it
more difficult to point somewhere
On 7/24/13 12:16 PM, Josh Matthews wrote:
All DOM objects are represented with |JSManagedWhatever whatever|.
When you want to access a property owner_document of Whatever, you use
|do whatever.with_imm |whatever| { whatever.owner_document }|, and |do
whatever.with_mut |whatever| {
On 7/25/13 8:51 AM, Josh Matthews wrote:
wrapper: 8 bytes
type_id: 16 bytes
abstract: 16 bytes
out_of_line: 8 bytes
layout_data: 8 bytes
Hmm. That's a lot smaller than 128 bytes, right? I guess the point is
that you could't put _all_ of parent/first/last/next/prev/ownerdoc
inline, which is
On 7/25/13 9:25 AM, Josh Matthews wrote:
type_id is an enum to distinguish between node types, with an inner enum
in the element case to distinguish the kind of element. All enums are
automatically 8 bytes, and if any variant contains another enum that
automatically bumps it up to 16.
OK. So
On 7/25/13 11:27 AM, Leo Meyerovich wrote:
Think of it like GC: many little nurseries and an occasional compaction.
OK, so movable DOM nodes. That would be interesting to try...
especially if we're already doing movable DOM nodes because they're in
the GC heap.
-Boris
Something else that I forgot to mention during the discussion earlier
today: do we need to worry about the subject indicator stuff Selectors 4
is adding? Or is that not an issue for rendering/style for now? The
spec discussion is ... unclear.
-Boris
On 7/15/13 3:05 PM, Josh Matthews wrote:
https://github.com/mozilla/servo/wiki/Meeting-2013-07-15
Some comments on the discussion (sorry I couldn't make the meeting, and
thank you for the notes!):
1) Mutable prototypes will be supported in SpiderMonkey (and indeed
are), but they will
On 7/12/13 7:45 PM, Patrick Walton wrote:
2. Use the JS GC for wrapped objects and reference counting for
non-wrapped objects. This assumes there are no cycles between them,
which I believe to be the case (though could be wrong)
If we can have both wrapped and unwrapped DOM nodes, I don't see
On 7/12/13 10:09 PM, Boris Zbarsky wrote:
Option 4 is to go with a GC and CC setup and refcounting on the Rust
side, I guess.
Though the developer experience of CC is not that great, to be honest.
What would implenentation of a DOM object that ends up not fitting in 18
64-bit words look like
On 6/28/13 4:58 PM, Simon Sapin wrote:
* Different rules can use the same selector. Map unique selectors each
to a list of rules, so that identical selectors do not need to be
matched more than once.
That's an interesting idea; it's worth measuring how often this is
useful in practice
On 2/14/13 5:33 PM, Brian Anderson wrote:
* FFI stack switching - https://github.com/mozilla/servo/issues/278
* FFI virtual calls - https://github.com/mozilla/servo/issues/278
* DOM representation - https://github.com/mozilla/servo/issues/280
* string representation -
On 2/13/13 11:19 PM, Patrick Walton wrote:
Servo now ships a known-working version of Rust, so it should be easier
to build.
Ah, excellent. I should try again!
Fixing this will require the
scheduler rewrite that brson is currently working on. As per the current
plan for the rewrite, content
I vaguely recall some discussion on this going by. If people haven't
already seen it, I recommend reading
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.planning/CrwdQkJRfEM
-Boris
___
dev-servo mailing list
jdm mentioned that he's working on DOM bindings again, so I wanted to
write down the things that we've run into as performance or usability
gotchas in Gecko bindings so far.
Performance:
1) For interface types, one needs a very fast way to unwrap them to
some sort of object you can call
On 10/24/12 7:04 PM, Robert O'Callahan wrote:
Couldn't we replace the original with a proxy that forwards to the new
object?
For access from JS that's exactly what we'll do.
The question is what happens for access from Rust.
-Boris
___
dev-servo
71 matches
Mail list logo
