Re: [webkit-dev] wiki spammers
Hi, Can't we add a captcha to the registration form of the trac to block SPAM bots? br, Ossy Andras Becsi írta: Hi, Could someone who has the needed credentials ban willetta...@yahoo.com carstrow...@yahoo.com tonygua...@gmail.com mtjohnwo...@gmail.com lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
Hi, On 18 September 2012 13:47, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, Can't we add a captcha to the registration form of the trac to block SPAM bots? Would be good because spamming seems to escalate lately. Some more addresses that regularly submitted spam links in recent months: sussane_...@hotmail.com toybaby...@gmail.com janeparker...@gmail.com ra...@mailinator.com dasta...@o2.pl doris.gr...@gmail.com w...@marrant.org dietas...@hotmail.com cont...@freemobileactu.com uuo...@gmail.com /Andras br, Ossy Andras Becsi írta: Hi, Could someone who has the needed credentials ban willetta...@yahoo.com carstrow...@yahoo.com tonygua...@gmail.com mtjohnwo...@gmail.com lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
The spam filter plugin had not been installed on the new hardware, but I just installed it, so the spamming should be better now. You can add new addresses or patterns to the BadContent wiki page for any new spam. Previously I had kept all of the Mac OS Forge BadContent lists in sync, but with the new hardware the project can manage its own BadContent page now. https://trac.webkit.org/wiki/BadContent -Bill On Sep 18, 2012, at 4:52 AM, Andras Becsi abe...@webkit.org wrote: Hi, On 18 September 2012 13:47, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, Can't we add a captcha to the registration form of the trac to block SPAM bots? Would be good because spamming seems to escalate lately. Some more addresses that regularly submitted spam links in recent months: sussane_...@hotmail.com toybaby...@gmail.com janeparker...@gmail.com ra...@mailinator.com dasta...@o2.pl doris.gr...@gmail.com w...@marrant.org dietas...@hotmail.com cont...@freemobileactu.com uuo...@gmail.com /Andras br, Ossy Andras Becsi írta: Hi, Could someone who has the needed credentials ban willetta...@yahoo.com carstrow...@yahoo.com tonygua...@gmail.com mtjohnwo...@gmail.com lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Anyone willing to update webkit.org?
I was noticing today that http://www.webkit.org/ is quite old and out of date. What xenon built 6 years ago, has stood up remarkably well, but it may be time for a refresh. (It also has no high-dpi support.) I'm aware that I have the ability to change it. But I'm also inviting others to do so: http://trac.webkit.org/browser/trunk/Websites/webkit.org In particular: - It mentions nothing of Safari on iOS or Chrome (which must be some huge fraction of our userbase by now) - Could link to numerous other sites showing information about WebKit (cia, ohloh, svnsearch) - Projects like SVG really aren't the current focus. :) I'm sure this list is full of individuals with infinitely more visual design sense than I. So I invite your patches, my reviewing and committing fingers stand ready. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anyone willing to update webkit.org?
On Sep 18, 2012, at 7:04 PM, Eric Seidel e...@webkit.org wrote: I was noticing today that http://www.webkit.org/ is quite old and out of date. What xenon built 6 years ago, has stood up remarkably well, but it may be time for a refresh. (It also has no high-dpi support.) I'm aware that I have the ability to change it. But I'm also inviting others to do so: http://trac.webkit.org/browser/trunk/Websites/webkit.org In particular: - It mentions nothing of Safari on iOS or Chrome (which must be some huge fraction of our userbase by now) - Could link to numerous other sites showing information about WebKit (cia, ohloh, svnsearch) - Projects like SVG really aren't the current focus. :) They are not? Maybe not for you :) Dirk I'm sure this list is full of individuals with infinitely more visual design sense than I. So I invite your patches, my reviewing and committing fingers stand ready. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt
My preference would simply be to improve the Clang static analyser - it's free, open source, etc. I periodically run that analyzer on JSC, but apparently their ToT code has many improvements over stable. --Oliver On Sep 17, 2012, at 9:20 PM, Brent Fulgham wrote: Hi Gang, On Sep 17, 2012, at 4:11 PM, James Hawkins jhawk...@chromium.org wrote: TL;DR - If you have opinions one way or another about having a Coverity instance available for WebKit developers, please respond to this message. I have used Coverity at on a couple of occasions, without modifying source code to help the static analyzer. While its rather high cost has prevented me from using it recently, I did think that it provided enough signal-to-noise that I really wish I still had it. I think one of its main advantages is the ability to have it run over the entire source tree periodically to do larger-scale analysis than we can do looking at individual changesets. Many of the bugs it found were of the 'uninitialized variable' type, but I did find that it could dredge up some very clever edge cases that were definitely worth fixing. Since the cost to the project is effectively zero, I think we would be very foolish not to take advantage of this very generous offer. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] platform-specific differences in test case inputs
Background: some of the storage systems use SerializedScriptValue to
persist structured-clonable objects (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8
but JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old
V8-based formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the serialisation
is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth aba...@webkit.org wrote:
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
What exactly are you trying to test here? The internal serialisation format
isn't exposed anywhere (nor should it be).
By definition newer formats won't be backwards compatible, or are you trying to
ensure that newer deserialisers will be able to continue to deserialise old
content?
--Oliver
On Sep 18, 2012, at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
Where do you test that property?
Adam
On Tue, Sep 18, 2012 at 12:43 PM, Oliver Hunt oli...@apple.com wrote:
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the
serialisation is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth aba...@webkit.org wrote:
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
Sorry I totally left out the I expose this through Internals - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote: What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enable encoding detector on layout(regression) test
Hi, I am working on a bad case that encoding detector doesn't recognize it. So I created a bug, https://bugs.webkit.org/show_bug.cgi?id=97054, then try to make a layout(regression) test case. However, enabling encoding detector by javaScript manipulation seems not feasible since encoding detector works on reading input stream level. Therefore, I am asking here if any of WebKittens would give some advices/opinions including good precedent to resolve this case. - Kangil Han ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
Hi, I just started working with webkit (specificially JSC) and am trying to learn the codebase. I hope someone can bear with me enough to help me with some questions: 1. I notice there are at least two implementations of hash tables in JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if either, is used in, say, the normal case of accessing the properties of a DOM element, like window.location, etc.? And assuming it's one or the other, what's the main use case of the other one? 2. Also, it looks like string keys in Lookup.h are always Identifiers, meaning (I think) that they are guaranteed to be single unique entries in the identifierTable of a JSGlobalData object. Because of this preprocessing, string equality in the hash table implementation can be tested just by comparing addresses. Is there any reason why PropertyMapHashTable.h does not (as far as I can tell) do the same thing? 3. Does the JIT side of the codebase use unique string identifiers like Lookup.h does, or is that a whole different ballgame? Thanks very much in advance for help! Stephen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
Hi Stephen.
1. I notice there are at least two implementations of hash tables in
JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if
either, is used in, say, the normal case of accessing the properties of a DOM
element, like window.location, etc.? And assuming it's one or the other,
what's the main use case of the other one?
window.location uses Lookup.h. Lookup.h contains hash table logic for static
properties compiled into the binary.
2. Also, it looks like string keys in Lookup.h are always Identifiers,
meaning (I think) that they are guaranteed to be single unique entries in the
identifierTable of a JSGlobalData object. Because of this preprocessing,
string equality in the hash table implementation can be tested just by
comparing addresses. Is there any reason why PropertyMapHashTable.h does not
(as far as I can tell) do the same thing?
It does.
inline PropertyTable::find_iterator PropertyTable::find(const KeyType key)
{
ASSERT(key);
ASSERT(key-isIdentifier() || key-isEmptyUnique());
unsigned hash = key-existingHash();
3. Does the JIT side of the codebase use unique string identifiers like
Lookup.h does, or is that a whole different ballgame?
Can you be more specific?
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
On Wed, Sep 19, 2012 at 1:12 AM, Geoffrey Garen gga...@apple.com wrote:
Hi Stephen.
1. I notice there are at least two implementations of hash tables in
JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if
either, is used in, say, the normal case of accessing the properties of a
DOM element, like window.location, etc.? And assuming it's one or the
other, what's the main use case of the other one?
window.location uses Lookup.h. Lookup.h contains hash table logic for
static properties compiled into the binary.
Thanks! So is PropertyMapHashTable for properties that have been defined by
the user, or is it not that simple?
2. Also, it looks like string keys in Lookup.h are always Identifiers,
meaning (I think) that they are guaranteed to be single unique entries in
the identifierTable of a JSGlobalData object. Because of this
preprocessing, string equality in the hash table implementation can be
tested just by comparing addresses. Is there any reason why
PropertyMapHashTable.h does not (as far as I can tell) do the same thing?
It does.
inline PropertyTable::find_iterator PropertyTable::find(const KeyType key)
{
ASSERT(key);
ASSERT(key-isIdentifier() || key-isEmptyUnique());
unsigned hash = key-existingHash();
My mistake: the second assert seems to not be there in QtWebKit-2.2.0, the
version I'm looking through, but I reading further I realized that keys are
also assumed to be unique identifiers with the comparison below.
if (key == table()[entryIndex - 1].key)
return std::make_pair(table()[entryIndex - 1], hash
m_indexMask);
(The way the types resolve, the key comparison is done on address rather
than value, as I assumed the first time I read it)
3. Does the JIT side of the codebase use unique string identifiers like
Lookup.h does, or is that a whole different ballgame?
Can you be more specific?
Apologies. Basically, does the implementation of object property access in
the JIT codebase also use strings which have been made unique identifiers
in the same way as in the runtime stack? (i.e. can they be assumed equal
iff they have the same address). I can't seem to find any code that does
it, but I am new to the whole tree.
Geoff
Thanks!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
Thanks! So is PropertyMapHashTable for properties that have been defined by the user, or is it not that simple? Yes. Apologies. Basically, does the implementation of object property access in the JIT codebase also use strings which have been made unique identifiers in the same way as in the runtime stack? (i.e. can they be assumed equal iff they have the same address). Yes -- typically, though, if the JIT needs to do a hash lookup, it will pass an Identifier to a C++ helper function. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
