[webkit-dev] Andres Gonzales is now a WebKit Reviewer

2021-10-13 Thread Chris Fleizach via webkit-dev
I'm happy to announce that Andres Gonzales is now a WebKit Reviewer! 
Congratulations Andres!

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit Commit Queue blocked by build errors in ToT

2018-12-07 Thread Chris Fleizach
To confirm, this is what is expected? Is WebKit the root namespace?

namespace WebKit {
using namespace WebCore;
using namespace WebKit;

Thanks


> On Dec 7, 2018, at 8:45 AM, Chris Fleizach  wrote:
> 
> Looks like there's quite a few of these. Will try to get them all
> 
>> On Dec 7, 2018, at 8:37 AM, Tim Horton > <mailto:timothy_hor...@apple.com>> wrote:
>> 
>> Someone in UnifiedSource28-mm.mm is “using namespace WebCore” outside of the 
>> root namespace.
>> 
>>> On Dec 7, 2018, at 08:31, Chris Fleizach >> <mailto:cfleiz...@apple.com>> wrote:
>>> 
>>> I'm hitting this tougher one now. Namespace conflict between Rect in Carbon 
>>> and WebCore::Rect
>>> 
>>> Any ideas?
>>> Thanks for your help
>>> 
>>> n file included from 
>>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:6:
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Plugins/mac/PluginInfoStoreMac.mm:32:
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/Source/WebKit/Shared/Plugins/Netscape/NetscapePluginModule.h:34:
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/npruntime_internal.h:28:
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/npapi.h:82:
>>> In file included from 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:29:
>>> In file included from 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbox.h:35:
>>> In file included from 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbar.h:26:
>>> In file included from 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Menus.h:22:
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Appearance.h:1373:3:
>>>  error: reference to 'Rect' is ambiguous
>>>   Rectbounds;
>>>   ^
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/Source/WebKit/WebKit2Prefix.h:45:
>>> In file included from 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43:
>>> In file included from 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:77:
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/MacTypes.h:550:41:
>>>  note: candidate found by name lookup is 'Rect'
>>> typedef struct Rect Rect;
>>> ^
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
>>> In file included from 
>>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:95:
>>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/Rect.h:60:7:
>>>  note: candidate found by name lookup is 'WebCore::Rect'
>>> class Rect final : public RectBase, public RefCounted {
>>>   ^
>>> 
>>> 
>>>> On Dec 6, 2018, at 4:44 PM, Chris Fleizach >>> <mailto:cfleiz...@apple.com>> wrote:
>>>> 
>>>> On it
>>>> 
>>>>> On Dec 6, 2018, at 4:44 PM, Andy Estes >>>> <mailto:aes...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 6, 2018, at 4:37 PM, Chris Fleizach >>>>> <mailto:cfleiz...@apple.com>> wrote:
>>>>>> 
>>

Re: [webkit-dev] WebKit Commit Queue blocked by build errors in ToT

2018-12-07 Thread Chris Fleizach
Looks like there's quite a few of these. Will try to get them all

> On Dec 7, 2018, at 8:37 AM, Tim Horton  wrote:
> 
> Someone in UnifiedSource28-mm.mm is “using namespace WebCore” outside of the 
> root namespace.
> 
>> On Dec 7, 2018, at 08:31, Chris Fleizach  wrote:
>> 
>> I'm hitting this tougher one now. Namespace conflict between Rect in Carbon 
>> and WebCore::Rect
>> 
>> Any ideas?
>> Thanks for your help
>> 
>> n file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:6:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Plugins/mac/PluginInfoStoreMac.mm:32:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/Source/WebKit/Shared/Plugins/Netscape/NetscapePluginModule.h:34:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/npruntime_internal.h:28:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/npapi.h:82:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:29:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbox.h:35:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbar.h:26:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Menus.h:22:
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Appearance.h:1373:3:
>>  error: reference to 'Rect' is ambiguous
>>   Rectbounds;
>>   ^
>> In file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/Source/WebKit/WebKit2Prefix.h:45:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:77:
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/MacTypes.h:550:41:
>>  note: candidate found by name lookup is 'Rect'
>> typedef struct Rect Rect;
>> ^
>> In file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:95:
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/Rect.h:60:7:
>>  note: candidate found by name lookup is 'WebCore::Rect'
>> class Rect final : public RectBase, public RefCounted {
>>   ^
>> 
>> 
>>> On Dec 6, 2018, at 4:44 PM, Chris Fleizach >> <mailto:cfleiz...@apple.com>> wrote:
>>> 
>>> On it
>>> 
>>>> On Dec 6, 2018, at 4:44 PM, Andy Estes >>> <mailto:aes...@apple.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 6, 2018, at 4:37 PM, Chris Fleizach >>>> <mailto:cfleiz...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 6, 2018, at 4:37 PM, Ryan Haddad >>>>> <mailto:ryanhad...@apple.com>> wrote:
>>>>>> 
>>>>>> Chris,
>>>>>> 
>>>>>> I'm assuming that this is in reference to the patch in 
>>>>>> https://bugs.webkit.org/show_bug.cgi?id=192373 
>>>>>> <https://bugs.webkit.org/show_bug.cgi?id=192373>. My guess is that 
>>>>>> something about the changes to 
>>>>>> Sourc

Re: [webkit-dev] WebKit Commit Queue blocked by build errors in ToT

2018-12-07 Thread Chris Fleizach
I'm hitting this tougher one now. Namespace conflict between Rect in Carbon and 
WebCore::Rect

Any ideas?
Thanks for your help

n file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:6:
In file included from 
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Plugins/mac/PluginInfoStoreMac.mm:32:
In file included from 
/Volumes/Data/EWS/WebKit/Source/WebKit/Shared/Plugins/Netscape/NetscapePluginModule.h:34:
In file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/npruntime_internal.h:28:
In file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/npapi.h:82:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:29:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbox.h:35:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbar.h:26:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Menus.h:22:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Appearance.h:1373:3:
 error: reference to 'Rect' is ambiguous
  Rectbounds;
  ^
In file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
In file included from /Volumes/Data/EWS/WebKit/Source/WebKit/WebKit2Prefix.h:45:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:77:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/MacTypes.h:550:41:
 note: candidate found by name lookup is 'Rect'
typedef struct Rect Rect;
^
In file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
In file included from 
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:95:
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/WebCore.framework/PrivateHeaders/Rect.h:60:7:
 note: candidate found by name lookup is 'WebCore::Rect'
class Rect final : public RectBase, public RefCounted {
  ^


> On Dec 6, 2018, at 4:44 PM, Chris Fleizach  wrote:
> 
> On it
> 
>> On Dec 6, 2018, at 4:44 PM, Andy Estes > <mailto:aes...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Dec 6, 2018, at 4:37 PM, Chris Fleizach >> <mailto:cfleiz...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 6, 2018, at 4:37 PM, Ryan Haddad >>> <mailto:ryanhad...@apple.com>> wrote:
>>>> 
>>>> Chris,
>>>> 
>>>> I'm assuming that this is in reference to the patch in 
>>>> https://bugs.webkit.org/show_bug.cgi?id=192373 
>>>> <https://bugs.webkit.org/show_bug.cgi?id=192373>. My guess is that 
>>>> something about the changes to 
>>>> Source/WebKit/WebKit.xcodeproj/project.pbxproj is causing an issue with 
>>>> unified sources.
>>>> 
>>>> The commit-queue itself has been landing other patches without issue and 
>>>> the build isn't broken on trunk bots. CC'ing Tim in case he can help point 
>>>> out the issue.
>>>> 
>>> 
>>> Yea must be. Any ideas why this wouldn’t build? I moved this .h/.mm to 
>>> another folder (from Mac -> Cocoa) 
>> 
>> Looks like we need to forward-declare class WebKit::SafeBrowsingWarning in 
>> WebViewImpl.h. Can you try that in your patch and see if that fixes it?
>> 
>> Andy
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] WebKit Commit Queue blocked by build errors in ToT

2018-12-06 Thread Chris Fleizach
On it

> On Dec 6, 2018, at 4:44 PM, Andy Estes  wrote:
> 
> 
> 
>> On Dec 6, 2018, at 4:37 PM, Chris Fleizach > <mailto:cfleiz...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Dec 6, 2018, at 4:37 PM, Ryan Haddad >> <mailto:ryanhad...@apple.com>> wrote:
>>> 
>>> Chris,
>>> 
>>> I'm assuming that this is in reference to the patch in 
>>> https://bugs.webkit.org/show_bug.cgi?id=192373 
>>> <https://bugs.webkit.org/show_bug.cgi?id=192373>. My guess is that 
>>> something about the changes to 
>>> Source/WebKit/WebKit.xcodeproj/project.pbxproj is causing an issue with 
>>> unified sources.
>>> 
>>> The commit-queue itself has been landing other patches without issue and 
>>> the build isn't broken on trunk bots. CC'ing Tim in case he can help point 
>>> out the issue.
>>> 
>> 
>> Yea must be. Any ideas why this wouldn’t build? I moved this .h/.mm to 
>> another folder (from Mac -> Cocoa) 
> 
> Looks like we need to forward-declare class WebKit::SafeBrowsingWarning in 
> WebViewImpl.h. Can you try that in your patch and see if that fixes it?
> 
> Andy

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


Re: [webkit-dev] WebKit Commit Queue blocked by build errors in ToT

2018-12-06 Thread Chris Fleizach


> On Dec 6, 2018, at 4:37 PM, Ryan Haddad  wrote:
> 
> Chris,
> 
> I'm assuming that this is in reference to the patch in 
> https://bugs.webkit.org/show_bug.cgi?id=192373 
> <https://bugs.webkit.org/show_bug.cgi?id=192373>. My guess is that something 
> about the changes to Source/WebKit/WebKit.xcodeproj/project.pbxproj is 
> causing an issue with unified sources.
> 
> The commit-queue itself has been landing other patches without issue and the 
> build isn't broken on trunk bots. CC'ing Tim in case he can help point out 
> the issue.
> 

Yea must be. Any ideas why this wouldn’t build? I moved this .h/.mm to another 
folder (from Mac -> Cocoa) 



> Ryan
> 
>> On Dec 6, 2018, at 3:55 PM, Chris Fleizach > <mailto:cfleiz...@apple.com>> wrote:
>> 
>> Hi
>> 
>> Looks like Commit Queue is blocked on processing patches because of a build 
>> failure that's been there for a day
>> 
>> --
>> https://webkit-queues.webkit.org/results/10296999 
>> <https://webkit-queues.webkit.org/results/10296999>
>> In file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
>> In file included from 
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:27:
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h:229:40: 
>> error: unknown type name 'SafeBrowsingWarning'; did you mean 
>> 'WKSafeBrowsingWarning'?
>> void showSafeBrowsingWarning(const SafeBrowsingWarning&, 
>> CompletionHandler&&)>&&);
>>^~~
>>WKSafeBrowsingWarning
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h:56:12: 
>> note: 'WKSafeBrowsingWarning' declared here
>> OBJC_CLASS WKSafeBrowsingWarning;
>>^
>> In file included from 
>> /Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:1619:19:
>>  error: out-of-line definition of 'showSafeBrowsingWarning' does not match 
>> any declaration in 'WebKit::WebViewImpl'
>> void WebViewImpl::showSafeBrowsingWarning(const SafeBrowsingWarning& 
>> warning, CompletionHandler&&)>&& 
>> completionHandler)
>>   ^~~
>> /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:2801:22:
>>  error: instance method '-dismiss' not found (return type defaults to 'id') 
>> [-Werror,-Wobjc-method-access]
>> [_shareSheet dismiss];
>>  ^~~
>> -
>> 
>> Filed a bug to track: https://bugs.webkit.org/show_bug.cgi?id=192479 
>> <https://bugs.webkit.org/show_bug.cgi?id=192479>
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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


[webkit-dev] WebKit Commit Queue blocked by build errors in ToT

2018-12-06 Thread Chris Fleizach
Hi

Looks like Commit Queue is blocked on processing patches because of a build 
failure that's been there for a day

--
https://webkit-queues.webkit.org/results/10296999
In file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
In file included from 
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:27:
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h:229:40: 
error: unknown type name 'SafeBrowsingWarning'; did you mean 
'WKSafeBrowsingWarning'?
void showSafeBrowsingWarning(const SafeBrowsingWarning&, 
CompletionHandler&&)>&&);
   ^~~
   WKSafeBrowsingWarning
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.h:56:12: 
note: 'WKSafeBrowsingWarning' declared here
OBJC_CLASS WKSafeBrowsingWarning;
   ^
