Nabble - Webkit

Re: appendChild does not work for elements produced by DOMParser

2009-11-30T07:20:27Z

2009/11/30 Maciej Stachowiak <mjs@...>:

>...
> Probably because parsing with DOMParser parses as XML, thus you get a 
> element that's not an HTML element (it is in the null namespace instead of
> the HTML namespace). To get an HTML p element you need to either do this:
>
> var str = " red;'>This is a test";
>
> or just use innerHTML or createContextualFragment to directly insert HTML
> text into a document.

Thank you, importNode works fine for my snippet given above.

But style information is omitted no matter whether xmlns attribute
specified or not.
This is because I was wrong about using
doc.documentElement.firstChild, I suppose doc.documentElement shall be
used instead:
var str = "This is a test";
var parser = new DOMParser();
var doc = parser.parseFromString(str, "text/xml");
document.body.appendChild(doc.documentElement);

And the fun thing is how different Gecko and WebKit(with the only
difference in added call to document.importNode) handle the code given
above.

Gecko:
Node inserted, text is visible but in black, e.g. style is still
omitted and Firebug indicates, that inserted element has no style
information, at the same time it indicates that style attribute exists
in the DOM tree.

WebKit:
Node inserted but in the strange way. Text content is not visible on
the screen. WebInspector indicates that new node exists in the DOM
tree but without it's content and closing tag and with xmlns and style
attributes.

I believe that this is because I'm playing with DOMParser in the wrong way.
Could you please clarify what is the error here?

>
> Regards,
> Maciej
>
>

--
Best regards,
Alexander Shabanov
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: appendChild does not work for elements produced by DOMParser

2009-11-30T04:58:50Z

On Nov 30, 2009, at 3:17 AM, Alexander Shabanov wrote:

> Hi all,
>
> Sorry for silly question but I think that it might be a nice feature
> to webkit.
> The following code works in Mozilla Firefox 3.5, but it does not work
> in webkit-based browsers:
>
> var parser = new DOMParser();
> var str = "This is a test";
> var doc = parser.parseFromString(str, "text/xml");
> document.body.appendChild(doc.documentElement.firstChild);

If you change the last step to this, it will work in WebKit-based
browsers:

document
.body.appendChild(document.importNode(doc.documentElement.firstChild));

The Gecko engine is more generous about allowing implicit cross-
document adoption. We allow it in only a few cases, and in theory it
is not supposed to be allowed at all (without the importNode call)
according to the DOM Core spec. That being said, if this is a compat
issue on real sites we can change to be more Gecko-like.

>
> I found that specification to DOMParser does not guarantee that the
> result of DOMParser's parseFromX methods can
> be directly used in the original document.
> Nevertheless I believe that it would be quite a useful feature, at
> least it won't require JS code to create DOM-compliant content from
> the parsed one.
> May be I missed something and webkit offers a way of quick adaptation
> of the parsed content to the original DOM tree?
> Thanks in advance.
>
> P.S.: even though Firefox provides such a feature, a style
> specification in the following code will take no effect:
> var parser = new DOMParser();
> var str = "This is a test";
> var doc = parser.parseFromString(str, "text/xml");
> document.body.appendChild(doc.documentElement.firstChild);

Probably because parsing with DOMParser parses as XML, thus you get a
 element that's not an HTML element (it is in the null namespace
instead of the HTML namespace). To get an HTML p element you need to
either do this:

var str = "This is a test";

or just use innerHTML or createContextualFragment to directly insert
HTML text into a document.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

appendChild does not work for elements produced by DOMParser

2009-11-30T03:17:26Z

Hi all,

Sorry for silly question but I think that it might be a nice feature to webkit.
The following code works in Mozilla Firefox 3.5, but it does not work
in webkit-based browsers:

var parser = new DOMParser();
var str = "This is a test";
var doc = parser.parseFromString(str, "text/xml");
document.body.appendChild(doc.documentElement.firstChild);

I found that specification to DOMParser does not guarantee that the
result of DOMParser's parseFromX methods can
be directly used in the original document.
Nevertheless I believe that it would be quite a useful feature, at
least it won't require JS code to create DOM-compliant content from
the parsed one.
May be I missed something and webkit offers a way of quick adaptation
of the parsed content to the original DOM tree?
Thanks in advance.

P.S.: even though Firefox provides such a feature, a style
specification in the following code will take no effect:
var parser = new DOMParser();
var str = "This is a test";
var doc = parser.parseFromString(str, "text/xml");
document.body.appendChild(doc.documentElement.firstChild);

--
Best regards,
Alexander Shabanov
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-29T23:11:52Z

fwiw, I'm not aware of any bad error reports that people are hitting in practice although as Adam mentioned it is possible for various reasons. If we hit any incorrect warnings with any frequency, we should disable them or fix them.

Of course, there are a lots of WebKit style guidelines that it doesn't catch.

> One basic reason the script isn't perfect is that it's doesn't have a
> full C++ / Objective-C++ parser.

If we could go this route, would we prefer it?

It may be a really good thing. It would depend on how complicated the tool/code got. As far as this tool goes, it is derived from an open source version of what Google uses in house and then originally adapted for WebKit by Shinichiro Hamaji. It primarily relies on regex. In the past I wrote a closed source tool that used a parser to do style fixes in lots of ways, and I appreciated the exactness of the results.

One nice thing about the current code is that it is pretty accessible to new folks. I don't think that was as true of the tool I wrote on top of the parser which examined and manipulated syntax trees.

Dave

PS In fact, some checks by various folks in WebKit were made to catch less things in order to avoid false negatives because noisy incorrect tools are just annoying (and imo frequently are justifiably ignored).

On Sun, Nov 29, 2009 at 5:55 PM, Adam Barth <abarth@...> wrote:

Yeah, I think improving the script would be great. I'm not actually
an expert on how it works internally, but I think David Levin is.
It's easy for the bot to pass a flag to the script if that would be
helpful. In general, I think we should give it a try and iterate to
remove the biggest pain points.

Thanks!
Adam

On Sun, Nov 29, 2009 at 5:00 PM, Chris Jerdonek

<chris.jerdonek@...> wrote:
> On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth <abarth@...> wrote:
>
>> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek
>> <chris.jerdonek@...> wrote:
>>> On Sat, Nov 28, 2009, Adam Barth wrote:
>>>> Hopefully, the script will improve over time, but it will
>>>> never be perfect.
>>>
>>> Can you elaborate on this? For example, are you saying there is a
>>> basic reason that the script will always have bugs? Without knowing
>>> too much about the script, it seems like it wouldn't be too hard to at
>>> least make the false negatives go away. Or are you simply saying that
>>> the guidelines and script will never fully capture what we mean by
>>> "correct style"?
>>
>> Does this mean you're volunteering to remove all the false positives
>> and false negatives? :)
>
> I was hoping to work on the script eventually, which is partly why I
> asked for elaboration.
>
> All that I meant above is that one could potentially disable (for the
> bot) the style tests that report false violations, or else reduce
> their confidence score. That way, if the style bot flags a patch, it
> is guaranteed to be meaningful without looking at the details of the
> report. This can only be done, though, if the problems with the
> script are not so basic that they affect most or many of the tests.
>
> (The reverse is not as straightforward, though. It does not seem as
> easy to change the script -- in a useful way -- so that if it reports
> that a patch has met the guidelines, then the patch really meets the
> guidelines.)
>
>> One basic reason the script isn't perfect is that it's doesn't have a
>> full C++ / Objective-C++ parser.
>
> If we could go this route, would we prefer it?
>
> --Chris
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-29T17:55:32Z

Yeah, I think improving the script would be great. I'm not actually
an expert on how it works internally, but I think David Levin is.
It's easy for the bot to pass a flag to the script if that would be
helpful. In general, I think we should give it a try and iterate to
remove the biggest pain points.

Thanks!
Adam

On Sun, Nov 29, 2009 at 5:00 PM, Chris Jerdonek
<chris.jerdonek@...> wrote:

> On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth <abarth@...> wrote:
>
>> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek
>> <chris.jerdonek@...> wrote:
>>> On Sat, Nov 28, 2009, Adam Barth wrote:
>>>> Hopefully, the script will improve over time, but it will
>>>> never be perfect.
>>>
>>> Can you elaborate on this? For example, are you saying there is a
>>> basic reason that the script will always have bugs? Without knowing
>>> too much about the script, it seems like it wouldn't be too hard to at
>>> least make the false negatives go away. Or are you simply saying that
>>> the guidelines and script will never fully capture what we mean by
>>> "correct style"?
>>
>> Does this mean you're volunteering to remove all the false positives
>> and false negatives? :)
>
> I was hoping to work on the script eventually, which is partly why I
> asked for elaboration.
>
> All that I meant above is that one could potentially disable (for the
> bot) the style tests that report false violations, or else reduce
> their confidence score. That way, if the style bot flags a patch, it
> is guaranteed to be meaningful without looking at the details of the
> report. This can only be done, though, if the problems with the
> script are not so basic that they affect most or many of the tests.
>
> (The reverse is not as straightforward, though. It does not seem as
> easy to change the script -- in a useful way -- so that if it reports
> that a patch has met the guidelines, then the patch really meets the
> guidelines.)
>
>> One basic reason the script isn't perfect is that it's doesn't have a
>> full C++ / Objective-C++ parser.
>
> If we could go this route, would we prefer it?
>
> --Chris
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-29T17:00:59Z

On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth <abarth@...> wrote:

> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek
> <chris.jerdonek@...> wrote:
>> On Sat, Nov 28, 2009, Adam Barth wrote:
>>> Hopefully, the script will improve over time, but it will
>>> never be perfect.
>>
>> Can you elaborate on this? For example, are you saying there is a
>> basic reason that the script will always have bugs? Without knowing
>> too much about the script, it seems like it wouldn't be too hard to at
>> least make the false negatives go away. Or are you simply saying that
>> the guidelines and script will never fully capture what we mean by
>> "correct style"?
>
> Does this mean you're volunteering to remove all the false positives
> and false negatives? :)

I was hoping to work on the script eventually, which is partly why I
asked for elaboration.

All that I meant above is that one could potentially disable (for the
bot) the style tests that report false violations, or else reduce
their confidence score. That way, if the style bot flags a patch, it
is guaranteed to be meaningful without looking at the details of the
report. This can only be done, though, if the problems with the
script are not so basic that they affect most or many of the tests.

(The reverse is not as straightforward, though. It does not seem as
easy to change the script -- in a useful way -- so that if it reports
that a patch has met the guidelines, then the patch really meets the
guidelines.)

> One basic reason the script isn't perfect is that it's doesn't have a
> full C++ / Objective-C++ parser.

If we could go this route, would we prefer it?

--Chris
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Platform API for Uniscribe/ComplexTextController?

2009-11-29T10:27:07Z

Hi all,

The wx port is starting to look at getting proper support for complex text, and one of the first places I started looking at was the Win and Mac port implementations. I noticed that the complex text code in FontWin.cpp and FontComplexTextMac.cpp is largely the same, passing the heavy lifting down to their respective complex text controllers, and I actually wondered if they could be merged if there were some tweaks to the APIs to make them compatible.

That led me to wonder if we couldn't make ComplexTextController one of our platform classes and have USE() defines to determine the implementation. Then we could move the drawComplexText, floatWidthForComplexText, and offsetForPositionForComplexText into Font.cpp guarded by that USE() define. The wx port can provide the native font handles the Win/Mac controllers need, so it'd really be great if we could just add these into our build to get complex text support working without having to implement the complex text methods differently for each platform.

BTW, I actually already did get UniscribeController compiling, actually, but on Windows I had to have the build script copy it to platform/graphics/wx because MSVC implicitly puts the current directory first on the path, which was causing it to pick up platform/graphics/win/FontPlatformData.h instead of the wx one when compiling that file. :( So that's something else that would need to be addressed if ports can start sharing these files.

Thanks,

Kevin

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: HTML Layers above plugin

2009-11-29T10:07:22Z

On Sun, Nov 29, 2009 at 7:11 AM, Andre-John Mas <ajmas@...> wrote:
> I am currently investigating the possibility of using a web container for an HTPC system. As part of the design I am looking at is to use the multiple tab views to embed the necessary elements. One would concentrate on the menu and another on the embedded player (via plugin). For the view showing the plug-in I have two approaches that I am looking at, where is either work with with plug-in developers to add the necessary chrome needed to display the play various information or to somehow overlay 'controls' in HTML.
>
> If I do create a layer with a z-index above the video plugin it will get obstructed by the plugin. On the other hand I am able to hide the layer with the plug-in without any issue. Is there are a way to draw HTML above the plugin? If not is there any technical reason why something like this could not be implemented?

This is a web development question and probably not appropriate for
this list, but:
- If the plugin is windowed, consulting your favorite search engine
for [iframe shim] will put you on the right track.
- If the plugin supports windowless mode, it layers like a normal HTML
element. E.g. see [flash wmode] for discussion of this for Flash.
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-29T09:35:05Z

On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek
<chris.jerdonek@...> wrote:
> On Sat, Nov 28, 2009, Adam Barth wrote:
>> A1: Unfortunately, no. First of all, check-webkit-style has false
>> negatives.
>
> It seems like this answers the different question, "If the style-queue
> complains, does that mean my patch has incorrect style?"

Yes, that too. I would call that a false positive, but you're right
that check-webkit-style probably has both kinds of bugs.

>> Hopefully, the script will improve over time, but it will
>> never be perfect.
>
> Can you elaborate on this? For example, are you saying there is a
> basic reason that the script will always have bugs? Without knowing
> too much about the script, it seems like it wouldn't be too hard to at
> least make the false negatives go away. Or are you simply saying that
> the guidelines and script will never fully capture what we mean by
> "correct style"?

Does this mean you're volunteering to remove all the false positives
and false negatives? :)

