Content Team planning.
Johnny Stenback
The members of the content team got together last week to discuss the
various big-ish tasks we'll be focusing on in the 3-9 months (and in
some case even farther out). The outcome of that meeting is in the
google spreadsheet located here:
http://spreadsheets.google.com/pub?key=pF_tMaWf14QywtyDtOwkzdg
While I initially meant to have our initial meeting in which only the
content team members participated be a fast one just to go over the
items and clean up the list enough for public consumption, we ended up
spending a fair bit of time on the items in the list. So things didn't
go as planned there.
Given that, I don't mind scheduling another meeting if there's direct
interest in it from others who were not present at the initial meeting,
but I don't think it's good use of our time to have another meeting
unless there's enough interest from others. So, if people disagree with
anything in the spreadsheet, want more information, or have specific
topics to add or change, please do reply and we'll schedule another
meeting if there's a need to do so.
--
jst
Clint Talbert
> http://spreadsheets.google.com/pub?key=pF_tMaWf14QywtyDtOwkzdg
> Given that, I don't mind scheduling another meeting if there's direct
> interest in it from others who were not present at the initial meeting,
> but I don't think it's good use of our time to have another meeting
> unless there's enough interest from others. So, if people disagree with
> anything in the spreadsheet, want more information, or have specific
> topics to add or change, please do reply and we'll schedule another
> meeting if there's a need to do so.
I don't think there is a need for a second meeting as yet, but I do have
some questions.
* HTML5 Parser -- What are we doing w.r.t. testing here? Writing the
entire HTML5 test suite seems a bit much, given the fluidity in that
spec, testing it with our current sets of HTML tests isn't going to be
enough. I have to admit I've only been following the fringes of Henri's
work here. How does this new parser degrade when it encounters a
non-HTML5 page? Does it just instantiate our old parser? Or does it
handle the non-HTML5 page itself?
* XBL2 -- I might be completely mistaken on this one, but here goes...
From the W3C CR, it seems that XBL2 is a technology more targeted at
content rather than chrome. I understand the desire to land it
"someplace safe" first, but how amenable will a "chrome-targeted"
implementation be to being moved into content? Do we have any
information on what chrome-XBL2 will be able to do that content-XBL2
cannot? Likewise, is there a document that compares our current XBL
implementation to the XBL2 CR? That would help me better understand
what the scope and size of this is, so I can better help plan testing
for it.
* Concurrency testing framework - we spoke about this the other day.
I didn't realize we were talking about CHESS. Does cgj have a wiki page
up on that yet, or a link to his prototype?
* DocShell test infrastructure work - sounds cool. What is it?
Thanks for posting this,
Clint
Boris Zbarsky
> * HTML5 Parser -- What are we doing w.r.t. testing here? Writing the
> entire HTML5 test suite seems a bit much, given the fluidity in that
> spec, testing it with our current sets of HTML tests isn't going to be
> enough. I have to admit I've only been following the fringes of Henri's
> work here. How does this new parser degrade when it encounters a
> non-HTML5 page? Does it just instantiate our old parser? Or does it
> handle the non-HTML5 page itself?
There are actually existing HTML5 parsing tests that we can use here, I
believe. And the point of HTML5 parsing is to be compatible with the
web as it exists now, so the parser would be used for everything.
> * XBL2 -- I might be completely mistaken on this one, but here goes...
> From the W3C CR, it seems that XBL2 is a technology more targeted at
> content rather than chrome.
Of course. There is no concept of "chrome" on the web... That said, is
there a particular problem you see in terms of using this for our chrome?
> Do we have any
> information on what chrome-XBL2 will be able to do that content-XBL2
> cannot?
Good question.
> Likewise, is there a document that compares our current XBL
> implementation to the XBL2 CR?
Not really, at least in part because there are parts of our current XBL
implementation that no one understands.
> That would help me better understand
> what the scope and size of this is, so I can better help plan testing
> for it.
Jonas should field this....
> * DocShell test infrastructure work - sounds cool. What is it?
I'm not sure what you're asking.
-Boris
Dao
> * HTML5 Parser -- What are we doing w.r.t. testing here? Writing the
> entire HTML5 test suite seems a bit much, given the fluidity in that
> spec, testing it with our current sets of HTML tests isn't going to be
> enough. I have to admit I've only been following the fringes of Henri's
> work here. How does this new parser degrade when it encounters a
> non-HTML5 page? Does it just instantiate our old parser? Or does it
> handle the non-HTML5 page itself?
My understanding is that there's only one HTML, and the HTML5 standard
defines all of it. Note that the spec defines things like "Parsing HTML
documents" rather than "Parsing HTML 5.0 documents".
Benjamin Smedberg
>> Do we have any information on what chrome-XBL2 will be able to do that
>> content-XBL2 cannot?
>
> Good question.
The XBL2 specification is designed so that a "chrome binding" could have
privileges greater than the page it is attached to, and can hide itself
completely from that page.
But I think that initially the goal is to avoid exposing XBL2 to the web
until we have a complete implementation and have done thorough security
reviews and fuzzing. We can expose it to chrome with much less thorough reviews.
>> Likewise, is there a document that compares our current XBL
>> implementation to the XBL2 CR?
>
> Not really, at least in part because there are parts of our current XBL
> implementation that no one understands.
XBL2 is very different than XBL in terms of how it applies bindings, deals
with anonymous content insertions, and many other details. It doesn't really
make sense to have a comparison document, because just about everything
other than the basic purpose is different.
>> That would help me better understand what the scope and size of this
>> is, so I can better help plan testing for it.
XBL2 is a large project, and is going to need significant automatic test
coverage, a security audit, and a fuzzer.
--BDS
Clint Talbert
> Clint Talbert wrote:
>
> There are actually existing HTML5 parsing tests that we can use here, I
> believe. And the point of HTML5 parsing is to be compatible with the web
> as it exists now, so the parser would be used for everything.
some quick searches before writing the message didn't turn up very much.
Do we have any links to these?
>
>> * XBL2 -- I might be completely mistaken on this one, but here goes...
>> From the W3C CR, it seems that XBL2 is a technology more targeted at
>> content rather than chrome.
>
> Of course. There is no concept of "chrome" on the web... That said, is
> there a particular problem you see in terms of using this for our chrome?
it into chrome with much less reviews etc and start testing. I worry
about potential security holes we might be creating for ourselves if we
take a chrome-implemented technology and put it into content. But as
bsmedburg also points out, that's why we'll need very good test coverage
here.
>> Likewise, is there a document that compares our current XBL
>> implementation to the XBL2 CR?
>
> Not really, at least in part because there are parts of our current XBL
> implementation that no one understands.
>
>
>> * DocShell test infrastructure work - sounds cool. What is it?
>
> I'm not sure what you're asking.
for this item because I haven't seen any mention of it previously. Here
are some better questions:
* Does this refer to a new test harness infrastructure?
* Or does this refer to a new test infrastructure built within one of
our existing test harnesses (i.e. the way Jonas created the XSS-XHR
tests with their own infrastructure within mochitest is an example of this)?
* Will creating this need changes in the existing test harnesses to
better accommodate such testing?
Thanks,
Clint
Clint Talbert
> On 3/19/09 4:41 PM, Boris Zbarsky wrote:
>
>
> The XBL2 specification is designed so that a "chrome binding" could have
> privileges greater than the page it is attached to, and can hide itself
> completely from that page.
>
> But I think that initially the goal is to avoid exposing XBL2 to the web
> until we have a complete implementation and have done thorough security
> reviews and fuzzing. We can expose it to chrome with much less thorough reviews.
>
> with anonymous content insertions, and many other details. It doesn't really
> make sense to have a comparison document, because just about everything
> other than the basic purpose is different.
>
-- Clint
Boris Zbarsky
>> There are actually existing HTML5 parsing tests that we can use here, I
>> believe. And the point of HTML5 parsing is to be compatible with the web
>> as it exists now, so the parser would be used for everything.
> That makes sense. I thought that I had seen such parsing tests, but
> some quick searches before writing the message didn't turn up very much.
> Do we have any links to these?
Henri Sivonen is the right man to ask here.
> My concern here is security. As bsmedburg points out later, we can get
> it into chrome with much less reviews etc and start testing. I worry
> about potential security holes we might be creating for ourselves if we
> take a chrome-implemented technology and put it into content. But as
> bsmedburg also points out, that's why we'll need very good test coverage
> here.
Sure. To be brutally frank, we'd have to try hard to be more insecure
than the current XBL implementation.... XBL2 is in fact designed with
non-chrome use in mind, whereas our current XBL is very much not.
>>> * DocShell test infrastructure work - sounds cool. What is it?
>>
>> I'm not sure what you're asking.
> I should have been more clear. I was basically asking what the plan is
> for this item because I haven't seen any mention of it previously. Here
> are some better questions:
> * Does this refer to a new test harness infrastructure?
> * Or does this refer to a new test infrastructure built within one of
> our existing test harnesses (i.e. the way Jonas created the XSS-XHR
> tests with their own infrastructure within mochitest is an example of
> this)?
> * Will creating this need changes in the existing test harnesses to
> better accommodate such testing?
Ah. I was thinking basically of working within the mochichrome harness
and creating a helper script file that would let me factor out common
test patterns for docshell tests (e.g. having to check for bfcache
status on all navigations, etc). Ideally we'd change mochichrome so it
actually runs in a chrome docshell too, but there's an existing bug on this.
-Boris
Mike Beltzner
Thanks for sharing the list - I agree that there's probably no need
for another meeting to discuss prioritization, but it would be great
(from my perspecitve, at least) to have a better understanding of:
- what each of these items gives, in terms of benefit, to Mozilla
stakeholders (platform consumers, product consumers, web community)
- what the expected costs are of these items (time, web
compatibility, platform compatibility, risk of regression)
- why the assigned priorities were decided on (requirements from
consumers, competitive landscape, etc)
That would help me, I think, to understand the prioritization. I'm not
looking for a huge write-up, just some additional context.
Also: I'm very curious to know what analyses and tasks can be
undertaken to keep on top of rendering speed and ensure that we're
optimising and engineering to remain competitive there.
cheers,
mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Christopher Blizzard
> Hey Johnny,
>
> Thanks for sharing the list - I agree that there's probably no need for
> another meeting to discuss prioritization, but it would be great (from my
> perspecitve, at least) to have a better understanding of:
>
> - what each of these items gives, in terms of benefit, to Mozilla
> stakeholders (platform consumers, product consumers, web community)
Yeah, just to echo this here. I'm trying to find more things to start
putting here for external web-developer and addon-developer audiences:
https://wiki.mozilla.org/Evangelism/DeveloperRoadmap
Some of this list touches on that (plugins, location.replace(), HTML5
parser, DOMParser work, pipelining, HTTP trailer (?)) but it's not
clear what's "what we want to have" and "what we will have." That
would help us a lot in describing our future roadmap to developers.
Just wondering what that process will look like. Will it be during
the upcoming all-hands?
--Chris
Jonas Sicking
>> From the W3C CR, it seems that XBL2 is a technology more targeted at
>> content rather than chrome.
>
> Of course. There is no concept of "chrome" on the web... That said, is
> there a particular problem you see in terms of using this for our chrome?
When implementing XBL2, the goal is to generally implement it such that
it could be exposed to content. So it won't be implemented as a chrome
technology that we then expose to the web.
That said, we'll definitely need to do a lot of testing, like fuzzing,
before we expose it to the web. There might also be some corners that
we'll knowingly and temporarily cut in order to meet deadlines and get
testing etc. But the key word there is temporarily, the overall goal is
for this to be safe to be exposed on the web.
>> Do we have any information on what chrome-XBL2 will be able to do that
>> content-XBL2 cannot?
>
> Good question.
Two things that I can think of off the top of my head are:
1. Binary XBL bindings. I.e. we might want to allow binary code to
implement the API that the binding adds to an element. Similar to how
XTF works.
2. "Permanent bindings", i.e. bindings that stick to a node even when
moved between documents.
3. Chrome privileged bindings. Bindings whose script run with chrome
level access.
Note that all of the above, especially the last, is things that can have
scary security implications. We're not going to do any of it without a
proper security review as we're well aware of the risks (don't want this
thread to turn into a flame war).
Generally this is stuff that XBL2 does not define, since it only
attempts to define things for the web, i.e. content-xbl. So we are
pretty free to innovate as we please to fit our needs.
>> Likewise, is there a document that compares our current XBL
>> implementation to the XBL2 CR?
>
> Not really, at least in part because there are parts of our current XBL
> implementation that no one understands.
Like Benjamin said, there's very little between XBL1 and XBL2 that is
similar, other than the goal. A document that describes the differences
would basically be the full XBL2 spec minus the "goals and requirements"
section.
>> That would help me better understand what the scope and size of this
>> is, so I can better help plan testing for it.
>
> Jonas should field this....
It's too early for me to have any estimates here. Basically the test
plan consists of "expose to chrome first and once we have tested and
implemented enough, expose to content".
/ Jonas
Samuel Sidler
> Given that, I don't mind scheduling another meeting if there's
> direct interest in it from others who were not present at the
> initial meeting, but I don't think it's good use of our time to have
> another meeting unless there's enough interest from others. So, if
> people disagree with anything in the spreadsheet, want more
> information, or have specific topics to add or change, please do
> reply and we'll schedule another meeting if there's a need to do so.
After thinking a bit about it, there's a few questions I had:
First, how do we plan to test each of these features? For some or most
of them, it might be pretty obvious, but regardless it'd help if the
spreadsheet listed what test infrastructure is going to be used to
test each feature and if a new bit of test infrastructure will be
needed. In the cases of a new test infrastructure, I definitely want
us to think out what needs to be tested and how we're going to do it.
Writing new code with no tests would suck. ;)
Secondly, and related, what security-related testing will be needed
for each of these features? I'm thinking along the line of new fuzzers
(as someone mentioned for XBL2) and security reviews among other
things. (Can we do security reviews prior to writing code as well as
afterwards?)
Finally, can you estimate how long it will take to complete these
features (including time for bug fixes, regression fixes, etc)? Even
if it's off by a lot I think it'd help in estimating the scope of each
of these features and hopefully ensuring we don't try to do too much
in whatever schedule we make for 1.9.2.
Thanks,
-Sam
Damon Sicore
Yes, actually right after (the 2 days immediately after) the all-
hands, we'll be working through these lists of work items, and filling
in as many details as possible. Lots of great ideas in this thread
wrt context, value, and prioritization. We're working directly
towards "what we will have."
Maybe we could use the:
https://wiki.mozilla.org/Evangelism/DeveloperRoadmap
page as an output for the meetings? Blizzard, does it make sense to
add specific questions/sections (i.e., "who's the consumer/stakeholder/
etc.?" "what's the value?" etc.) to the Developer Roadmap? If we
have a list of questions that need answers before we go into the
planning sessions, that would probably help. What do you think?
Damon
>
>
> --Chris
Christopher Blizzard
> Yes, actually right after (the 2 days immediately after) the all-hands,
> we'll be working through these lists of work items, and filling in as many
> details as possible. Lots of great ideas in this thread wrt context, value,
> and prioritization. We're working directly towards "what we will have."
>
> Maybe we could use the:
>
> https://wiki.mozilla.org/Evangelism/DeveloperRoadmap
>
> page as an output for the meetings? Blizzard, does it make sense to add
> specific questions/sections (i.e., "who's the consumer/stakeholder/etc.?"
> "what's the value?" etc.) to the Developer Roadmap? If we have a list of
> questions that need answers before we go into the planning sessions, that
> would probably help. What do you think?
>
Sadly, I won't be around for those two days due to a previous family engagement.
However, that URL would be perfect. Remember that it's
audience-specific. If it affects web developers in a real way I think
that things should end up there. For example, HTML5 support, new CSS
items, fixes for interfaces exposed through JavaScript, etc - all of
that should end up in there. Internal changes that don't affect how
developers interact with us probably isn't all that interesting for
that list.
Basically I'm interested in taking the stuff that bz, roc and dbaron
post in their personal blogs and trying to make it coherent in between
releases - and maybe even be able to predict the future a little bit
as well.
--Chris
Boris Zbarsky
> However, that URL would be perfect. Remember that it's
> audience-specific. If it affects web developers in a real way I think
> that things should end up there. For example, HTML5 support, new CSS
> items, fixes for interfaces exposed through JavaScript, etc - all of
> that should end up in there. Internal changes that don't affect how
> developers interact with us probably isn't all that interesting for
> that list.
So this is different from our web-tech blog in that we want to add
things to this list while we're still planning them, right?
-Boris
Christopher Blizzard
I'd like to have a place where we can get these features listed before
we do them so people understand the choices that we're making for our
next release. The blog is nice, but it's not the same as a
well-maintained roadmap.
--Chris
Stuart Parmenter
> Hello all,
Hi guys,
I would really like to see something related to really improving
responsiveness via content sink changes. There are some possibly
smaller-term fixes that could help, but I know Jonas had some ideas on
bigger changes that could help even more.
stuart
Damon Sicore
Stuart and Jonas, I'd like to hear what these are. Care to elaborate?
>
>
> stuart
Jonas Sicking
>
> On Mar 31, 2009, at 8:41 PM, Stuart Parmenter wrote:
>
>> On Mar 18, 11:13 pm, Johnny Stenback <j...@mozilla.com> wrote:
>>> Hello all,
>>
>>
>> Hi guys,
>>
>> I would really like to see something related to really improving
>> responsiveness via content sink changes. There are some possibly
>> smaller-term fixes that could help, but I know Jonas had some ideas on
>> bigger changes that could help even more.
>
> Stuart and Jonas, I'd like to hear what these are. Care to elaborate?
What needs to be done here is to rewrite how the contentsink is
inserting content. And also rewrite how that interacts with layout
flushing the work its doing to display the content.
A lot of this changes once we do off-main-thread parsing so I've been
somewhat inclined to wait for that to get a bit further along before
starting to write code.
Right now we parse a bunch of stuff, and flush layout every so often,
and then return to the main event loop. But I *think* while we're doing
this we've batched up a bunch of work that needs to be done before we
can process user events. So even though we look at the time and
determine that we need to return to the main even loop, before we can
process user input we end up having to do a bunch more work.
Specifically, the work that we've batched up is content notifications
(which cause frame construction), as well as layout reflow.
What we should do here is to think through how we want this all to tie
together in order to both parse quickly and stay responsive. And make
sure that content and layout work in harmony to accomplish this.
/ Jonas
Damon Sicore
Well, we have a specific goal this quarter to improve responsiveness
w/ multi-core ( https://wiki.mozilla.org/Platform/2009-Q2-
Goals#Content ). So, It sounds like it would help if we listed these
items out, get bugs for them, and identify a few that would help with
this goal. It would be even better if we improved responsiveness
regardless of multiple cores, so this would be a win-win if we could
get some of this work done in parallel to off-main-thread parsing
(NPI). What do you think?
>
>
> / Jonas
Jonas Sicking
> for them, and identify a few that would help with this goal. It would
> be even better if we improved responsiveness regardless of multiple
> cores, so this would be a win-win if we could get some of this work done
> in parallel to off-main-thread parsing (NPI). What do you think?
Hmm.. I'm not sure why we ended up with a goal for "responsiveness with
multi-core". I missed that that was what it said when we were reviewing
the goals. Mentally I was thinking we have a goal for *performance* with
multi-core, and that's what all the sub-goals are helping with. I think
that was what we meant when we were writing the goal.
But adding a separate goal regarding responsiveness would be a very good
idea.
/ Jonas
Christopher Blizzard
> But adding a separate goal regarding responsiveness would be a very good
> idea.
>
I'm hoping that this is understood as a goal within everyone's groups
right now. How long it takes to respond to a click to how long
startup takes to how long parses block the UI to getting us ready for
mobile - a lot of stuff is riding on this one concept.
--Chris
Henri Sivonen
Clint Talbert <ctal...@mozilla.com> wrote:
> On 3/19/09 1:41 PM, Boris Zbarsky wrote:
> > Clint Talbert wrote:
> >
> > There are actually existing HTML5 parsing tests that we can use here, I
> > believe. And the point of HTML5 parsing is to be compatible with the web
> > as it exists now, so the parser would be used for everything.
> That makes sense. I thought that I had seen such parsing tests, but
> some quick searches before writing the message didn't turn up very much.
> Do we have any links to these?
HTML5 parsing tests live in the svn repo of the html5lib project.
https://html5lib.googlecode.com/ (currently down)
The current setup is that the Java version of the HTML5 parser passes
the tests and the automatic translation to C++ is merely assumed not to
break stuff. Going forward, the plan is to make the C++ version run the
tree builder tests using the framework that is already in m-c. (Making
the C++ version run the tokenizer tests, too, would require more test
harness code. Perhaps that's ahead, too, but later.)
On another topic in this thread: The HTML5 parser batches insertions and
notifications.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/