In file included from 
/Volumes/Data/EWS/WebKit/WebKitBuild/Release/DerivedSources/WebKit2/unified-sources/UnifiedSource28-mm.mm:1:
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:1619:19: 
error: out-of-line definition of 'showSafeBrowsingWarning' does not match any 
declaration in 'WebKit::WebViewImpl'
void WebViewImpl::showSafeBrowsingWarning(const SafeBrowsingWarning& warning, 
CompletionHandler&&)>&& completionHandler)
  ^~~
/Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/Cocoa/WebViewImpl.mm:2801:22: 
error: instance method '-dismiss' not found (return type defaults to 'id') 
[-Werror,-Wobjc-method-access]
[_shareSheet dismiss];
 ^~~
-

Filed a bug to track: https://bugs.webkit.org/show_bug.cgi?id=192479

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


Re: [webkit-dev] Is anyone interested in maintaining INPUT_SPEECH?

2014-08-05 Thread Chris Fleizach
It’s never been supported on Mac, so I don’t think there are any complaints here

 On Aug 5, 2014, at 8:14 PM, TAMURA, Kent tk...@chromium.org wrote:
 
 FYI. It was removed from Blink too.
 
 
 On Wed, Aug 6, 2014 at 11:40 AM, Benjamin Poulain benja...@webkit.org 
 mailto:benja...@webkit.org wrote:
 Hi,
 
 Is anyone interested in INPUT_SPEECH?
 
 It looks like no port enable that feature. The code looks unmaintained. 
 Everyone skip all the tests.
 
 I will remove the code if nobody maintains it.
 
 Benjamin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 -- 
 TAMURA Kent 
 Software Engineer, Google 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] dump accessibility tree

2014-04-23 Thread Chris Fleizach
A few of the layout tests have something like this where it can iterate every 
object.

Although usually, the platform AX trees are pretty accurate representations of 
what in the WebCore AX tree

On Apr 23, 2014, at 12:34 PM, Jarek Czekalski ja...@jarek.katowice.pl wrote:

 Hi All!
 
 I'm trying to discover the way accessibility works in webkit and maybe fix 
 some orca blockers. There is a renderer tree, that I can dump using 
 DumpRenderTree. There is also atk tree, that I can inspect with python 
 scripts and accerciser. But there is also a layer inbetween, something like 
 WebCore Accessibility Tree. Is there a way to dump the tree for a given page?
 
 Or maybe there are other useful tools or tricks, to use when I see a broken 
 atk tree, like in bug #131933 [1]?
 
 Thanks in advance
 Jarek
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=131933
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Reading Open Type tables in WebKit?

2014-03-20 Thread Chris Fleizach
Hi,

In regards to the Mac platform we can use with CTFontCopyTable() with the MATH 
identifier.

Can you email me a copy of the Microsoft document so we can look into it more.

Thanks