One basic reason the script isn't perfect is that it's doesn't have a
full C++ / Objective-C++ parser. I think it uses regular expressions.
Anyway, I just wanted to set expectations that the tool might not be
perfect.

Adam
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-29T09:26:49Z

On Sat, Nov 28, 2009, Adam Barth wrote:

> One of the bots that Eric and I have been working on is about to come
> online. This bot is a "style bot" that runs check-webkit-style on
> patches that have been nominated for review.

This seems like a good effort, thanks. A couple minor comments below
on the first question in your FAQ:

> == Frequently Asked Questions ==
>
> Q1: If the style-queue doesn't complain, does that mean my patch has
> correct style?
>
> A1: Unfortunately, no. First of all, check-webkit-style has false
> negatives.

It seems like this answers the different question, "If the style-queue
complains, does that mean my patch has incorrect style?"

> Hopefully, the script will improve over time, but it will
> never be perfect.

Can you elaborate on this? For example, are you saying there is a
basic reason that the script will always have bugs? Without knowing
too much about the script, it seems like it wouldn't be too hard to at
least make the false negatives go away. Or are you simply saying that
the guidelines and script will never fully capture what we mean by
"correct style"?

> Second, the style-queue is only able to check
> patches that successfully download and apply to top-of-tree. If your
> patch does not apply to top-of-tree (e.g., because it depends on
> another patch), then style-queue won't say anything.

Thanks,
--Chris
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

localStorage quota limit

2009-11-29T08:38:21Z

All -

I've been discussing the localStorage quota limit over on this bug with Jeremy Orlow:

https://bugs.webkit.org/show_bug.cgi?id=31791

To recap from the discussions on that bug:

Jeremy has implemented the localStorage quota on the latest Webkit builds. This caused my usage of localStorage to fail, because as a JS programmer, I assumed that 5MB meant '5 million characters' of storage. This assumption holds true on Firefox 3.5.X+ and IE8, but fails on Webkit since it stores things into localStorage as UTF-16.

One option we discussed on that bug was getting the spec folks to alter the spec in one of three ways:

- specify the quota in terms of 'characters' (or Strings, or whatever) thereby abstracting away the encoding problem entirely.

- specify UTF-8 so that 'MB = characters'

- specify a JS API such that the encoding could be specified.

Jeremy wasn't too taken with any of these proposals, and in any case, they probably need to be taken up on the W3 group defining this stuff, not here.

In any case, as Jeremy states in Comment #5 of the bug report, "the spec's mentioning of 5mb is really just an example". And when I filed this bug on Mozilla's Bugzilla tracker:

https://bugzilla.mozilla.org/show_bug.cgi?id=461684

another comment there points out the same thing. (Note that this bug was originally filed to see if the Mozilla guys would raise their quota to 10MB to match IE8 and, since they don't use double-byte encoding, I was really asking for '10 million characters' there :-)).

Given that, an increase from 5MB to 10MB would 'solve my immediate problem'. And, without going back to the spec folks, I'm not sure that much more can be done here.

Jeremy wanted me to post to get the discussion started (and hopefully attain some consensus :-) ), so let's discuss :-).

Thanks in advance!

Cheers,

- Bill

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-29T08:26:00Z

Maybe in the case of failure, provide a link to further information?

Kenneth

On Sun, Nov 29, 2009 at 3:44 AM, Maciej Stachowiak <mjs@...> wrote:

On Nov 28, 2009, at 10:53 AM, Adam Barth wrote:

On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs@...> wrote:

On Nov 28, 2009, at 2:21 AM, Adam Barth wrote:

1) "Adding an extra flags is going to cause confusion." The
style-queue does not add any flags to Bugzilla. Instead of storing
it's state in Bugzilla flags (like commit-queue does), we built an
AppEngine web service to hold the queue's persistent state. Instead
of indicating style errors with a negative flag, the bot adds a
comment to the bug.

It does seem that flags are noisy in an unappealing way, but it would be
much better (IMO) to store this information in the bugzilla database instead
of externally. Is there any way we can do that?

>From an implementation point of view, either way is easy now that
we've got the infrastructure built. It's a question of which you'd
prefer.

Could we make a flag that is
hidden in the default UI, or use specially formatted comments that the bot
knows how to recognize?

>From my point of view, a hidden flag could work. We considered
specially formatted comments, but that would make the bot more chatty.
For example, if the style-queue has some internal error that prevents
it from processing the patch, it wants to remember that, but it
doesn't want to spam the bug with that information.

I'm not sure representing all the state in Bugzilla is necessary. We
should represent the "most interesting" state (e.g., pass / fail)
there. For the rest, we can have a dashboard similar to
build.webkit.org that shows the status of various patches before they
are committed. I've started sketching something rough here:

http://webkit-commit-queue.appspot.com/static/details.html

Pass/fail status sounds fine to me. I agree that an error by the bot should not be highly visible in the bug, as that is not as useful to the review and submitter as Pass or Fail and Here's the Mistakes.

You can imagine clicking those squares to see the full log of what
happened. For example, if the build failed on Qt, you might want to
see the full output of build-webkit --qt, but we don't need to post
all that to Bugzilla. The comment might just say:

Looks like a decent design.

Patch 86912 did not build on Qt. Build log:
http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all

At a higher level, I'm sympathetic to Mark's concerns about what the
system will look like when we have a number of bots. Bugzilla flags
work well for receiving input from humans. There are lots of choices
for how to present output. For example, another option is to have a
bunch of colored squares next to each attachment that represent that
patch's row on the dashboard.

Adam

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

HTML Layers above plugin

2009-11-29T07:11:07Z

Hi,

I am currently investigating the possibility of using a web container for an HTPC system. As part of the design I am looking at is to use the multiple tab views to embed the necessary elements. One would concentrate on the menu and another on the embedded player (via plugin). For the view showing the plug-in I have two approaches that I am looking at, where is either work with with plug-in developers to add the necessary chrome needed to display the play various information or to somehow overlay 'controls' in HTML.

If I do create a layer with a z-index above the video plugin it will get obstructed by the plugin. On the other hand I am able to hide the layer with the plug-in without any issue. Is there are a way to draw HTML above the plugin? If not is there any technical reason why something like this could not be implemented?

André-John
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-28T22:44:52Z

On Nov 28, 2009, at 10:53 AM, Adam Barth wrote:

> On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs@...>
> wrote:
>> On Nov 28, 2009, at 2:21 AM, Adam Barth wrote:
>>> 1) "Adding an extra flags is going to cause confusion." The
>>> style-queue does not add any flags to Bugzilla. Instead of storing
>>> it's state in Bugzilla flags (like commit-queue does), we built an
>>> AppEngine web service to hold the queue's persistent state. Instead
>>> of indicating style errors with a negative flag, the bot adds a
>>> comment to the bug.
>>
>> It does seem that flags are noisy in an unappealing way, but it
>> would be
>> much better (IMO) to store this information in the bugzilla
>> database instead
>> of externally. Is there any way we can do that?
>
> From an implementation point of view, either way is easy now that
> we've got the infrastructure built. It's a question of which you'd
> prefer.
>
>> Could we make a flag that is
>> hidden in the default UI, or use specially formatted comments that
>> the bot
>> knows how to recognize?
>
> From my point of view, a hidden flag could work. We considered
> specially formatted comments, but that would make the bot more chatty.
> For example, if the style-queue has some internal error that prevents
> it from processing the patch, it wants to remember that, but it
> doesn't want to spam the bug with that information.
>
> I'm not sure representing all the state in Bugzilla is necessary. We
> should represent the "most interesting" state (e.g., pass / fail)
> there. For the rest, we can have a dashboard similar to
> build.webkit.org that shows the status of various patches before they
> are committed. I've started sketching something rough here:
>
> http://webkit-commit-queue.appspot.com/static/details.html

Pass/fail status sounds fine to me. I agree that an error by the bot
should not be highly visible in the bug, as that is not as useful to
the review and submitter as Pass or Fail and Here's the Mistakes.

>
> You can imagine clicking those squares to see the full log of what
> happened. For example, if the build failed on Qt, you might want to
> see the full output of build-webkit --qt, but we don't need to post
> all that to Bugzilla. The comment might just say:

Looks like a decent design.

>
> Patch 86912 did not build on Qt. Build log:
> http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all
>
> At a higher level, I'm sympathetic to Mark's concerns about what the
> system will look like when we have a number of bots. Bugzilla flags
> work well for receiving input from humans. There are lots of choices
> for how to present output. For example, another option is to have a
> bunch of colored squares next to each attachment that represent that
> patch's row on the dashboard.
>
> Adam

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-28T10:53:06Z

On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs@...> wrote:

> On Nov 28, 2009, at 2:21 AM, Adam Barth wrote:
>> 1) "Adding an extra flags is going to cause confusion." The
>> style-queue does not add any flags to Bugzilla. Instead of storing
>> it's state in Bugzilla flags (like commit-queue does), we built an
>> AppEngine web service to hold the queue's persistent state. Instead
>> of indicating style errors with a negative flag, the bot adds a
>> comment to the bug.
>
> It does seem that flags are noisy in an unappealing way, but it would be
> much better (IMO) to store this information in the bugzilla database instead
> of externally. Is there any way we can do that?

>From an implementation point of view, either way is easy now that
we've got the infrastructure built. It's a question of which you'd
prefer.

> Could we make a flag that is
> hidden in the default UI, or use specially formatted comments that the bot
> knows how to recognize?

>From my point of view, a hidden flag could work. We considered
specially formatted comments, but that would make the bot more chatty.
For example, if the style-queue has some internal error that prevents
it from processing the patch, it wants to remember that, but it
doesn't want to spam the bug with that information.

I'm not sure representing all the state in Bugzilla is necessary. We
should represent the "most interesting" state (e.g., pass / fail)
there. For the rest, we can have a dashboard similar to
build.webkit.org that shows the status of various patches before they
are committed. I've started sketching something rough here:

http://webkit-commit-queue.appspot.com/static/details.html

You can imagine clicking those squares to see the full log of what
happened. For example, if the build failed on Qt, you might want to
see the full output of build-webkit --qt, but we don't need to post
all that to Bugzilla. The comment might just say:

Patch 86912 did not build on Qt. Build log:
http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all

At a higher level, I'm sympathetic to Mark's concerns about what the
system will look like when we have a number of bots. Bugzilla flags
work well for receiving input from humans. There are lots of choices
for how to present output. For example, another option is to have a
bunch of colored squares next to each attachment that represent that
patch's row on the dashboard.

Adam
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: style-queue entering beta

2009-11-28T10:21:00Z

Sounds like a good idea in general. Some comments below:

On Nov 28, 2009, at 2:21 AM, Adam Barth wrote:

> One of the bots that Eric and I have been working on is about to come
> online. This bot is a "style bot" that runs check-webkit-style on
> patches that have been nominated for review. I'd like to ask your
> patience while we work out the kinks.
>
> You can skip the rest of this email if you're not interested in the
> nitty gritty.
>
> == Summary ==
>
> The primary goal of the style-queue is to reduce review latency by (1)
> giving immediate feedback to contributors and (2) making human
> reviewer more efficient by relieving them of mechanical tasks (like
> asking for tabs to be replaced with spaces).
>
> The style-queue scans the set of patches that are pending-review for
> new patches. When it finds a new patch, the bot runs
> check-webkit-style on the patch. If check-webkit-style finds style
> errors, the bot comments on the bug.
>
> == Social Contract ==
>
> The style-queue is purely informative. You're free to ignore it's
> comments. Ideally, the bot should be silent unless it has something
> interesting to say. If we decide that style-queue is too chatty, we
> can change check-webkit-style to report fewer errors.
>
> One corollary of this social contract is that the style-queue doesn't
> inform you when your patch passes the style check (because most
> patches should pass, right?). We can re-visit this design choice
> later if it turns out we really want to know when the check succeeds.

To actually relieve reviewers of the burden of manual style review, it
seems like the bot would have to record when a patch passes the style
check. Otherwise, how can you tell whether a patch has passed the
check, or if the bot just hasn't run on it yet? Would anyone object to
seeing the information that a patch has passed an automated style
check in a comment?

>
> == Response to Previous Feedback ==
>
> When I floated this idea on webkit-dev previously (in the "bot-filled
> future" thread), I got a bunch of useful feedback. Here's how we
> incorporated that feedback into the current design:
>
> 1) "Adding an extra flags is going to cause confusion." The
> style-queue does not add any flags to Bugzilla. Instead of storing
> it's state in Bugzilla flags (like commit-queue does), we built an
> AppEngine web service to hold the queue's persistent state. Instead
> of indicating style errors with a negative flag, the bot adds a
> comment to the bug.

It does seem that flags are noisy in an unappealing way, but it would
be much better (IMO) to store this information in the bugzilla
database instead of externally. Is there any way we can do that? Could
we make a flag that is hidden in the default UI, or use specially
formatted comments that the bot knows how to recognize?

>
> 2) "What machines are going to be doing these tests, and on which
> platforms?" The style-queue runs on a machine in my apartment that
> runs Mac OS X. The style-queue is platform independent, so this is
> less of an issue for style-queue than it is for a build-queue.
>
> 3) "Which patches would this test?" The style-queue tests any patch
> marked "review?". This design avoids the need for additional flags or
> indications that a patch should be run through the queue.
>
> 4) "Running tests on an arbitrary patches [opens a security hole]."
> Instead of running check-webkit-style from it's own working copy, the
> style-queue runs check-webkit-style from a separate working copy.
> While it's true you could haxor my machine by committing an evil copy
> of check-webkit-style, I'm already running that risk whenever I type
> "svn up".
>
> == Frequently Asked Questions ==
>
> Q1: If the style-queue doesn't complain, does that mean my patch has
> correct style?
>
> A1: Unfortunately, no. First of all, check-webkit-style has false
> negatives. Hopefully, the script will improve over time, but it will
> never be perfect. Second, the style-queue is only able to check
> patches that successfully download and apply to top-of-tree. If your
> patch does not apply to top-of-tree (e.g., because it depends on
> another patch), then style-queue won't say anything.
>
> Q2: How can I see whether style-queue processed my patch?
>
> A2: There isn't a great way to do this yet. The data is stored in the
> webkit-commit-queue.appspot.com web service, but we haven't built a
> front-end for it yet. If you have a strong stomach, you can look at
> the endpoint the bot itself uses
>
> http://webkit-commit-queue.appspot.com/patch-status/style-queue/12345
>
> where 12345 is the ID of your attachment. If you'd like to have a
> better status display, feel free to hack on
> WebKitTools/QueueStatusServer and send me or Eric patches to review.
> In the long term, there's no reason we can't have an awesome UI.
>
> Q3: This bot is going to run amock! How can I keep track of all it's
> evil deeds?
>
> A3: If you want to see what the bots are doing, you can subscribe to
> the following email list:
>
> http://groups.google.com/group/webkit-bot-watchers
>
> Whenever the bots touch a bug, they're supposed to add this address to
> the CC list. This functionality is very new, so we might not have
> every case covered yet. If you see the bot misbehaving, let me or
> Eric know. We'll correct the issue ASAP.
>
> Q4: Checking style is fine and dandy, but I was hoping for a build-
> queue!
>
> A4: My next project is to get a build-queue working for Qt. The
> build-queue will share a lot of infrastructure with the style-queue,
> but making the style-queue was easier because check-webkit-style is a
> lot faster than build-webkit. :)
>
> Q5: When are you flipping the switch?
>
> A5: Either today or tomorrow, depending on when I find a stretch of
> time to babysit the queue through whatever initial troubles it has.
> My working copy of the style-queue is about five patches ahead of
> trunk. It would be nice to have those patches committed before
> flipping the switch, but it's not necessary.
>
> Thanks for reading to the end, and I hope you find the style-queue
> useful.
>
> Adam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@...
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Why it is not possible to appendChild on elements created by DOMParser?

2009-11-28T03:16:26Z

style-queue entering beta

2009-11-28T02:21:38Z

One of the bots that Eric and I have been working on is about to come
online. This bot is a "style bot" that runs check-webkit-style on
patches that have been nominated for review. I'd like to ask your
patience while we work out the kinks.

You can skip the rest of this email if you're not interested in the
nitty gritty.

== Summary ==

The primary goal of the style-queue is to reduce review latency by (1)
giving immediate feedback to contributors and (2) making human
reviewer more efficient by relieving them of mechanical tasks (like
asking for tabs to be replaced with spaces).

The style-queue scans the set of patches that are pending-review for
new patches. When it finds a new patch, the bot runs
check-webkit-style on the patch. If check-webkit-style finds style
errors, the bot comments on the bug.

== Social Contract ==

The style-queue is purely informative. You're free to ignore it's
comments. Ideally, the bot should be silent unless it has something
interesting to say. If we decide that style-queue is too chatty, we
can change check-webkit-style to report fewer errors.

One corollary of this social contract is that the style-queue doesn't
inform you when your patch passes the style check (because most
patches should pass, right?). We can re-visit this design choice
later if it turns out we really want to know when the check succeeds.

== Response to Previous Feedback ==

When I floated this idea on webkit-dev previously (in the "bot-filled
future" thread), I got a bunch of useful feedback. Here's how we
incorporated that feedback into the current design:

1) "Adding an extra flags is going to cause confusion." The
style-queue does not add any flags to Bugzilla. Instead of storing
it's state in Bugzilla flags (like commit-queue does), we built an
AppEngine web service to hold the queue's persistent state. Instead
of indicating style errors with a negative flag, the bot adds a
comment to the bug.

2) "What machines are going to be doing these tests, and on which
platforms?" The style-queue runs on a machine in my apartment that
runs Mac OS X. The style-queue is platform independent, so this is
less of an issue for style-queue than it is for a build-queue.

3) "Which patches would this test?" The style-queue tests any patch
marked "review?". This design avoids the need for additional flags or
indications that a patch should be run through the queue.

4) "Running tests on an arbitrary patches [opens a security hole]."
Instead of running check-webkit-style from it's own working copy, the
style-queue runs check-webkit-style from a separate working copy.
While it's true you could haxor my machine by committing an evil copy
of check-webkit-style, I'm already running that risk whenever I type
"svn up".

== Frequently Asked Questions ==

Q1: If the style-queue doesn't complain, does that mean my patch has
correct style?

A1: Unfortunately, no. First of all, check-webkit-style has false
negatives. Hopefully, the script will improve over time, but it will
never be perfect. Second, the style-queue is only able to check
patches that successfully download and apply to top-of-tree. If your
patch does not apply to top-of-tree (e.g., because it depends on
another patch), then style-queue won't say anything.

Q2: How can I see whether style-queue processed my patch?

A2: There isn't a great way to do this yet. The data is stored in the
webkit-commit-queue.appspot.com web service, but we haven't built a
front-end for it yet. If you have a strong stomach, you can look at
the endpoint the bot itself uses

http://webkit-commit-queue.appspot.com/patch-status/style-queue/12345

where 12345 is the ID of your attachment. If you'd like to have a
better status display, feel free to hack on
WebKitTools/QueueStatusServer and send me or Eric patches to review.
In the long term, there's no reason we can't have an awesome UI.

Q3: This bot is going to run amock! How can I keep track of all it's
evil deeds?

A3: If you want to see what the bots are doing, you can subscribe to
the following email list:

http://groups.google.com/group/webkit-bot-watchers

Whenever the bots touch a bug, they're supposed to add this address to
the CC list. This functionality is very new, so we might not have
every case covered yet. If you see the bot misbehaving, let me or
Eric know. We'll correct the issue ASAP.

Q4: Checking style is fine and dandy, but I was hoping for a build-queue!

A4: My next project is to get a build-queue working for Qt. The
build-queue will share a lot of infrastructure with the style-queue,
but making the style-queue was easier because check-webkit-style is a
lot faster than build-webkit. :)

Q5: When are you flipping the switch?

A5: Either today or tomorrow, depending on when I find a stretch of
time to babysit the queue through whatever initial troubles it has.
My working copy of the style-queue is about five patches ahead of
trunk. It would be nice to have those patches committed before
flipping the switch, but it's not necessary.

Thanks for reading to the end, and I hope you find the style-queue useful.

Adam
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Why Page::setMainFrame use PassRefPtr type parameter?

2009-11-28T00:09:48Z

Look at this:void Page::setMainFrame(PassRefPtr<Frame> mainFrame).

Why use PassRefPtr? Infact,change to following will work same:

void Page::setMainFrame(Frame *mainFrame)

1).Look into the function source code:

m_mainFrame = mainFrame; --> call "operator=(T* optr)",reference count +1

It mean that if change to "Frame *mainFrame" ,will call mainFrame->ref();

2).Using "PassRefPtr<Frame> mainFrame":

m_mainFrame = mainFrame; --> call "operator=(const PassRefPtr<T>& o)",reference count no change

But,reference count was changed when the function is called:

page->setMainFrame(this); --> call "PassRefPtr(T* ptr) : m_ptr(ptr) { if (ptr) ptr->ref(); }", reference count +1

So,The "PassRefPtr<Frame> mainFrame" and the "Frame *mainFrame" cause same reference count.

But use "PassRefPtr<Frame>" will call new operation!

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: GlobalScript in WebKit

2009-11-26T09:44:20Z

What I meant was it would be nice, for the sake of discussion, to share the experience of real life applications that used SharedWorkers or inter-window communications for sharing of significant portions of code and data. Google apps may be a partial example but it is a real life example of concrete issues with proposed solution that sounds pretty generic and useful for other web apps. It is only prudent to take their feedback rather then replace it with our own theories about future of the web. No doubt this is a new mechanism and it's good to question it, since it has costs even as experimental API. Gut feelings vary, some app devs say they need it to solve real issues, we dont hear from other app devs who were facing similar issues and solved it differently. Seems there is no strong argument to kill it nor bless it. Why don't make it experimental and see? If it was possible to implement it in extension or plugin, we would run it as another Gears-like experiment, but it can not be done in a plugin... I believe there could be good arguments that simply didn't surface yet, and hope to hear them. Dmitry.

On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting <pkasting@...> wrote:

On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich@...> wrote:

BTW, could you tell what's the 'course' that would be reverted?

Meaning, "before we decide that SharedWorkers and inter-window communication are insufficient, and a further proposal should be entertained by the standards community".

PK

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T22:30:01Z

On Wed, Nov 25, 2009 at 1:49 PM, Maciej Stachowiak <mjs@...> wrote:
> On Nov 25, 2009, at 1:33 PM, Adam Barth wrote:
>> I don't have a complete design in mind. I could try to write up a
>> design document.
>
> Sounds like we could use one given the potential complications.

I've sketched out a complete design here:

http://docs.google.com/Doc?id=dd4p8wc4_12sm65qbk4

I've given the participants in this thread write access so they can
add notes / ideas. If you'd like write access, let me know.

Adam
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: GlobalScript in WebKit

2009-11-25T22:16:21Z

On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich@...> wrote:

BTW, could you tell what's the 'course' that would be reverted?

Meaning, "before we decide that SharedWorkers and inter-window communication are insufficient, and a further proposal should be entertained by the standards community".

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: GlobalScript in WebKit

2009-11-25T21:41:46Z

Hi Sam!

Thanks a lot for sharing your perspective! I really wish your reply
had, in addition to the statement of the opinion, an argument or just
more explanation of why you think so. I think we covered SharedWorkers
and inter-window communication in the previous discussions and in the
design doc.

BTW, could you tell what's the 'course' that would be reverted?

Dmitry

On Wed, Nov 25, 2009 at 8:30 PM, Sam Weinig <sam.weinig@...> wrote:

> Hi Dmitry,
> As I have noted to others on the Chrome team, I do not think this is good
> idea and I don't think we should have it in WebKit. It adds extra
> complexity to WebKit and gives little beyond what is possible using
> inter-window communication and SharedWorkers. I think we need to give more
> time for large applications to adopt designs around workers before we
> reverse course, at which point, we should again discuss this in the
> standards community.
> -Sam
>
> On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov <dimich@...> wrote:
>>
>> Hi webkit!
>> I'm starting to work on actual implementation of GlobalScript experimental
>> API and started to post patches (hopefully in reviewable portions). There is
>> an uber-bug which has plan of implementation.
>> The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC
>> and v8 bindings (first with JSC because at the moment JSC bindings are
>> easier to work with and I'd wish WebKit not to have 1-engine-only features
>> ever).
>> I'd be glad to know if there are suggestions, ideas or concerns of any
>> kind... For example, if there is no interest in JSC bindings, it can be hard
>> to get them reviewed by someone who knows them well. It'd be better to know
>> that earlier.
>> Thanks!
>> Dmitry
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@...
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: GlobalScript in WebKit

2009-11-25T20:30:59Z

Hi Dmitry,

As I have noted to others on the Chrome team, I do not think this is good idea and I don't think we should have it in WebKit. It adds extra complexity to WebKit and gives little beyond what is possible using inter-window communication and SharedWorkers. I think we need to give more time for large applications to adopt designs around workers before we reverse course, at which point, we should again discuss this in the standards community.

-Sam

On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov <dimich@...> wrote:

Hi webkit!

I'm starting to work on actual implementation of GlobalScript experimental API and started to post patches (hopefully in reviewable portions). There is an uber-bug which has plan of implementation.

The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC and v8 bindings (first with JSC because at the moment JSC bindings are easier to work with and I'd wish WebKit not to have 1-engine-only features ever).

I'd be glad to know if there are suggestions, ideas or concerns of any kind... For example, if there is no interest in JSC bindings, it can be hard to get them reviewed by someone who knows them well. It'd be better to know that earlier.

Thanks!
Dmitry

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T14:01:56Z

On Nov 25, 2009, at 1:45 PM, Michal Zalewski wrote:

>> The other way to skin this cat, by the way, is to implement the
>> seamless attribute on iframes. That gives you a similar sort of
>> design using the @sandbox attribute and solves many of your above
>> concerns, e.g. by creating a new namespace for @ids. Maybe we should
>> try that first or in parallel?
>
> I would think that in practice, IFRAMEs would, at least
> psychologically, be significantly less useful to web app developers.
>
> This is due to the fact that frames are conceptually more difficult to
> properly position and size to accommodate any dynamically inserted
> text;

Seamless iframes would address this first problem by participating in
the layout of the containing page.

> are more cumbersome to pre-populate with data on server-side
> (extra HTTP roundtrips or opaque data: URLs). Also, are renderer
> implementations actually ready to handle hundreds of seamless IFRAMEs
> on a page with the performance footprint not exceeding that of spans
> and divs?

But not these last two problems (though I think you can still
document.write() into a sandboxed seamless iframe, making it not much
less convenient than the staticInnerHTML solution).

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T13:49:39Z

On Nov 25, 2009, at 1:33 PM, Adam Barth wrote:

> On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak <mjs@...>
> wrote:
>> On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
>>> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak
>>> <mjs@...> wrote:
>>>> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
>>>>> Maybe we should have a DOM API called
>>>>> webkitJailChildren("no-script-for-you") on Node that prevents
>>>>> future
>>>>> children from running script. Making it a DOM API prevents
>>>>> authors
>>>>> from trying to turn the feature on with markup.
>>>>
>>>> Interesting idea. This seems potentially trickier to implement
>>>> than just
>>>> innerStaticHTML, since nearly every method that mutates the DOM
>>>> will have
>>>> to
>>>> check jail status. innerStaticHTML could be limited in scope to
>>>> only
>>>> operations that happen as part of parsing.
>>>
>>> Instead of checking every DOM mutation, we could just walk the
>>> parent
>>> pointers before executing a script to see if an ancestor is jailed.
>
> I don't have a complete design in mind. I could try to write up a
> design document.

Sounds like we could use one given the potential complications.

>
>> A few thoughts:
>>
>> 1) Presumably we'd want to block instantiation of plugins and Java
>> applets
>> too, or the scripting restriction becomes toothless. Perhaps also
>> iframes,
>> unless the scripting restriction is intended to propagate across
>> frame
>> boundaries.
>
> Yes. Also the <base> element. Essentially, all the same APIs that
> are currently restricted by the XSSAuditor.
>
>> 2) Capturing all points at which script execution occurs and
>> tracing them
>> back to the originating element may be tricky. javascript: URIs are
>> one
>> potentially subtle example. By the time the JavaScript for those gets
>> executed, I believe we no longer know the originating element, the
>> way the
>> code is currently structured.
>
> The way I would do this is to teach HTMLAnchorElement and friends not
> to hand off JavaScript URLs to FrameLoader if their parent is jailed.
> I'm not sure how many such interception points we'd need.

Not sure either. Two others I can think of are SVGAElement and
HTMLFormElement.

>
>> 3) It seems like the rule "don't execute JS" might not be quite
>> what is
>> desired, since it would (presumably) prevent the parent itself from
>> using
>> event listeners on nodes in the jail. IMO the best treatment for
>> event
>> listeners would be to prevent them from being created by
>> attributes, rather
>> than to prevent them from executing.
>
> Agreed. We'd want to stop inline event listeners from being created
> on jailed nodes.
>
>> 4) Do we need to strip or rename id, name and class values to prevent
>> interference with the containing page's use of getElementById() and
>> such?
>> Caja does.
>
> I think this is an order of magnitude less important that direct
> script execution. There are going to be advanced use cases for which
> Caja is the right answer.

Caja wants to let you actually run script in the jail without
interfering with the containing page - I definitely don't think we
should target that. But preventing the content from interfering with
the containing page seems in-scope. I agree this particular threat is
less risky than actual script execution.

> The other way to skin this cat, by the way, is to implement the
> seamless attribute on iframes. That gives you a similar sort of
> design using the @sandbox attribute and solves many of your above
> concerns, e.g. by creating a new namespace for @ids. Maybe we should
> try that first or in parallel?

Indeed, it can cover some similar use cases. I don't know if it's good
for comment sections - one iframe per comment would be quite
heavyweight. If there is any active content *around* each comment
(like edit or reply buttons) then you might not be able to use one for
all of them. In such a case I think innerStaticHTML (or moral
equivalent via jailed nodes) would be a more suitable solution. If you
have only a small number of untrusted content regions then seamless
iframes could be a good solution and it might be easier to be really
confident of the implementation (since all cross-frame access of any
kind is already doing a security check, and turning off scripting or
plugins wholesale for a frame can be done in a very localized way).
OTOH it would require render tree expertise to implement the layout
aspects.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T13:45:33Z

> The other way to skin this cat, by the way, is to implement the
> seamless attribute on iframes. That gives you a similar sort of
> design using the @sandbox attribute and solves many of your above
> concerns, e.g. by creating a new namespace for @ids. Maybe we should
> try that first or in parallel?

I would think that in practice, IFRAMEs would, at least
psychologically, be significantly less useful to web app developers.

This is due to the fact that frames are conceptually more difficult to
properly position and size to accommodate any dynamically inserted
text; are more cumbersome to pre-populate with data on server-side
(extra HTTP roundtrips or opaque data: URLs). Also, are renderer
implementations actually ready to handle hundreds of seamless IFRAMEs
on a page with the performance footprint not exceeding that of spans
and divs?

/mz
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T13:33:35Z

On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak <mjs@...> wrote:

> On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
>> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs@...> wrote:
>>> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
>>>> Maybe we should have a DOM API called
>>>> webkitJailChildren("no-script-for-you") on Node that prevents future
>>>> children from running script. Making it a DOM API prevents authors
>>>> from trying to turn the feature on with markup.
>>>
>>> Interesting idea. This seems potentially trickier to implement than just
>>> innerStaticHTML, since nearly every method that mutates the DOM will have
>>> to
>>> check jail status. innerStaticHTML could be limited in scope to only
>>> operations that happen as part of parsing.
>>
>> Instead of checking every DOM mutation, we could just walk the parent
>> pointers before executing a script to see if an ancestor is jailed.

I don't have a complete design in mind. I could try to write up a
design document.

> A few thoughts:
>
> 1) Presumably we'd want to block instantiation of plugins and Java applets
> too, or the scripting restriction becomes toothless. Perhaps also iframes,
> unless the scripting restriction is intended to propagate across frame
> boundaries.

Yes. Also the <base> element. Essentially, all the same APIs that
are currently restricted by the XSSAuditor.

> 2) Capturing all points at which script execution occurs and tracing them
> back to the originating element may be tricky. javascript: URIs are one
> potentially subtle example. By the time the JavaScript for those gets
> executed, I believe we no longer know the originating element, the way the
> code is currently structured.

The way I would do this is to teach HTMLAnchorElement and friends not
to hand off JavaScript URLs to FrameLoader if their parent is jailed.
I'm not sure how many such interception points we'd need.

> 3) It seems like the rule "don't execute JS" might not be quite what is
> desired, since it would (presumably) prevent the parent itself from using
> event listeners on nodes in the jail. IMO the best treatment for event
> listeners would be to prevent them from being created by attributes, rather
> than to prevent them from executing.

Agreed. We'd want to stop inline event listeners from being created
on jailed nodes.

> 4) Do we need to strip or rename id, name and class values to prevent
> interference with the containing page's use of getElementById() and such?
> Caja does.

I think this is an order of magnitude less important that direct
script execution. There are going to be advanced use cases for which
Caja is the right answer.

The other way to skin this cat, by the way, is to implement the
seamless attribute on iframes. That gives you a similar sort of
design using the @sandbox attribute and solves many of your above
concerns, e.g. by creating a new namespace for @ids. Maybe we should
try that first or in parallel?

Adam
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T13:25:30Z

On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:

> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs@...>
> wrote:
>> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
>>> Maybe we should have a DOM API called
>>> webkitJailChildren("no-script-for-you") on Node that prevents future
>>> children from running script. Making it a DOM API prevents authors
>>> from trying to turn the feature on with markup.
>>
>> Interesting idea. This seems potentially trickier to implement than
>> just
>> innerStaticHTML, since nearly every method that mutates the DOM
>> will have to
>> check jail status. innerStaticHTML could be limited in scope to only
>> operations that happen as part of parsing.
>
> Instead of checking every DOM mutation, we could just walk the parent
> pointers before executing a script to see if an ancestor is jailed.

A few thoughts:

1) Presumably we'd want to block instantiation of plugins and Java
applets too, or the scripting restriction becomes toothless. Perhaps
also iframes, unless the scripting restriction is intended to
propagate across frame boundaries.

2) Capturing all points at which script execution occurs and tracing
them back to the originating element may be tricky. javascript: URIs
are one potentially subtle example. By the time the JavaScript for
those gets executed, I believe we no longer know the originating
element, the way the code is currently structured.

3) It seems like the rule "don't execute JS" might not be quite what
is desired, since it would (presumably) prevent the parent itself from
using event listeners on nodes in the jail. IMO the best treatment for
event listeners would be to prevent them from being created by
attributes, rather than to prevent them from executing.

4) Do we need to strip or rename id, name and class values to prevent
interference with the containing page's use of getElementById() and
such? Caja does.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T12:34:24Z

On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs@...> wrote:

> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
> > Maybe we should have a DOM API called
> > webkitJailChildren("no-script-for-you") on Node that prevents future
> > children from running script. Making it a DOM API prevents authors
> > from trying to turn the feature on with markup.
>
> Interesting idea. This seems potentially trickier to implement than just
> innerStaticHTML, since nearly every method that mutates the DOM will have to
> check jail status. innerStaticHTML could be limited in scope to only
> operations that happen as part of parsing.

Instead of checking every DOM mutation, we could just walk the parent
pointers before executing a script to see if an ancestor is jailed.

Adam
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: innerStaticHTML

2009-11-25T12:30:58Z

On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:

On Tue, Nov 24, 2009 at 11:21 PM, Maciej Stachowiak <mjs@...> wrote:
If we tie it to an element or attribute, people may be tempted to just do it
in markup, which would be insecure.

Maybe we should have a DOM API called
webkitJailChildren("no-script-for-you") on Node that prevents future
children from running script. Making it a DOM API prevents authors
from trying to turn the feature on with markup.

Interesting idea. This seems potentially trickier to implement than just innerStaticHTML, since nearly every method that mutates the DOM will have to check jail status. innerStaticHTML could be limited in scope to only operations that happen as part of parsing.

On Tue, Nov 24, 2009 at 11:27 PM, Michal Zalewski <lcamtuf@...> wrote:

...unsanitized user content...


I'd rather not go this route in our initial implementation. I think
we should target the use case of a web site receiving an untrusted
string via cross-origin XMLHttpRequest or postMessage.

One obvious likely use case is for sites that wish to sanitize user-generated content, for example comment sections of blogs. innerStaticHTML is actually decent for that use case. Not quite as nice as markup, but I'm wary of introducing parser complexity to defend against hostile content that tries to prematurely close the jail.

Regards,

Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

ImageLoader class

2009-11-25T12:15:04Z

Hello,

I am writing my own class using ImageLoader. Can somebody, please, help me with these questions:

How do I know that the image was loaded already? Can I set up callback somehow?
What should functions sourceURI() and dispatchLoadEvent() do?
What is pixel format for m_imageLoader.image()->image()->data()->data()? Is this the right way to access loaded image raw pixel data?
How can I handle animations (e.g. GIF files)? How do I know when the next image in the animation suquence is ready? Another callback?
Which image formats are supported? Can I add my own, like HDR?

Thank you.

Sergiy

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: Why are some layout tests renamed with a suffix of -disabled?

2009-11-25T10:53:43Z

On Wed, Nov 25, 2009 at 10:44 AM, Dan Bernstein <mitz@...> wrote:

On Nov 25, 2009, at 10:38 AM, Darin Fisher wrote:

On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein <mitz@...> wrote:

On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote:

> Why are some layout tests renamed with a suffix of -disabled? Why aren't such tests simply added to the skipped list? Is -disabled simply the old way?

Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug makes it impossible to run the test (e.g. it crashes DumpRenderTree) or makes the test produce different results on each run (this can also be a bug in the test). The skipped lists are platform-specific, so they are not a good way to deal with such situations.

My concern is that some tests may pass on some ports but not others.

For such cases, the skipped list is the way to go.

If the tests are -disabled, then it prevents them from being run on ports where the tests function properly.

I see now that I didn’t make myself clear. By “WebKit bug” above I meant a bug that affects all ports and platforms (maybe I should have said “a core WebKit bug” or “a WebCore bug” :-) ).

Since skipped lists prevent the test from being executed, doesn't it solve the problem of disabling a test for ports that can't handle it? What am I missing? :-)

The “tests that crash/hang/behave unpredictably on all ports” part.

There aren’t many -disabled tests, and I think it’s a good idea to audit them and make sure that (a) they can’t be re-enabled (b) they can’t just be skipped on some platforms and run on others and (c) there’s a bug filed on re-enabling them (or fixing the reason why they can’t be enabled).

This makes sense now. Thanks for clarifying.

-Darin

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: Why are some layout tests renamed with a suffix of -disabled?

2009-11-25T10:44:05Z

On Nov 25, 2009, at 10:38 AM, Darin Fisher wrote:

On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein <mitz@...> wrote:

On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote:

> Why are some layout tests renamed with a suffix of -disabled? Why aren't such tests simply added to the skipped list? Is -disabled simply the old way?

Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug makes it impossible to run the test (e.g. it crashes DumpRenderTree) or makes the test produce different results on each run (this can also be a bug in the test). The skipped lists are platform-specific, so they are not a good way to deal with such situations.

My concern is that some tests may pass on some ports but not others.

For such cases, the skipped list is the way to go.

If the tests are -disabled, then it prevents them from being run on ports where the tests function properly.

I see now that I didn’t make myself clear. By “WebKit bug” above I meant a bug that affects all ports and platforms (maybe I should have said “a core WebKit bug” or “a WebCore bug” :-) ).

Since skipped lists prevent the test from being executed, doesn't it solve the problem of disabling a test for ports that can't handle it? What am I missing? :-)

The “tests that crash/hang/behave unpredictably on all ports” part.

There aren’t many -disabled tests, and I think it’s a good idea to audit them and make sure that (a) they can’t be re-enabled (b) they can’t just be skipped on some platforms and run on others and (c) there’s a bug filed on re-enabling them (or fixing the reason why they can’t be enabled).

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: Why are some layout tests renamed with a suffix of -disabled?

2009-11-25T10:38:15Z

On Wed, Nov 25, 2009 at 10:35 AM, Dan Bernstein <mitz@...> wrote:

On Nov 25, 2009, at 9:55 AM, Darin Fisher wrote:

> Why are some layout tests renamed with a suffix of -disabled? Why aren't such tests simply added to the skipped list? Is -disabled simply the old way?

Usually a test is disabled, with a bug filed to re-enable it, when a WebKit bug makes it impossible to run the test (e.g. it crashes DumpRenderTree) or makes the test produce different results on each run (this can also be a bug in the test). The skipped lists are platform-specific, so they are not a good way to deal with such situations.

My concern is that some tests may pass on some ports but not others. If the tests are -disabled, then it prevents them from being run on ports where the tests function properly. Since skipped lists prevent the test from being executed, doesn't it solve the problem of disabling a test for ports that can't handle it? What am I missing? :-)

-Darin

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev