Re: [webkit-dev] "using" statement clarifications

[Darin Adler]

On Dec 7, 2009, at 8:42 PM, Chris Jerdonek wrote:

> The existing guidelines single out the case of nested namespaces and
> says they should appear further down when the parent exists.  For
> example, instead of this--
> 
>> using namespace WebCore::HTMLNames;
>> 
>> namespace WebCore {
> 
> do this--
> 
>> namespace WebCore {
>> 
>> using namespace HTMLNames;
> 
> Should nested namespaces remain an exception?

I think so.

-- Darin

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

Re: [webkit-dev] "using" statement clarifications

[Chris Jerdonek]

On Mon, Dec 7, 2009 at 9:30 AM, Darin Adler  wrote:
> Sorry, I wasn’t able to follow all the logic in the style guideline and the 
> email message nor fully understand what the script enforces. So I’ll give my 
> view on this and hope it helps.

Thanks.  To be clear, I will restate your clarifications and
suggestions as I understand them.  I will also explain how they
compare to the guidelines as currently stated.

(1) Add this to the guidelines: Do not use statements of the form
"using std:foo" in implementation files.  Use "using namespace std"
instead.  (The script currently enforces this rule, but for header
files and not just implementation files.)

(2) Clarify that the rule to put "using namespace" statements near the
beginning of a file applies only to implementation files. (It
currently applies also to header files.)  Also, strengthen the rule so
it applies to all "using" statements in implementation files and not
just "using namespace" statements.

> I also don’t see a need for "using" statements of either kind further down in 
> the file. It seems they can go at the top, right after the includes. But 
> maybe I’ve missed some useful case.

The existing guidelines single out the case of nested namespaces and
says they should appear further down when the parent exists.  For
example, instead of this--

> using namespace WebCore::HTMLNames;
>
> namespace WebCore {

do this--

> namespace WebCore {
>
> using namespace HTMLNames;

Should nested namespaces remain an exception?

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

Re: [webkit-dev] Renaming WebCore/dom/ClassNames

[Darin Adler]

On Dec 7, 2009, at 3:33 PM, Nate Chapin wrote:

> I was thinking of renaming it to SpaceSplitString, or AtomicStringList (it's 
> previous name), but I'm not hung up on any particular name.

Renaming seems OK. Of the two I definitely prefer SpaceSplitString. Generally I 
think we should only use “List” in names of things that have efficient 
add/remove semantics.

-- Darin

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

[webkit-dev] Renaming WebCore/dom/ClassNames

[Nate Chapin]

(https://bugs.webkit.org/show_bug.cgi?id=32250 is the relevant bug)

Summary: ClassNames used to be used only for class names, but its behavior
meets the requirements for HTML5's strings of space separated tokens.  If
folks are ok with it, I'd like to rename ClassNames to something more
generic so that it is more appropriate to use it for HTML5 features (the
only current html5-flavored usage I know of is the one I introduced in
HTMLAnchorElement
).

I was thinking of renaming it to SpaceSplitString, or AtomicStringList (it's
previous name), but I'm not hung up on any particular name.

Any thoughts or objections?
~Nate
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Accessibility: Usage of node in TextMarkerData not reference counting... leading to crashes

[Chris Fleizach]

When we create TextMarkerData in AXObjectCache.cpp

We just stick in a Node, like so

textMarkerData.axID = obj.get()->axObjectID();
textMarkerData.node = domNode;
textMarkerData.offset = deepPos.deprecatedEditingOffset();
textMarkerData.affinity = visiblePos.affinity(); 

It seems that this is the probable cause of a number of low-incidence crashes, 
because when TextMarkerData is returned by the Assistive technology 
application, .node has already been released.

For example, this crash

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xbbadbeef
0x0001026d2f7f in WebCore::TreeShared::ref ()
(gdb) bt
#0  0x0001026d2f7f in WebCore::TreeShared::ref ()
#1  0x0001026d3163 in WTF::PassRefPtr::PassRefPtr ()
#2  0x000103193dfb in WebCore::VisiblePosition::VisiblePosition ()
#3  0x0001027517b9 in 
WebCore::AXObjectCache::visiblePositionForTextMarkerData ()
#4  0x0001026dbe69 in visiblePositionForTextMarker ()
#5  0x0001026dbeb8 in visiblePositionForEndOfTextMarkerRange ()
#6  0x0001026dbf47 in -[AccessibilityObjectWrapper 
visiblePositionRangeForTextMarkerRange:] ()
#7  0x0001026e16ff in -[AccessibilityObjectWrapper 
accessibilityAttributeValue:forParameter:] ()
#8  0x000100d9c692 in CopyParameterizedAttributeValue ()
#9  0x7fff8619a6c2 in _AXXMIGCopyParameterizedAttributeValue ()
#10 0x7fff861a481f in _XCopyParameterizedAttributeValue ()

It seems like we need a cache for the node's we store in TextMarkerData



Should I add a HashSet in AXObjectCache that uses RefPtr around the nodes?

Or should I add something in the destructor of Node to inform accessibility to 
update it's cache? (I think this is what RenderObject does)___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] "using" statement clarifications

[David Levin]

On Sat, Dec 5, 2009 at 9:29 AM, Chris Jerdonek wrote:

> I noticed that the style-check script enforces a rule that isn't
> stated in the coding style guidelines.


Just a quick note about this in general:
If you ever encounter this, feel free to submit a patch to disable and/or
remove the check (or file a bug to disable the check).

Any items like this would be an accident due to the heritage of the script.

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

Re: [webkit-dev] "using" statement clarifications

[Darin Adler]

Sorry, I wasn’t able to follow all the logic in the style guideline and the 
email message nor fully understand what the script enforces. So I’ll give my 
view on this and hope it helps.

- The rule against "using namespace xxx" in headers in namespace scope exists 
because of the notion that someone might be building software that depends on a 
header without being able to modify the header. Combining the namespace may 
create name conflicts that are not fixable.

The assumption that clients are using a header and can’t modify it may not in 
fact be true for headers inside WebKit. Most are designed for use only within 
WebKit and so in theory that guideline could be limited only to headers 
intended for use outside WebKit. On the other hand, I have the impression that 
on some platforms such as Qt it is common for clients to directly use internal 
headers, such as the ones in WebCore.

I can’t think of a concrete example where a "using xxx::yyy" would be a problem 
inside a class or function scope in a header, so it seems fine to permit those. 
I suppose there’s a chance that "using namespace xxx" could still cause a 
problem even inside a function, but again it’s hard for me to think of a real 
example.

- Inside non-header files, there is the guideline of preferring "using 
namespace std" to "using std::min". This suggestion comes from me.

It does not seem worthwhile to maintain a list of "using" statements at the top 
of the file mentioning each imported identifier. In theory we could avoid some 
rare conflicts this way, but in practice it just seems like a lot of unhelpful 
bookkeeping.

At first, I did the "using std::min" thing, but now I prefer "using namespace 
std" inside implementation files, and I suggest we retain that guideline.

I also don’t see a need for "using" statements of either kind further down in 
the file. It seems they can go at the top, right after the includes. But maybe 
I’ve missed some useful case.

-- Darin

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

Re: [webkit-dev] AJAX requests from local files to network stopped working in 4.6

[Darin Adler]

On Dec 7, 2009, at 6:28 AM, Alexander Vassilev wrote:

> With qtwebkit 4.5.x I had no problems doing so, no cross-site scripting 
> blocking by webkit, everything just worked (i did security control by 
> myself). With qt 4.6 however, I get an empty responseText of the 
> XMLHttpRequest object.

I think this message belongs on webkit-help rather than webkit-dev. Please look 
at  to see the description of the purpose of 
the mailing lists.

The change in behavior is due to:

https://bugs.webkit.org/show_bug.cgi?id=20249
http://trac.webkit.org/changeset/41297

> is there a way to disable this security feature, like it was in the qt-4.5.x 
> version of WebKit?

The setAllowUniversalAccessFromFileUrls function is what you are looking for, I 
think.

-- Darin

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

[webkit-dev] AJAX requests from local files to network stopped working in 4.6

[Alexander Vassilev]

Hi all,

I am using qt and qtwebkit in my application, it embeds webkit and loads 
some local html and javascript files, which do XMLHTTP requests over the 
network. With qtwebkit 4.5.x I had no problems doing so, no cross-site 
scripting blocking by webkit, everything just worked (i did security 
control by myself). With qt 4.6 however, I get an empty responseText of 
the XMLHttpRequest object. Just to be sure its not the javascript code 
that causes the problem, I ran a qt-4.5.x version of my app on the same 
html and it nicely got the xmlhttp reply. Again, ran the qt-4.6 version, 
and it got an empty response string. I have checked that the xssAuditor 
is not enabled in qtwebkit (not via qtwebkit API, but by accessing 
internal APIs of webkit). My question is, what is blocking my xmlhttp 
request and is there a way to disable this security feature, like it was 
in the qt-4.5.x version of WebKit? I have access to webkit

internals, so the absence of a qtwebkit API to control the xss blocking
would not be a problem, as long as there is a generic WebKit API to do so.

Thanks in advance
Alex


<>___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SVG Filters

[Maciej Stachowiak]

On Dec 6, 2009, at 3:00 PM, Dirk Schulze wrote:


Hi Maciej and Darin,

you both suggested to add fuzz tests for SVG Filters. I looked at the
fuzz test LayoutTest/svg/dom/fuzz-path-parser.html. As an analogy to
this test, I would suggest an array with the effects to test, it's
number of inputs and attributes, that can't be randomly set.
But the basic question is, what should the fuzz test test?
The combination of different effects? Should every filter effect have
it's own fuzz test with a default input? Different sizes of effects?
We need to keep in mind, that LayoutTests will slow down, as more
comlpex the fuzz tests get.


The fuzz testing doesn't necessarily have to be part of the layout  
tests. It's good to do that for simple fuzz testers like the path  
parser, but not for long-running exhaustive tests like iExploder.


I think the following are interesting to test as fuzz parameters:

- The contents used as filter input - would want to test random,  
realistic images, and maybe edge cases like all black, all white, all  
opaque, etc.
- The filter parameters - different combinations of parameter values,  
including extremely large and extremely small, negative for ones that  
shouldn't allow it, invalid values, etc.


Combinations of filters may also be interesting to test, but I'm not  
sure that would be as likely to reveal bugs. The main thing I am  
worried about is code that does direct bitmap manipulation - a bounds  
overflow in such code seems like the most likely vector for a security  
bug.


Regards,
Maciej

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