On Mar 19, 2014, at 11:43 PM, Frédéric WANG fred.w...@free.fr wrote:

 Hi all,
 
 I'm trying to implement the OpenType MATH table [1] in WebKit in order to 
 improve the MathML support. I've already made some progress and split the 
 work into several steps [2]. For people who are interested, here are some 
 screenshots showing some rendering improvements:
 
 http://www.ulule.com/mathematics-ebooks/news/screenshots-31369/
 
 There was already some code in Source/WebCore/platform/graphics/opentype/ to 
 read OpenType tables so I've been able to reuse it for the MATH table. 
 However, this code is not compiled on all platforms. At the moment I'm only 
 able to compile the support for OpenType MATH table with the following 
 condition:
 
 USE(FREETYPE) || (PLATFORM(WIN)  (USE(CG) || USE(CAIRO)))
 
 which I think means it will work on Linux (I tested the EFL and GTK ports) 
 and most Windows platforms (not tested yet). This means that for the Mac 
 port, I can not do better than using big hardcoded tables... That can be a 
 temporary solution, but it would be better to read the font tables directly 
 in order to get support for arbitrary MATH fonts and to make maintenance 
 easier.
 
 So I'd like to know if the current font API on the Mac port has some features 
 to load OpenType tables? As a comparison on Gecko, I've used Harfbuzz to read 
 the MATH table and this library is also available on Mac. I heard that Blink 
 was moving to Harfbuzz on all platforms, so I'm also wondering if there are 
 plans to do the same for WebKit? This would allow to support OpenType tables 
 on all platforms...
 
 Thank you,
 
 [1] MATH table references:
 http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format/call-proposals-isoiec-14496-22-open-font-format-color-font
 http://www.ntg.nl/maps/38/03.pdf
 The MATH table and OpenType Features for Math Processing (Microsoft's 
 document, not public yet ; send me a private mail if you want to get a copy)
 
 [2] Bugzilla references:
 https://bugs.webkit.org/show_bug.cgi?id=130321
 https://bugs.webkit.org/show_bug.cgi?id=130322
 https://bugs.webkit.org/show_bug.cgi?id=130324
 https://bugs.webkit.org/show_bug.cgi?id=130325
 
 -- 
 Frédéric Wang
 MathML Crowdfunding: ulule.com/mathematics-ebooks
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

2014-01-27 Thread Chris Fleizach
I dislike this change now that's been rolled out. 

The lack of email notices before confirmed that my patch was OK and I was able 
to do something else while waiting for review.
Now I have to continually revisit the bug page checking to see if more bots 
have completed and that my patch is good.

I think at least the person who submitted the patch should be notified when 
there's been an error.



On Jan 17, 2014, at 4:27 PM, Alexey Proskuryakov a...@webkit.org wrote:

 
 This has been implemented, and one unintended consequence is that this 
 noticeably affects how quickly one can iterate on time sensitive patches.
 
 It's a huge waste of time that you are no longer informed when a build fails 
 on EWS. This seriously delays urgent work, as you only start working on fixes 
 when you happen to manually poll, or even worse, when a reviewer tells you 
 about build breakage.
 
 It's good to not spam everyone, however patch author should be notified by 
 EWS immediately I think. Some ideas:
 
 - e-mail;
 - IRC;
 - browser notifications when bug page is open.
 
 The latter might be best, as it also gives some control over whether to get 
 pinged - keep the bug open if you care, close it if it's not urgent, and you 
 cannot afford distraction now.
 
 I filed https://bugs.webkit.org/show_bug.cgi?id=127203 about this.
 
 - WBR, Alexey Proskuryakov
 
 
 16 янв. 2014 г., в 15:09, Ryosuke Niwa rn...@webkit.org написал(а):
 
 Okay, let's remove the python paths but keep the style error messages until 
 we can improve the EWS infrastructure.
 
 - R. Niwa
 
 
 On Thu, Jan 16, 2014 at 9:41 AM, Timothy Hatcher timo...@apple.com wrote:
 On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote:
 
 
 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а):
 
 I think that it's good to try not dumping build failures into comments 
 right away, and to see what happens.
 
 As for not showing style bot failures, it seems almost certain that this 
 will make them substantially more annoying to work with. Can you describe 
 the workflow for patch author and reviewer to deal with style bot warnings 
 when they are not inline? Manually finding relevant lines by number can't 
 work.
 
 I agree with Tim that dumping all tested paths along with style warnings 
 is silly. How hard would it be it to get rid of that?
 
 The workflow is to click on the bubble to see the style errors. e.g.
 https://webkit-queues.appspot.com/results/6544662978363392
 
 
 Seems like that would require everyone to manually match errors to code 
 lines indeed, so I object against making this change for style checker 
 warnings.
 
 - WBR, Alexey Proskuryakov
 
 Yeah, seeing the style warnings as a comment (which also causes them to show 
 up in the patch review) is helpful. I was just complaining about the python 
 path spew it also includes.
 
 — Timothy Hatcher
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d

2013-10-14 Thread Chris Fleizach

On Oct 14, 2013, at 2:28 PM, Rik Cabanier caban...@gmail.com wrote:

 
 
 
 On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher timo...@apple.com wrote:
 On Oct 14, 2013, at 12:43 PM, Rik Cabanier caban...@gmail.com wrote:
 
 Also, how would your suggestion tell the UA about what areas are associated 
 with the elements? What happens if an element is no longer focused? The ring 
 is drawn into the canvas bitmap so those pixels have to be regenerated.
 
 
 Focus rings are usually larger than the control they surround. How is the 
 developer suppose to know the pixel padding needed for each platform's focus 
 ring? Guess and hope for the best?
 
 Why would he need to know this? Is it for the path that describes the ring?
  
 Would drawing the system focus ring taint the canvas pixels? (Drawing form 
 controls into canvas via SVG images and foreignObject has been considered 
 taint worthy because it could leak the user's UI theme.)
  
 I'm unsure if it should taint the canvas. How much information would be 
 leaked that isn't already available through other means?
 

Hi, 

I think it would be likely that the OS would draw their focus ring on top in a 
different context and the canvas wouldn't have to be responsible to repaint.

Which leaves the case where the canvas sees drawCursor fails and then tries to 
draw its own, which seems somewhat strange to me. How would the web page know 
what the user wanted. There could be a variety of high contrast cursors that 
the user might want to use

Thanks


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


Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d

2013-10-11 Thread Chris Fleizach
Hi

The naming of these methods also made it a bit confusing for me.

It appears that drawCustomFocusRing   just updates the accessibility rectangle 
-- while the system variant does that, and draws the normal focus ring. 
In the former case, it doesn't really draw anything, it just allows an AT to 
retrieve the bounding box of the focused item.

It seems that for this to be useful for ATs, you'd have to iterate every object 
in your canvas and call at least drawCustomFocusRing once. Then when the item 
actually did become focused, you'd have to call drawSystemFocusRing. 

I don't know what others think, but I think accessibility work is best done on 
demand.

In this case I could imagine something like a RectangleRequestEvent be 
dispatched that the canvas could intercept. 
The event would have the Element in question as a data member of the 
Event.
The canvas could set the rectangle in the event for that element 

Then this work would only have to be done when requested


On Oct 10, 2013, at 7:32 PM, Rik Cabanier caban...@gmail.com wrote:

 
 
 
 On Thu, Oct 10, 2013 at 7:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Oct 10, 2013 at 7:21 PM, Rik Cabanier caban...@gmail.com wrote:
 On Thu, Oct 10, 2013 at 7:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Oct 10, 2013 at 7:14 PM, Rik Cabanier caban...@gmail.com wrote:
 On Thu, Oct 10, 2013 at 7:07 PM, Ryosuke Niwa rn...@webkit.org wrote:
 The spec. text is also misleading in saying that 
 
 The drawSystemFocusRing(element) method, when invoked, must run the following 
 steps:
 
 If I understood your reply correctly, these are steps that need to be ran 
 continuously?  Or is it that steps 2  3 must run upon the currently focused 
 element being changed.  The specification needs to revised to clarify this.
 
 I think non-normative text or a note could be added to make this more clear. 
 In general, the function should be called when the focus changes or the 
 element is relocated and the canvas should be redrawn.
 ...
 As is, the specification reads as if the author needs to repaint and call 
 drawSystemFocusRing upon focus change.
 
 That is correct and what should happen.
 
 
 That seems to contract what you've said earlier:
 What is an AT? :-) You don't call drawSystemFocusRing when an element is 
 focused. You *always* call it and if it is focused, a ring will be drawn. In 
 all cases, the accessibility software is notified of the area.
 (AT stands for http://en.wikipedia.org/wiki/Assistive_technology).
 
 Am I correct in saying that the author needs to call this function each and 
 every time an element inside the canvas is focused?
 
 No, he needs to ALWAYS call this function wether it's focused or not.
 
 I understand that. My point is that the author has to explicitly repaint the 
 canvas and call drawSystemFocusRing when the focus changed for the focus ring 
 to be drawn.  i.e. UA can't later decide to draw the focus ring on its own.
 
 That is correct. The accessibility software can though since it just draws on 
 top of the browser windows (and so can the web inspector)
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

2013-10-07 Thread Chris Fleizach
Hi Dirk,


On Oct 7, 2013, at 12:36 AM, Dirk Schulze dschu...@adobe.com wrote:

 I am all for accessibility! But isn't the idea to keep content out of CSS so 
 that it does not interfere with accessibility as much as possible?
 
 The main problem with the 'content' property is that it is not accessible. 
 Why I really think it should not be used for more than symbols. ARIA and 
 class names on the element can help screen readers to make the styling 
 accessible as needed.
 
Is this a question? I'm not sure what you're driving at. Yes ARIA can be used 
to provide labels, but when CSS content is used, there's nothing to label (ie 
DOM Node)

 Do you have use cases where unaccessible CSS is actually a problem? And 
 which actually needs  to be done in CSS?

We come across scenarios like

 [data-new]::after {
   content: \2730”; /* a.k.a. ✰ , literally “shadowed white star” 
  */
   alt: attr(data-new); /* allows for localized content from the 
 DOM, e.g. @data-new=New! */
   }

Where we don't want the screen reader to say shadowed white star -- we want 
to label it with the semantic description  -- New!


 
 Also, did you speak with people from screen reader software and societies for 
 people with different needs and preferences? Are they willing to adapt this 
 feature and on board?

Apple makes a screen reader for Mac and iOS, so this is not an issue for us. 
Moreover, there's nothing for them to adapt or be on board with. WebKit can 
start vending the right information and everyone benefits.

 
 This discussion should probably also move to the W3C mailing list www-style 
 unless you don't plan to expose it to the web.
 

Inside the webkit bug, the first comment states:

Description From James Craig 2013-08-22 17:59:42 PST (-) [reply]
AX: Implement CSS -webkit-alt property

Not in a spec yet, but discussion was positive and the issue is being tracked 
by the CSS WG. Since this is holding up several projects, I propose 
implementing the vendor-prefixed form: -webkit-alt.

http://lists.w3.org/Archives/Public/www-style/2012Nov/0319.html



 Greetings,
 Dirk
 
 On Oct 1, 2013, at 7:08 AM, James Craig jcr...@apple.com wrote:
 
 AX: Implement CSS -webkit-alt property
 https://bugs.webkit.org/show_bug.cgi?id=120188
 
 This is blocking 20+ bugs on one of our higher profile content sites and 
 we’d like to start work on it. To clarify, the problem is that with CSS 
 generated content in pseudo-elements like this:
 
  .expandable::before { content: \25BA; /* a.k.a. ► */ }
 
 …there is no way to prevent VoiceOver from speaking the literal character 
 description, “right pointing black pointer.” If this were an actual DOM 
 node, we could hang some ARIA attributes on it, but there is no node for 
 pseudo-elements, so the property has to be defined in CSS.
 
 The CSS Working Group discussion indicates the editors (Tab from Google, and 
 Elika from Mozilla) are generally on board with the concept of accessible 
 text alternatives for CSS generated content and Tab suggested the property 
 name. It is not in a CSS4 draft yet, but some usage examples are below.
 
 Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
 
  [aria-expanded=false”]::before {
  content: \25BA; /* a.k.a. ► , literally “right pointing black 
 pointer” */
  alt: ; /* aria-expanded=false already in DOM, so this 
 pseudo-element is decorative */
  }
 
 And this, where a style indicates new content, screen readers can speak 
 “New” instead of “shadowed white star”:
 
  [data-new]::after {
  content: \2730”; /* a.k.a. ✰ , literally “shadowed white star” 
  */
  alt: attr(data-new); /* allows for localized content from the 
 DOM, e.g. @data-new=New! */
  }
 
 Any questions or concerns?
 
 Thanks,
 James
 
 
 PS. Related to this one is bug 122138, where the “alt” can be specified 
 inline after url() image content:
 
 AX: WebKit does not expose text alternative of CSS generated image content
 https://bugs.webkit.org/show_bug.cgi?id=122138
 
  .new::after {
  content: url(./star.png), New!;
  }
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


[webkit-dev] Feature Announcement: IndieUI: Events

2013-03-05 Thread Chris Fleizach
Hello,

I'm planning on implementing the IndieUI Events 1.0 W3C spec
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html

This feature's primary goal is to allow assistive technologies (like a Screen 
reader) a way to control certain events that normally rely on a standard 
device, but it's abstract enough that it will be useful in other contexts.

Example: The escape key on a keyboard might be used to dismiss a dialog, but an 
assistive technology might not be able to press the escape key.

The spec's introduction states:

IndieUI: Events 1.0 is an abstraction between physical, device-specific user 
interaction events and inferred user intent such as scrolling or changing 
values. This provides an intermediate layer between device- and 
modality-specific user interaction events, and the basic user interface 
functionality used by web applications. IndieUI: Events focuses on granular 
user interface interactions such as scrolling the view, canceling an action, 
changing the value of a user input widget, selecting a range, placing focus on 
an object, etc. Implementing platforms will combine modality-specific user 
input, user idiosyncratic heuristics to determine the specific corresponding 
Indie UI event, and send that to the web application in addition to the 
modality-specific input such as mouse or keyboard events, should applications 
wish to process it.


The WebKit bug can be found here
https://bugs.webkit.org/show_bug.cgi?id=111446

The feature flag I plan on using is
INDIEUI_EVENTS

Let me know if you have any questions.

Thanks
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Feature Announcement: WebSpeech - Speech Synthesis

2013-01-13 Thread Chris Fleizach
Hello,

I'm planning on implementing the speech synthesis aspect of the WebSpeech API 
Specification
https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#tts-section

The WebKit bug can be found here
https://bugs.webkit.org/show_bug.cgi?id=106742

I'll be putting the files in the Modules/speech/ directory where the WebSpeech 
Speech Recognition files live, but I'll be using a different ENABLE flag so 
that a platform can decide to support one or the other (or both).

The flag I plan on using is
WEB_SPEECH_SYNTHESIS

Let me know if you have any questions.

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


Re: [webkit-dev] Accessibility Object Searching

2011-06-22 Thread Chris Fleizach

On Jun 22, 2011, at 3:34 PM, Dominic Mazzoni wrote:

 I just had another thought: how would this work in a multi-process browser?
 
 As you may know, Chrome runs an instance of webkit in a separate
 renderer process for each tab, but the GUI and all accessibility
 handling happens in the main browser process. Because accessibility
 calls are synchronous, we cache accessibility information in the
 browser process and respond to queries from that cache, rather than
 sending an IPC to the renderer process and getting a response. I
 realized that we wouldn't be able to use this search function very
 easily as you've proposed it. If NSAccessibility gets such an API,
 we'd have to write our own implementation that could run in Chrome's
 browser process.
 

I think this is one drawback of Chrome's approach, the inability to retrieve 
dynamic information. I suspect Chrome has similar issues for the 
NSAccessibilityParameterizedAttribute attributes, and that it doesn't support 
the AXTextMarker APIs that Safari does for the same reason.

To support this (along with the other things I mentioned) Chrome would need to 
synchronously called into WebCore, wait for the answer, and then return that 
information.

 My understanding was that WebKit2 and Safari are moving to a
 multi-process model as well. Is this design going to be compatible
 with this?
 

Yes, WebKit2 works with accessibility. You'll be able to see the code to 
support that strewn throughout WebKit2. Let me know if you need more pointers.

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

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


Re: [webkit-dev] Accessibility Object Searching

2011-06-22 Thread Chris Fleizach

On Jun 22, 2011, at 4:29 PM, James Robinson wrote:

 On Wed, Jun 22, 2011 at 4:21 PM, Chris Fleizach cfleiz...@apple.com wrote:
 
 On Jun 22, 2011, at 3:34 PM, Dominic Mazzoni wrote:
 
  I just had another thought: how would this work in a multi-process browser?
 
  As you may know, Chrome runs an instance of webkit in a separate
  renderer process for each tab, but the GUI and all accessibility
  handling happens in the main browser process. Because accessibility
  calls are synchronous, we cache accessibility information in the
  browser process and respond to queries from that cache, rather than
  sending an IPC to the renderer process and getting a response. I
  realized that we wouldn't be able to use this search function very
  easily as you've proposed it. If NSAccessibility gets such an API,
  we'd have to write our own implementation that could run in Chrome's
  browser process.
 
 
 I think this is one drawback of Chrome's approach, the inability to retrieve 
 dynamic information. I suspect Chrome has similar issues for the 
 NSAccessibilityParameterizedAttribute attributes, and that it doesn't support 
 the AXTextMarker APIs that Safari does for the same reason.
 
 To support this (along with the other things I mentioned) Chrome would need 
 to synchronously called into WebCore, wait for the answer, and then return 
 that information.
 
 Assuming that the data is needed from the browser process (or UI process in 
 WebKit2 terminology) that's not acceptable from either a performance or bug 
 point of view.  In a multi-process browser, you can never let the browser (or 
 UI) process block on a synchronous message from the renderer (or web) process.
 

While this policy decision may be important, the downside is that it sacrifices 
the correctness of Accessibility, on Mac at least.

Luckily, there are now hooks in WebKit2 that allow true cross process 
accessibility. The AT talks directly to the web process when it needs to and 
the hierarchy between the two apps appears seamless.


 - James
 
 
 
  My understanding was that WebKit2 and Safari are moving to a
  multi-process model as well. Is this design going to be compatible
  with this?
 
 
 Yes, WebKit2 works with accessibility. You'll be able to see the code to 
 support that strewn throughout WebKit2. Let me know if you need more pointers.
 
  - Dominic
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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


Re: [webkit-dev] Accessibility Object Searching

2011-06-21 Thread Chris Fleizach

Searching for elements on a webpage is one of the important functions for a 
screen reader, so this has the potential for vastly improving screen reader 
access on the web.

What's nice about this approach is that it will allow other platforms to also 
take advantage. It should significantly reduce memory usage, number of IPC 
calls and overall runtime whenever searching is done.

On Jun 21, 2011, at 4:30 PM, Samuel White wrote:

 Hey everybody,
 
 I'm new to the list and thought it would be a good idea to get some feedback 
 on an accessibility feature before filing a bug or submitting anything. 
 Currently, no functionality exists in WebKit to search through 
 AccessibilityObjects using basic search criteria like next link or next table 
 internally. Screen readers and other access devices often must instead probe 
 WebKit and build up their own internal representation of a page before they 
 can begin searching for what they are after. This presents two big problems 
 for the users of access technology. First, pages such as the HTML 5 working 
 doc have a massive number of DOM elements and building up an external 
 representation can be a very expensive and slow task. Secondly, maintaining 
 an accurate external representation of a site can become difficult if that 
 site has a large amount of dynamic content and users may not be accessing 
 relevant information.
 
 I would like to make a few small changes to the AccessibilityObject class 
 that adds the functionality I've mentioned. I think these small but important 
 additions will allow existing access technologies to rely much more on 
 WebKits representation of a page and thus eliminate the problems I've 
 described above. I appreciate any feedback and look forward to helping out.
 
 Thanks
 Sam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Accessibility Object Searching

2011-06-21 Thread Chris Fleizach

On Jun 21, 2011, at 5:45 PM, Charles Pritchard wrote:

 On Jun 21, 2011, at 4:30 PM, Samuel White samuel_wh...@apple.com wrote:
 
 Hey everybody,
 
 I'm new to the list and thought it would be a good idea to get some feedback 
 on an accessibility feature before filing a bug or submitting anything. 
 Currently, no functionality exists in WebKit to search through 
 AccessibilityObjects using basic search criteria like next link or next 
 table internally. Screen readers and other access devices often must instead 
 probe WebKit and build up their own internal representation of a page before 
 they can begin searching for what they are after. This presents two big 
 problems for the users of access technology. First, pages such as the HTML 5 
 working doc have a massive number of DOM elements and building up an 
 external representation can be a very expensive and slow task. Secondly, 
 maintaining an accurate external representation of a site can become 
 difficult if that site has a large amount of dynamic content and users may 
 not be accessing relevant information.
 
 I would like to make a few small changes to the AccessibilityObject class 
 that adds the functionality I've mentioned. I think these small but 
 important additions will allow existing access technologies to rely much 
 more on WebKits representation of a page and thus eliminate the problems 
 I've described above. I appreciate any feedback and look forward to helping 
 out.
 
 Thanks
 Sam
 
 While you're rooting around in there, I'd love to see the tree exposed to 
 WebKit inspector at some point. It might make ARIA a little easier to use.
 

The accessibility hierarchy is usually coupled (tightly at times) to the 
platform's implementation. Often there are tools on the platform to help figure 
out the accessibility hierarchy. 

On the Mac, there's Accessibility Inspector, which conveniently can also be 
run on the iOS simulator. Just start the program and hover the mouse over an 
item on a webpage to learn how it's exposed to the platform.

 I'm still months away from being a contributor-- I'm hoping to see the canvas 
 shadow DOM made accessible, and subsequently, see paths supported by 
 assistive technology, like Apple's gesture-based eyes-free mode in Mobile 
 Safari/iOS.
 
 -Charles
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Considering a Touchhover

2011-03-11 Thread Chris Fleizach

There's no established API to handle this, but we are working on a W3C proposal 

http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html

to address this.

In the meantime, VoiceOver on iOS will call .focus() every time it hovers on 
an item, so you can use that monitor where VO is at any moment.

If that doesn't work with canvas tags please file bugs at bugs.webkit.org and 
CC me

On Mar 11, 2011, at 9:43 AM, Charles Pritchard wrote:

 Recently, while working on code review / accessibility for a large canvas 
 application, I found that the iOS VoiceOver AT
 does not play well with the html canvas element. It can work, but it's not a 
 natural transition from html to
 canvas (with buttons in it). Using transparent [button] tags work, but it 
 is rather awkward.
 
 It occurred to me that, when VoiceOver is on, on these mobile devices, that a 
 new touch type is active.
 For the time being, I'm proposing calling it touchhover.
 
 Currently, VoiceOver AT captures touch events, waiting until the user has set 
 virtual focus to an element,
 then tapped twice, to set event focus on that element. It works quite well 
 for html elements.
 
 My thinking is that this state, where it's not passing 
 touchstart/touchmove/touchend events, is
 very much like the traditional hover events we've used with mice.
 
 If touchhover events were passed through Mobile Safari, I'd be able to use 
 hit detection on canvas
 elements, and set the canvas element to the appropriate title matching 
 whatever the user has focus upon.
 
 Does this make sense? Should I provide more examples? The purpose here is to 
 enable UI elements
 in Canvas to work appropriately with touch-based AT, such as the iOS 
 VoiceOver extension.
 
 
 -Charles
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


[webkit-dev] Accessibility in WK2 update

2011-01-04 Thread Chris Fleizach
Just landed a large patch to make accessibility work in WK2

http://trac.webkit.org/changeset/75031

There were some changes that may have implications for other platforms, so if 
you work on accessibility read on.

• I replaced the getOrCreate method in AXObjectCache with rootObject, so that 
there's no ambiguity about how to get the top of the AX tree from WebKit/WK2.

• I made the root object be the ScrollView containing the RenderView (web 
area). The AX object representing the ScrollView is now handled by 
AccessibilityScrollView, instead of platform scroll views. This was needed 
because there are no platform scroll views in WK2. 

• The AccessibilityScrollView has 3 children, the 2 scroll bars (if visible) 
and the web area.

If any of these changes don't jive with your platform feel free to submit 
patches and I'll review them promptly.

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


Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications

2010-11-01 Thread Chris Fleizach
Hi Ojan,

You reviewed- the first pass at an implementation of this proposal

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

but haven't responded to this thread. Do you have any other objections. 

On Oct 27, 2010, at 2:57 PM, James Craig wrote:

 Sorry for the delayed response, Tony. My answers inline.
 
 On Sep 3, 2010, at 9:35 AM, Tony Chang wrote:
 
 I'm curious what elements the UIRequestEvents apply to.  Does it fire at the 
 document level or does it fire for specific elements like textareas?
 
 Focused element (or AX-focused element) where appropriate. Document body 
 otherwise.
 
 For example, the scroll request events should be fired on the focused node so 
 they can bubble up the DOM tree, so any node that needs to intercept it can. 
 An example of when this may be inappropriate to fire on a lower-level node 
 DOM is in the case of a browsing context that does not have a focus model 
 where something always has focus; e.g. many touch-screen mobile devices do 
 not have a focused element unless a form element is selected, or an assistive 
 technology application is running on top of the rendering engine. In this 
 case, firing at the document level would be appropriate.
 
 The addition of undo/redo is similar to the proposal to add this to the 
 textInput event.  There was some discussion of that here:
 http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html
 
 This may be answered my response to Doug Schepers' related question in this 
 email from the www-dom list.
 http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0051.html
 
 Quoting from that thread:
 
 Doug Schepers wrote:
 Note also that HTML5 defines editing actions and APIs [6], specifically 
 the UndoManager interface [7].
 
 [7] http://www.w3.org/TR/html5/dnd.html#undomanager
 
 James Craig responded:
 The main difference seems to be that our Undo and Redo *request* allows the 
 web application to determine what (if anything) should be undone, or 
 redone, where the HTML5 undo manager requires that the user agent make the 
 change directly to the DOM or editable content. The UIRequestEvent 
 interface allows the app to determine the outcome of the events based on 
 the business logic of the app, which the browser does not know about.
 
 
 The reason these are all called 'request' events is because they don't 
 change anything. They only send a 'request' to the web application (not to 
 the user agent) to make a change on the user's behalf. The web application 
 can then intercept or ignore the event as needed. If ignored (if the web 
 app hasn't registered that event listener, or if the event is not canceled 
 with preventDefault) then the user agent or assistive technology can fall 
 back to whatever behavior is deemed appropriate, including then using the 
 HTML5 undo manager.
 
 
 Back to Tony's email:
 
 Ojan also proposed renaming the textInput event to just beforeInput because 
 it seems like it can apply to more than just text (e.g., undo'ing the 
 insertion of an image).  Do you think the use of textInput/beforeInput would 
 meet the use cases needed by UIRequestEvent?
 
 In some cases, it may be appropriate, but my response to the previous 
 question may provide additional understanding of why textInput/beforeInput is 
 not sufficient, and why these two proposals are not mutually exclusive, even 
 if they do overlap in some places.
 
 As I stated in the bug tracker comments, the W3C DOM and PF working groups 
 discussed this, and the outcome was to work on a standalone specification as 
 a joint effort of the two groups. The initial document editors will likely be 
 Doug Schepers (W3C staff contact for www-dom) and me. From the teleconference 
 discussions, these will be an add-on to DOM 3 Events and/or ARIA 1.0, because 
 both of those documents are currently in Last Call. The only major change to 
 the proposal so far that we're discussing a new method to the Event object 
 (perhaps 'suppressEvents' or 'suppressRelatedEvents') so that we don't have 
 to cancel the event by overloading the original use of the preventDefault 
 method.
 
 Thanks for your questions. We realize the proposal may not be clear unless 
 the reader knows a lot about 1) screen readers and 2) WAI-ARIA, but we hope 
 to improve the understandability of the document in future iterations.
 
 Cheers,
 James Craig
 

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


[webkit-dev] Force rebuild on QT Minimal?

2010-09-29 Thread Chris Fleizach
Is there a way to force a clean build on QT minimal. It looks like it just 
didn't update building CSSPrimitiveValueMappings.h

I tried the Force Build button, but it didn't do a clean build

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


Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications

2010-09-03 Thread chris fleizach

Nothing I'm aware of would cause this to be synchronous. Thanks for pointing it 
out. It's definitely worth mentioning this fact in the proposal

On Sep 3, 2010, at 4:56 PM, James Craig wrote:

 On Sep 3, 2010, at 1:47 PM, Dominic Mazzoni wrote:
 
 On Fri, Sep 3, 2010 at 1:44 PM, Adam Barth wrote:
 
 In general, synchronous events are bad from an architectural point of
 view.  They result in large, complex callstacks, which expose crashes
 and security vulnerabilities.  In the long term, they also impose
 contraints on how tightly coupled different components need to be.  If
 two components need to communicate synchronously, that limits our
 future ability to modularize the platform and to exploit parallelism.
 
 
 It'd also be nearly impossible to implement a synchronous API in a 
 multi-process browser like Chrome.
 
 I'm unaware of any reason it would need to be synchronous. 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


[webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications

2010-09-02 Thread Chris Fleizach
Hello WebKit,

James and I have been working on a W3C proposal to address some shortcomings 
we've noticed in terms of dealing with ScreenReaders and magnifiers in the wild 
wild web. 

It's aim is to add JavaScript capabilities to window.navigator and new 
AccessibilityEvents so that web developers are able to make web pages that 
interact with assistive technology to a degree they cannot today.

If you're interested in accessibility, please take a look and send any feedback 
to us, or to these w3c lists (wai-xtech, www-dom, public-canvas-api, and 
public-html-comments) it was posted to


User Interface Independence for Accessible Rich Internet Applications

W3C Proposal: 30 August 2010

http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html


PS:
I had originally submitted a patch for half of this proposal, but we decided it 
would be best to make this public before landing it in webkit.
https://bugs.webkit.org/show_bug.cgi?id=43005



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


[webkit-dev] style question for empty for loops

2010-08-26 Thread Chris Fleizach
Which is preferred?

for (...; ...; ...) { }

or

for (...; ...; ...) 
{ }___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] style question for empty for loops

2010-08-26 Thread Chris Fleizach

On 26. aug. 2010, at 11.49, Darin Adler wrote:

 On Aug 26, 2010, at 11:35 AM, Chris Fleizach wrote:
 
for (...; ...; ...) { }
 

So maybe this is the best option. I can add a style guide check for that, 
unless there are objections

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


Re: [webkit-dev] style question for empty for loops

2010-08-26 Thread Chris Fleizach
webkit-check-style should probably be amended as well


On Aug 26, 2010, at 12:48 PM, James Robinson wrote:

 The style guide currently covers this 
 http://webkit.org/coding/coding-style.html:
 
 4. Control clauses without a body should use empty braces:
 Right:
 for ( ; current; current = current-next) { }
 Wrong:
 for ( ; current; current = current-next);
 
 - James
 
 On Thu, Aug 26, 2010 at 12:22 PM, Chris Fleizach cfleiz...@apple.com wrote:
 
 On 26. aug. 2010, at 11.49, Darin Adler wrote:
 
  On Aug 26, 2010, at 11:35 AM, Chris Fleizach wrote:
 
 for (...; ...; ...) { }
 
 
 So maybe this is the best option. I can add a style guide check for that, 
 unless there are objections
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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


Re: [webkit-dev] Updating the tradition for new reviewer blog posts

2010-08-03 Thread Chris Fleizach

So what is the process then if you have a blog ready to post? Just get one 
person to review?

On 2 ʻAok 2010, at 9:02 PM, Maciej Stachowiak wrote:

 
 I agree that it would be good to have more useful and interesting content. I 
 don't think it's good to do this by forcing the task on new reviewers. Not 
 everyone enjoys a writing exercise and it shouldn't be required to become a 
 reviewer. However, I encourage people to post about cool WebKitty stuff!
 
  - Maciej
 
 On Aug 2, 2010, at 11:56 AM, Tony Gentilcore wrote:
 
 The Surfin' Safari blog seems to have fairly wide readership in the web dev 
 community. Google Reader reports 35k Reader subscribers. For comparison: 
 blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last 
 post with descriptive content was back on April 18th. Since that post, we've 
 written 8 X is a now a WebKit reviewer posts. One recent commenter said:
 
 I don’t suppose there’s anything more interesting going on in WebKit land 
 worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t 
 nearly as interesting as whatever new hotness is coming down the pipe. And I 
 know I’m not the only one who thinks so… Feel like blogging about WebKit 
 awesomeness?
 
 I propose we increase the amount of blogging about WebKit awesomeness by 
 changing the tradition for new reviewer posts.
 
 Instead of defaulting to:
 
   So-and-so is now a WebKit reviewer
   Posted by Someone-else
   So-and-so has worked on awesome-feature or awesome-infrastructure...
 
 We encourage (or just allow?) a format more like:
 
   How awesome-infrastructure works
   Posted by So-and-so, the latest WebKit reviewer
   Here's my description of how awesome-infrastructure works in WebKit...
 
   -OR-
 
   Awesome-feature is the new hotness
   Posted by So-and-so, the latest WebKit reviewer
   Web developers can now use awesome-feature. Here's how it works...
 
 Thoughts?
 
 -Tony
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


[webkit-dev] Rolling out a series of changes

2010-08-02 Thread Chris Fleizach
Anyone know how to roll out a series of changes, like the ones from

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

using sherrifbot or other tools?

(or if someone could just roll out the changes from that patch...)

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


[webkit-dev] LayoutTest with a fragment reported as the document URL?

2010-06-07 Thread Chris Fleizach
Hello,

I need to write a layout test where the document's URL will be reported as

http://layouttest/new-test.html#segment

I tried 

window.location = url + #name1;

but that doesn't work

any ideas?

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


[webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?

2010-06-04 Thread Chris Fleizach
Could someone explain why WebAccessibilityRole duplicates AccessibilityRole?

This will make it very painful to change, re-order or add to AccessibilityRole 
as it becomes necessary in the future

ie) see https://bugs.webkit.org/show_bug.cgi?id=40133
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?

2010-06-04 Thread Chris Fleizach
Is there any way chromium can automate this so if it sees it is different, it 
can re-generate to match the enums again

On Jun 4, 2010, at 10:04 AM, Adam Barth wrote:

 [+fishd]
 
 I believe this is a common pattern in the Chromium WebKit API.  fishd
 can speak to why this works the way it does in more detail.  I believe
 these enums exist to encapsulate WebCore types in the interface.
 
 Adam
 
 
 On Fri, Jun 4, 2010 at 9:40 AM, Chris Fleizach cfleiz...@apple.com wrote:
 Could someone explain why WebAccessibilityRole duplicates AccessibilityRole?
 
 This will make it very painful to change, re-order or add to 
 AccessibilityRole as it becomes necessary in the future
 
 ie) see https://bugs.webkit.org/show_bug.cgi?id=40133
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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


Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?

2010-06-04 Thread Chris Fleizach

For one, I would like to alphabetize that list. That will require hundreds of 
changes, requiring me to make hundreds of blind changes in chromium code.

It seems like rather bad form to duplicate core WebCore code used by all 
platforms, within one platform, and not a solution that is forward looking. 

When ARIA2 comes out, mayhaps there will be a dozen or two new additions. 

It just means every patch that goes in is going to fail to build and force 
someone to look through ported code so they can duplicate the work they just 
did.


On Jun 4, 2010, at 10:45 AM, Peter Kasting wrote:

 On Fri, Jun 4, 2010 at 10:14 AM, Chris Fleizach cfleiz...@apple.com wrote:
 Is there any way chromium can automate this so if it sees it is different, it 
 can re-generate to match the enums again
 
 Is it really that enormous of a problem?  It doesn't seem like you're going 
 to be making hundreds of changes, and modifying two places, while not as 
 convenient as one, isn't anything we don't have to do elsewhere.
 
 PK 

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


Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?

2010-06-04 Thread Chris Fleizach

Was just hoping something easier might come along. I'll let the appropriate 
people know if I need any help 

thanx

On Jun 4, 2010, at 11:04 AM, Peter Kasting wrote:

 On Fri, Jun 4, 2010 at 10:54 AM, Chris Fleizach cfleiz...@apple.com wrote:
 For one, I would like to alphabetize that list. That will require hundreds of 
 changes, requiring me to make hundreds of blind changes in chromium code.
 
 When ARIA2 comes out, mayhaps there will be a dozen or two new additions.
 
 OK, but each of those seems like one change that touches multiple lines, not 
 dozens or hundreds of separate changes that will each individually cause a 
 separate problem.  Alphabetize, see compile failure, alphabetize the other 
 list.
 
 I don't have a proposal for a better API.  One of the primary purposes of 
 Chromium's WebKit API layer is to firewall WebKit types, so a replacement 
 design would have to be able to compile without referencing any WebKit 
 headers, which seems like it precludes something that automatically tracks 
 WebKit-side changes.  Even Darin's mention of switch-based translations would 
 still require you to at least make changes for new and modified enum values 
 (though it would avoid problems due to simple reordering of the enums; but if 
 you're going to reorder once, that costs rather than saves effort).
 
 If it's any consolation, I'm sure any of us Chromium folk would be happy to 
 help make any Chromium-side changes necessary, if there's anything we can do 
 to help.  And if I've missed a good replacement design, we're certainly open 
 to implementing different things in principle.
 
 PK 

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


Re: [webkit-dev] Announcing WebKit2

2010-04-08 Thread Chris Fleizach
If its in a separate process, does Accessibility still work as expected?

On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote:

 Hello everyone,
 
 This is a heads-up that we will shortly start landing patches for a new 
 WebKit framework that we at Apple have been working on for a while. We 
 currently call this new framework WebKit2.
 
 WebKit2 is designed from the ground up to support a split process model, 
 where the web content (JavaScript, HTML, layout, etc) lives in a separate 
 process. This model is similar to what Google Chrome offers, with the major 
 difference being that we have built the process split model directly into the 
 framework, allowing other clients to use it.
 
 Some high-level documentation is available at 
 http://trac.webkit.org/wiki/WebKit2
 
 Currently WebKit2 is available for Mac and Windows, and we would gladly 
 accept patches to add more ports.
 
 We're more than happy to answer any questions you might have, and we hope 
 that this will be a topic of discussion at the WebKit Contributors Meeting.
 
 Thanks,
 Anders Carlsson and Sam Weinig.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Announcing WebKit2

2010-04-08 Thread Chris Fleizach

Great. 

I think Google chrome has taken a similar approach and have had trouble making 
accessibility work because of the inter-process separation, so when we come up 
with a solution, maybe they can adopt as well.

On Apr 8, 2010, at 6:30 PM, Maciej Stachowiak wrote:

 
 On Apr 8, 2010, at 6:19 PM, Chris Fleizach wrote:
 
 If its in a separate process, does Accessibility still work as expected?
 
 It does not yet work in this rough initial version, but it's certainly our 
 intent to make it work.
 
 Cheers,
 Maciej
 
 
 On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote:
 
 Hello everyone,
 
 This is a heads-up that we will shortly start landing patches for a new 
 WebKit framework that we at Apple have been working on for a while. We 
 currently call this new framework WebKit2.
 
 WebKit2 is designed from the ground up to support a split process model, 
 where the web content (JavaScript, HTML, layout, etc) lives in a separate 
 process. This model is similar to what Google Chrome offers, with the major 
 difference being that we have built the process split model directly into 
 the framework, allowing other clients to use it.
 
 Some high-level documentation is available at 
 http://trac.webkit.org/wiki/WebKit2
 
 Currently WebKit2 is available for Mac and Windows, and we would gladly 
 accept patches to add more ports.
 
 We're more than happy to answer any questions you might have, and we hope 
 that this will be a topic of discussion at the WebKit Contributors Meeting.
 
 Thanks,
 Anders Carlsson and Sam Weinig.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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


[webkit-dev] Better to store a local variable or call a method repeatedly?

2010-01-06 Thread Chris Fleizach
I see a lot of code that calls the same function a number of times in the same 
scope.

Is it better to store that result in a local variable, or is it better to 
repeatedly call a method...

in this example, node() is called two times

return !m_renderer-node() || !m_renderer-node()-isContentEditable();

Would it better to write it as 

Node* node = m_renderer-node();
return !node || !node-isContentEditable();
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Calling JavaScript function from within DumpRenderTree

2010-01-02 Thread Chris Fleizach

On Jan 2, 2010, at 1:34 AM, Maciej Stachowiak wrote:

 
 On Jan 1, 2010, at 9:25 PM, Sam Weinig wrote:
 
 
 That said, a more javascripty way to do this would be to pass the function 
 object to liveRegion.addNotificationListener itself.  That way, in the test 
 file, you would have,
 
 liveRegion.addNotificationListener(function(notification) {
   // do stuff with notification
 });
 
 In the implementation of addNotificationListener, you would save the 
 function object off instead of saving off the string, and then call it in 
 _accessibilityNotificationCallback.
 
 I would recommend doing it this second way. Note that with this approach you 
 can still declare the function up front, and just pass the name, but you 
 wouldn't pass it with a string.
 

I agree. I have it working with this method now. 

Thx
 

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


[webkit-dev] Calling JavaScript function from within DumpRenderTree

2010-01-01 Thread Chris Fleizach
I need to have a layout test register a callback with DRT, then have that 
callback be called at the appropriate time (in order to test accessibility 
notifications)

I can't figure out the right incantations to do so. 

I'd like to do something like this in the LayoutTest

var addedNotification = liveRegion.addNotificationListener(ariaCallback);

then have a function in the test like

function ariaCallback(notification) {
   // do stuff with notification
}

DRT knows when to call this method, but I'm not sure how.. This is what I have 
so far, which does not work.

// The JavaScript callback we'll use when we get a notification
static JSStringRef AXNotificationFunctionCallback = 0;

static void _accessibilityNotificationCallback(id element, NSString* 
notification)
{
if (!AXNotificationFunctionCallback)
return;

JSObjectRef function = JSObjectMakeFunction([mainFrame globalContext], 
NULL, 0, NULL, AXNotificationFunctionCallback, NULL, 1, NULL);
JSValueRef argument = JSValueMakeString([mainFrame globalContext], 
JSStringCreateWithCFString((CFStringRef)notification));


JSObjectCallAsFunction([mainFrame globalContext], function, NULL, 1, 
argument, NULL);
}___
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

2009-12-07 Thread 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::TreeSharedWebCore::Node::ref ()
(gdb) bt
#0  0x0001026d2f7f in WebCore::TreeSharedWebCore::Node::ref ()
#1  0x0001026d3163 in WTF::PassRefPtrWebCore::Node::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] [webkit-changes] [48407] trunk/LayoutTests

2009-09-16 Thread Chris Fleizach


Accessibility LayoutTests have unfortunately been a bit of a black box  
since I only know Mac stuff.


It's possible that Windows, for example, supports an accessibility  
value attribute for sliders, but it's also possible that it does not.  
Likewise, it's possible Linux could support that attribute, or not.


All I am sure of right now is that it's not implemented now.

So instead of adding Skipped tests for every platform except Mac on  
every checkin I make, I've just been making them mac tests only.


If someone knows differently on these subjects, please let me know

On Sep 16, 2009, at 6:15 AM, Adam Roben wrote:


On Sep 15, 2009, at 11:39 PM, cfleiz...@apple.com wrote:

+This test should only be for Mac, since the other  
platforms don't support the necessary features.

+
+WAI-ARIA: add support for ranges, including the  
progressbar, slider, and spinbutton roles

+https://bugs.webkit.org/show_bug.cgi?id=28841
+
+* accessibility/aria-slider-value-change-expected.txt:  
Removed.

+* accessibility/aria-slider-value-change.html: Removed.
+* platform/mac/accessibility/aria-slider-value-change- 
expected.txt: Copied from LayoutTests/accessibility/aria-slider- 
value-change-expected.txt.
+* platform/mac/accessibility/aria-slider-value- 
change.html: Copied from LayoutTests/accessibility/aria-slider- 
value-change.html.


Is the test intrinsically Mac-only? Or is it just that Mac is the  
only platform that will currently pass the test?


If it's the former, moving the test to platform/mac (like you did)  
is the right thing. If it's the latter, then either the test should  
be added to the Skipped files for all the other platforms, or  
failing results should be checked in for all the other platforms.  
(I'm not sure which strategy we prefer these days.)


-Adam



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


[webkit-dev] LayoutTest results choose from which folder?

2009-08-22 Thread Chris Fleizach

I just committed

http://trac.webkit.org/changeset/47675

which affects LayoutTest/accessibility/aria-roles.html

The result is different on SnowLeopard than it is on Tiger/Leopard

To account for this difference, I have an -expected file in platform/ 
mac-snowleopard


where the line is

 This test PASSES in DumpRenderTree. The role is AXRole: AXList

There is an existing file in platform/mac/

where the line is

 This test PASSES in DumpRenderTree. The role is AXRole: AXGroup

---
Now after committing, Tiger/Leopard are complaining and saying
http://build.webkit.org/results/Tiger%20Intel%20Release/r47675%20(3758)/accessibility/aria-roles-pretty-diff.html

that it is expecting my the expected file from mac-snowleopard instead  
of platform/mac



My question is, why does Tiger/Leopard expect the file in the mac- 
snowleopard folder


http://build.webkit.org/results/Tiger%20Intel%20Release/r47675%20(3758)/accessibility/aria-roles-expected.txt

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


[webkit-dev] scroll areas of textarea's

2009-08-04 Thread Chris Fleizach
How do the scroll areas that encompass text areas fit into the render  
tree?


I need to turn that scroll area into an accessible object, but when I  
look at the render tree i don't see anything that would indicate there  
is a renderer associated with the scroll area.


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


[webkit-dev] initializing protected variable in a subclass

2009-08-03 Thread Chris Fleizach


I have added

protected:
AccessibilityRole m_role;

to AccessibilityObject.h

I want to initialize that variable in subclasses of  
AccessibilityObject, like so


AccessibilityImageMapLink::AccessibilityImageMapLink()
: m_role(WebCoreLinkRole)

but the compiler says


/Volumes/data/WebKit/WebCore/accessibility/ 
AccessibilityImageMapLink.cpp:48: error: class  
‘WebCore::AccessibilityImageMapLink’ does not have any field named  
‘m_role’


even though this works fine

AccessibilityImageMapLink::AccessibilityImageMapLink()
{
m_role = WebCoreLinkRole;
}

any tips?

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


Re: [webkit-dev] Changing two unit tests: 'alt' as accessible name instead of description

2009-07-23 Thread Chris Fleizach


I don't think you want to return the altTag in stringValue(). That  
should only be for things that have actual strings (textfields, text  
rendered onto the screen)


Right now titleAttr is exposed for all elements in the ::title()  
method. Perhaps that is incorrect, but its hard to get this right,  
since so many developers

use title and alt incorrectly.

On the Mac side, AT software is able to get the titleAttr through an  
AXTitle attribute and the altAttr through AXDescription


AXDescription is supposed to be the description of the object that  
when that description is not displayed on the screen. This is  
basically what accessibilityDescription() does (which also

explains why altAttr is being returned in accessibilityDescription())

So in my naivety, it seems Gtk should exposed the ::title() method  
through some attribute, so that the AT program can take the title and  
the description and decide what to do with it.


On the mac side, there is also an attribute called AXHelp, which is  
more inline with what W3 says on how title should be used (as a  
tooltip). AXHelp thus does return the titleAttr in webkit.


Unfortunately, due to the general uselessness of AXHelp and tooltips,  
it is not something that is often heard by mac AT users.


Combine that with the misusage of the title attribute to label an  
element, creates a situation where the AT user would not hear the  
information the developer adorned their elements

with, in most cases.

Thus, titleAttr is returned as the AXTitle on the mac.



Hi,

As the result of working in bug 25524 (see [1] for more details), we
have reached the conclusion (and not only to fix that bug) that  
perhaps

it would be good to change how the 'alt' attribute is exposed to ATs,
switching from being the accessible description to be the accessible
name. This would allow to always use (for every HTML element) the HTML
core attribute 'title' for the accessible description, which is what  
the

already proposed patch implements so far.

In other works, current patch proposal is as follows:

 * Always expose 'alt' in images as the accesible name.
 * Always expose 'title', for every HTML item, as the accessible
   description.

Problem is that this change, which affects to all the platforms (and  
not

only to GTK, despite of the bug name), would also mean to change two
unit tests which are failing right now:

- accessibility/img-aria-button-alt-tag.html
- accessibility/input-image-alt.html

Those tests are failing because they *always* expect the 'alt'  
attribute

for images to be exposed as the accessible description instead of the
name, and that would need to be changed if this patch got accepted.

Thus, as this change would affect to all the platforms and would  
mean to

change two regression tests, we'd love to hear more opinions from
someone else on this topic before making a final decision.

So... any thoughts?

Thanks,
Mario

[1] https://bugs.webkit.org/show_bug.cgi?id=25524
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev